somtimes rc.conf missed to be start in runlevel 6
Bug #1463299 reported by
Alex Tu
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart |
Expired
|
Undecided
|
Unassigned |
Bug Description
device: Arale
reproduce steps:
1. get reboot tool from lp:~toykeeper/+junk/reboot-test/
2. $ ./reboot-test.sh -v 30m
3. reboot failed around in 8th ~10th times
Somethings different in failed case:
1. rc.config post-stop executed with $PREVLEVEL=2 $RUNLEVEL=6
Success case rc.config post-stop executed with $PREVLEVEL=N $RUNLEVEL=2
2. "/etc/init.d/rc 6" did not be executed.
The original ticket to track this issue:
https:/
To post a comment you must log in.
Hi Alex,
It is certainly possible to hit a race in upstart when changing runlevels. The /etc/init/rc.conf job is 'start on runlevel [...]' and has no 'instance' specifier. If the rc job is still running at the time that another runlevel event is emitted, then /etc/init.d/rc will not be called for the new runlevel.
In general this isn't a major issue because /etc/init.d/rc does very little on an (Ubuntu) upstart system and exits quickly. So it's very rare that a user will be trying to change runlevel before the previous runlevel switch has completed. Indeed, this bug has existed since the beginning of upstart's use and I don't believe anyone has reported it as a problem previously.
It's possible your reboot-test script should be changed so that wait_for_boot ensures the system has entered runlevel 2 before rebooting. I'm surprised if it takes longer for /etc/init.d/rc to finish than it takes for the user session to become available. Races here are also possible, however /etc/init.d/rc *should* be very quick on the phone also. If it's not - perhaps because an init script is blocking - that is something that we will want to debug.