On Wed, May 22, 2013 at 7:41 PM, Laurent Bercot <[email protected]> wrote: >> Erratum: killall5 prevents this, since it does not signal the processes >> in its own session. Ugh. I'll have to study how it's done - the kill() >> system call does not make this easy, so I suspect excluding one process >> group or session from the slaughter requires scanning. Brb studying this. > > Follow-up. Sorry for the spam. > So, as I expected, killall5 is a heavy monster, scanning the process > list in /proc (so, not portable), and killing them one by one unless > they match some criteria. Absolutely ugly, needs some specific tweaks > to support FUSE, and would exhibit a huge race condition if it didn't > SIGSTOP all processes before scanning and SIGCONT them after killing. > > Definitely not the kind of program you'd want your daughter to hang > around with. I'll stay with my "perform the kill in process 1" routine, > it's a lot faster (only 1 system call) and much less ad-hoc and kludgy.
But shutdown from PID 1 *does that too*! You *do* want to kill all processes, not only ones under control of service manager, but even those you have no idea about where they came. > Something is still puzzling me though: to stop all processes before the > scan, killall5 performs kill(-1, SIGSTOP). > How does it not stop itself? Linux doesn't signal the process which does kill(-1). They tried to "POSIX fix" it and promptly discovered that it, tada, breaks shutdown :) I remember reading it on lkml. Fun :) _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
