> 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. Something is still puzzling me though: to stop all processes before the scan, killall5 performs kill(-1, SIGSTOP). How does it not stop itself ? You're not supposed to be able to ignore SIGSTOP, and although sysvinit killall5 ignores it anyway (yay more useless system calls), busybox killall5 does not and still works - I'd assume. There's no comment about this in either sysvinit or busybox, and I have been unable to find information on the Web. POSIX says nothing special about kill() and SIGSTOP, except SIGSTOP cannot be blocked or ignored. Why doesn't kill(-1, SIGSTOP) stop the calling process ? -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
