kill -1 behaviour

Rob Landley rob at landley.net
Wed Mar 8 15:24:10 UTC 2006


On Wednesday 08 March 2006 8:38 am, Giuseppe Ciotta wrote:
> Hi,
>
> I have basically to kill all system processes (except init) and
> execute a pivot_root followed by a chroot into a new filesystem.  I've
> disabled /bin/kill in favour of the ash builtin of the same
> name. Note: I'm running an interactive ash.

Is this busybox ash?

> Trying to kill all processes with ``kill -TERM -1'' kills the current
> shell too, this is annoying since i cannot continue with pivot_root
> and chroot.  Reading the kill(2) manual found on my debian
> installation, i see:
>
> ¨POSIX 1003.1-2001 requires that kill(-1,sig) send sig to all processes
> that the current process may send signals to, except possibly for some
> implementation-defined system processes.  Linux allows a process to
> signal itself, but on Linux the call kill(-1,sig) does not signal the
> current process."

And that's a kernel thing.

> Then i assume there's something wrong in the specification or in the
> kill(2) implementation, since kill(-1,sig) seems to signal the current
> process which actually sent the signal.
>
> Am I missing something out of the picture?

You never said what version of busybox you're using, or what version of the 
kernel, but let's take a look at busybox ash...

Oh joy.  Busybox has a perfectly good kill command, which in standalone shell 
mode you can run as a built-in, and what does ash do?  Reimplements it 
internally as killcmd().  Along the way it even reinvents decimal number 
parsing too (the "number()") function.  Apparently with a function that 
doesn't understand negative numbers, so the call site does this little 
beauty:

> pid = **argv == '-' ?
>                -number(*argv + 1) : number(*argv);

No wonder this pig is over thirteen thousand lines long...

That said, I don't immediately see why it wouldn't work (unless pid_t was 
unsigned, but tracing through the headers it boils down to an int).  But I 
don't trust any of the code in ash.c as far as I could throw it, either.

> P.S.: init tricked me for a while into thinking ash was not receiving
> the signal, but it was simply a respawn put into inittab creating a
> new shell when the current ended. Well, then it's more correct to say
> it was me tricking myself...

Why do you want to use the ash built-in instead of the busybox command?

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list