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