somtimes rc.conf missed to be start in runlevel 6

Bug #1463299 reported by Alex Tu
10
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://bugs.launchpad.net/tangxi/+bug/1453286/comments/17

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Changed in upstart:
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

To be clear, what I'm looking for here by way of additional information is:

- does making your script wait until 'initctl --system list | grep -q '^rc stop/waiting' returns true give you the behavior you want?

- does making this adjustment to the script result in the reboot being much slower than expected? If so - what is running at the time?

- what are the contents of /etc/rc2.d/ on the affected system? (please attach as a tarball)

Revision history for this message
Alex Tu (alextu) wrote :

Hi Steve,
sorry to reply late cause I comment on original LP issue https://bugs.launchpad.net/tangxi/+bug/1453286
I'm wondering which ticket we should continue to comment on.

For 1st, 2nd questions, because the owner of that script is Selene who created LP#1453286, so I think she is the better one who familiar with that script and can answer questions .

For 3th question,
The content can be found in attached file in:
https://bugs.launchpad.net/tangxi/+bug/1453286/comments/22
https://bugs.launchpad.net/tangxi/+bug/1453286/comments/24

Hope this can be help :)

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for upstart because there has been no activity for 60 days.]

Changed in upstart:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.