[PATCH] init: handle kexec clean reboot

Denys Vlasenko vda.linux at googlemail.com
Thu May 23 13:29:55 UTC 2013


On Wed, May 22, 2013 at 7:41 PM, Laurent Bercot
<ska-dietlibc at skarnet.org> 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 :)


More information about the busybox mailing list