kill -1 behaviour

[Jason Schoon]

I can vouch that the kill applet does not have this problem.  I submitted a
patch a while back to allow -1 and it works correctly.

I didn't go find the message threads from back then, but I remember that
Vodz had stated that the shell already had recently added the ability to
specify -1 as well.

So, I guess the first question is what Busybox are you using?  This would
have been added in 1.0 or later.  Other than that, I have never used the
shell version, just the applet.



On 3/8/06, Rob Landley <rob at landley.net> wrote:
>
> 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.
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20060308/3e40b7f4/attachment-0001.htm