init: job.c: 283: Assertion failed in job_changed_state: job->blocker == NULL
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart |
Fix Released
|
Critical
|
Scott James Remnant (Canonical) |
Bug Description
Hi
This can happen when using expect daemon when expect fork should have been used.
As a real world example take the following two .conf files
dbus-system.conf:
start on starting hald
stop on starting shutdown
oom -15
respawn
expect fork
exec dbus-daemon --system --fork
post-stop script
rm -f /var/run/dbus.pid || true
end script
hald.conf (expect daemon should be expect fork here):
start on starting slim
stop on stopping dbus-system
respawn
expect daemon
exec hald --daemon=yes
Typing 'start hald' starts the dbus-system and then hald jobs but upstart gets the pid of hald wrong.
Now 'stop dbus-system' will hang and after breaking initctl status says
dbus-system stop/stopping, process xxx
hald stop/killed, process yyy
and both jobs are stuck.
Finally 'killl xxx' will kill the dbus-daemon and trigger the assert:
init: dbus-system main process ended, respawning
init: job.c: 283: Assertion failed in job_changed_state: job->blocker == NULL
init: Caught abort, core dumped
Kernel panic - not syncing..
/Emil Renner Berthing
Changed in upstart: | |
assignee: | nobody → Scott James Remnant (scott) |
This sounds similar to bug #387216, just following an entirely different code path; there should be no way to "escape" such that blocker is NULL, but it's clearly happening