On 10/06/2015 19:13, Steve Litt wrote:
Does the preceding sentence mean that killall5 is available only when sysvinit is installed? That could be a problem.
It all depends on how your distribution does things, but yes, killall5 comes with the sysvinit tarball, so it's most likely part of your distribution's sysvinit package. Busybox comes with a killall5 utility, if you're dead-set on using killall5, but all in all it's easier to just use kill.
I think I could theoretically change Suckless-Init to run /bin/rc.shutdown with an exec so it *is* pid1. I think.
It's very possible: change sigpoweroff() and sigreboot() so they execvp(rcblahcmd[0], rcblahcmd) instead of spawn(rcblahcmd). Note that on Linux, you're likely to have bash, which includes a kill builtin. If you don't mind depending on bash, or on any other shell that runs kill as a builtin, you don't have to worry about those process 1 shenanigans.
How would one run a shutdown script as a PID higher than 1, then magically change back to PID1? Would you run 2 different shutdown scripts: one for the standard stuff, and one for the "killalls"?
There needs to be support in init for that. Generally, to shut a machine down, you send a signal to init, which then runs a shutdown script. - sysvinit starts by killing all processes itself, before running whatever's in /etc/inittab (usually /sbin/reboot). Since the nuke has already been launched, the shutdown script doesn't need to run as process 1. There are certainly subtleties with FUSE daemons, though; I'm not sure how they're handled by sysvinit. - suckless init and runit just run the shutdown script in another process. It works as long as you're lucky, but since most people use Linux and bash, they're ok. - If you run s6-svscan as process 1, it execs into your shutdown script, so your shutdown script runs as process 1. I paid attention to that because I wanted it to work without depending on the non-portable Linux behaviour where the process launching the nuke is itself protected. -- Laurent
