Bug#142424: sysvinit: single-user mode has no return ("killall5" is much too brutal)
Dmitry Bogatov
KAction at debian.org
Sat Dec 29 18:33:29 GMT 2018
control: tags -1 +moreinfo
[2002-04-12 15:06] Miquel van Smoorenburg <miquels at 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.
More information about the Debian-init-diversity
mailing list