runit event.d file should stop service in single user mode
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
runit (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Medium
|
Unassigned | ||
Quantal |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: runit
[Impact]
Because runit uses an upstart stanza (stop on shutdown) which does not exist it will not be termineted when switching to single user mode and is just left running.
[Test Case]
1. Install runit and add the directory test to /etc/service.
3. Add a script called 'run' and a script called 'finish' to this directory. Add a line 'echo run > /test; sleep 10000' and 'echo finish > /test' to run and finish respectively, then make them executable.
4. When run is marked executable, runsvdir will start it, check with pstree -a to see the runsvdir process tree and run somewhere beneath. Observe that /test contains 'run'.
5. Execute the command 'sudo telinit 1' and wait for the single user command prompt.
6. Observe that pstree -a will still show runsvdir, runsv and run to be running. Also observe that /test will not contain 'finish', which means that runsv has never been told that runsvdir is going to terminate.
runit has not been restarted, it has never been terminated in the first place. It needs a correct upstart configuration to even try to terminate processes graceful. Furthermore, runsvdir expects SIGHUP to correctly shutdown all supervised services.
[Regression potential]
IMO small, unless someone came to rely on the broken behaviour.
Changed in runit (Ubuntu Precise): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in runit (Ubuntu Quantal): | |
status: | New → Triaged |
importance: | Undecided → Medium |
description: | updated |
tags: | added: verification-done-precise |
I've added a debdiff that should fix this issue here:
https:/ /bugs.launchpad .net/ubuntu/ +source/ runit/+ bug/245728
It's against the runit source package in maverick. Can you confirm that the runsvdir process itself was still active in single user mode? The current package behaviour should have resulted in runsvdir being killed and not respawning, but the runsv processes and the services they were supervising still remaining alive. Any testing or feedback would be appreciated.