control: tags -1 +moreinfo
[2002-04-12 15:06] Miquel van Smoorenburg <miqu...@cistron.nl> > According to Marc Herbert: > > Going to single-user runlevel destroys ALL processes on the machine using > > signals, by calling "killall5" inside the init.d/S20single script, (probably > > because it does not trust individual /etc/init.d/XXX stop scripts ?) > > No, because a typical machine has much more processes running than > those started by init scripts, or don't you have any users on your machines? > > > > > 1) I think this goes agains the original System V philosophy, > > No. Read the scripts from for example solaris. Exactly the same is done. > > > 2) This makes the single-user mode "one-way only": it's *impossible* to go > > back to multi-user mode without rebooting, because vital daemons like > > DHCP > > or portmap were wrongly killed. > > They should be restarted when going back to single-user mode. Portmap > doesn't do that right now; several bugs are open against the portmap > package for that, the oldest for 2 years, but the maintainer simply > isn't fixing it. I cannot help that. > > > 1) - extract from "man init" on woody: > > > > When init is requested to change the runlevel, it sends the warning > > signal > > SIGTERM to all processes that are undefined in the new runlevel. It > > then > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Yes, that is the *init binary*. The whole system is much more than that. > > > I find this quite different to killing "ALL" processes without restriction ! > > Because it isn't /sbin/init doing that, but the scripts that form the > whole sysvinit foundation. > > > - extract from "man init" on Solaris 8: > > > > Run Level Changes > > When a run level change request is made, init sends the > > warning signal (SIGTERM) to all processes that are undefined > > ^^^^^^^^^^^^^^^^^ > > Some story. That's /sbin/init, not the scripts. > > > left mounted. During the transition down to single- > > user mode, all processes started by init or init.d > > scripts that should only be running in multi-user > > mode are killed. > > > > 2) Some vital services, like init.d/networking and init.d/portmap for > > instance, are meant to be launched at boot and never stopped. The problem > > is they rely on a active process to function properly. Going to single > > user mode stop these services wrongly, and even worse: brutaly (not > > even calling their /etc/init.d/XXX stop script). > > So that's a bug in those packages. If they need to be shut down > properly, they should supply the correct init scripts to do so. > > > 3) Suggested workarounds (some of them are cumulative, some other mutually > > exclusive): > > > > - modify the init man page to advertise the fact that returning from > > single-user mode kills really ALL processes. > > Again, see above. > > > - ask daemons maintainers to take this single-user specificity > > into consideration > > File bugs against the broken packages if you want. Filing one against > portmap won't help, you'll probably be ignored like the rest of us. > > > - rerun boot scripts after entering single-user mode ? > > Ofcourse not. That's the responsibility of the package itself. > > > - implement a "softer single-user mode" (for instance runlevel number 2), > > which would just bring down services with /etc/init.d/XXX stop scripts, and > > no brutal signals. > > And leave all user processes running? > > > 4) This "cannot return from single-user mode" bug is related to the very old > > bug #16273 : <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=16273> > > "cannot enter single user mode remotely" > > Right, the current system doesn't support that. It would take > a *lot* of effort to change this. I don't see it happening anytime soon. > > But what exactly is the bug you are trying to report here? It looks > more like a discussion that should be held on debian-devel. It seems that previous maintainer meant to close this bug as wontfix, but forgot to do it. Currently, killall(1) is called in `killprocs' script, which is dependency of `single', but it changes nothing -- fact is fact -- switching to single runlevel kills all processed, including those, that were started during process boot (rcS). I do not have strong opinion on this matter, but unless dear co-maintainers, you do, I'd leave behaviour that was with us for 16 yeas intact.
