The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
is supposed to do. Maybe we should follow it.
Andries
--- signal.c~ Thu Nov 22 01:26:27 2001
+++ signal.c Fri Dec 14 18:27:34 2001
@@ -649,8 +649,10 @@
/*
* kill_something_info() interprets pid in interesting ways just like kill(2).
*
- * POSIX specifies that kill(-1,sig) is unspecified, but what we have
- * is probably wrong. Should make it like BSD or SYSV.
+ * POSIX (2001) specifies "If pid is -1, sig shall be sent to all processes
+ * (excluding an unspecified set of system processes) for which the process
+ * has permission to send that signal."
+ * So, probably the process should also signal itself.
*/
static int kill_something_info(int sig, struct siginfo *info, int pid)
@@ -663,7 +665,7 @@
read_lock(&tasklist_lock);
for_each_task(p) {
- if (p->pid > 1 && p != current) {
+ if (p->pid > 1) {
int err = send_sig_info(sig, info, p);
++count;
if (err != -EPERM)
On Fri, 14 Dec 2001 [email protected] wrote:
>
> The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
> is supposed to do. Maybe we should follow it.
Well, we should definitely not do it in 2.4.x, at least not until proven
that no real applications break.
But I applied it to 2.5.x, let's see who (if anybody) hollers.
Linus
On Fri, Dec 14, 2001 at 05:34:48PM +0000, [email protected] wrote:
> + * POSIX (2001) specifies "If pid is -1, sig shall be sent to all processes
> + * (excluding an unspecified set of system processes) for which the process
> + * has permission to send that signal."
> + * So, probably the process should also signal itself.
> - if (p->pid > 1 && p != current) {
> + if (p->pid > 1) {
Argh, I hate this. I fail to see what progress a process could make if
it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
everything except my shell, and now I'll have to kill everything else
manually, one by one.
If a process wants to commit suicide too, why doesn't it just do that
after?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [email protected] ][ [email protected] ]
[ Opinions expressed are not necessarily those of my employers. ]
On Fri, 14 Dec 2001, Simon Kirby wrote:
>
> On Fri, Dec 14, 2001 at 05:34:48PM +0000, [email protected] wrote:
>
> > + * POSIX (2001) specifies "If pid is -1, sig shall be sent to all processes
> > + * (excluding an unspecified set of system processes) for which the process
> > + * has permission to send that signal."
> > + * So, probably the process should also signal itself.
> > - if (p->pid > 1 && p != current) {
> > + if (p->pid > 1) {
>
> Argh, I hate this. I fail to see what progress a process could make if
> it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
> everything except my shell, and now I'll have to kill everything else
> manually, one by one.
I do agree, I've used "kill -9 -1" myself.
However, let's see how problematic it is to try to follow it (in 2.5.x,
not 2.4.x) and if people really complain.
Count one for the complaints, but I want more to overrule a published
standard.
(Of course, a language lawyer will call "self" a "system process",
although I cannot for the life of me really see what kind of excuse we
would come up with to do se ;)
Linus
On Fri, Dec 14, 2001 at 12:40:16PM -0800, Linus Torvalds wrote:
> I do agree, I've used "kill -9 -1" myself.
>
> However, let's see how problematic it is to try to follow it (in 2.5.x,
> not 2.4.x) and if people really complain.
Doesn't init use kill -15 -1, kill -9 -1, etc., to terminate all
processes? Hmm. Yes, it does, but the kernel checks for (pid > 1).
By removing the single compare in the kernel, we're potentially
increasing the size of userspace applications from a single syscall to a
whole walking of /proc just to kill other running processes. Ugh.
"kill -STOP -1" is also great for freezing forkbombs which would no
longer possible with the /proc method.
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [email protected] ][ [email protected] ]
[ Opinions expressed are not necessarily those of my employers. ]
> Of course, a language lawyer will call "self" a "system process"
No, the standard very explicitly allow signalling oneself.
(And Linux also allowed that, e.g. in kill(0,sig), only until now
not in kill(-1,sig).)
>> Argh, I hate this. I fail to see what progress a process could make
>> if it kills everything _and_ itself.
Note that kill() is just a function that sends a signal.
The signal may well be SIGWINCH or SIGSTOP or so.
Andries
Linus Torvalds writes:
> On Fri, 14 Dec 2001, Simon Kirby wrote:
>> it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
>> everything except my shell, and now I'll have to kill everything else
>> manually, one by one.
>
> I do agree, I've used "kill -9 -1" myself.
This means: EVERYTHING DIE DIE DIE!!!!
On a Digital UNIX system, I do "/bin/kill -9 -1" often. I expect it to
kill the shell. This is a nice way to quickly log out and wipe out any
background processes that might try to save state or continue running.
So the standards violation isn't appreciated by all.
On Sat, 15 Dec 2001, Albert D. Cahalan wrote:
> Linus Torvalds writes:
> > On Fri, 14 Dec 2001, Simon Kirby wrote:
>
> >> it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
> >> everything except my shell, and now I'll have to kill everything else
> >> manually, one by one.
> >
> > I do agree, I've used "kill -9 -1" myself.
>
> This means: EVERYTHING DIE DIE DIE!!!!
>
> On a Digital UNIX system, I do "/bin/kill -9 -1" often. I expect it to
> kill the shell. This is a nice way to quickly log out and wipe out any
> background processes that might try to save state or continue running.
Works the same way in Solaris. 'kill -9 -1' kills your running shell
aswell.
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with experience.
On Sat, Dec 15, 2001 at 05:19:42AM -0500, Albert D. Cahalan wrote:
> > I do agree, I've used "kill -9 -1" myself.
>
> This means: EVERYTHING DIE DIE DIE!!!!
>
> On a Digital UNIX system, I do "/bin/kill -9 -1" often. I expect it to
> kill the shell. This is a nice way to quickly log out and wipe out any
> background processes that might try to save state or continue running.
Exactly.
And then init spawns your getty again, and you log in again, and you
continue doing what you were doing.
Or you could just let it not kill the process doing the killing, and
you'd be more productive.
My point is that I can't see a valid case where we _actually want_ -1 to
send to itself also. Yes, I know the standards don't mention this. They
also don't explicity disallow not sending to the originating process, so
I don't see what the big problem is.
Does anybody have a case where including itself is actually useful?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [email protected] ][ [email protected] ]
[ Opinions expressed are not necessarily those of my employers. ]
Simon Kirby writes:
> On Sat, Dec 15, 2001 at 05:19:42AM -0500, Albert D. Cahalan wrote:
>> [Linus Torvalds]
>>> I do agree, I've used "kill -9 -1" myself.
>>
>> This means: EVERYTHING DIE DIE DIE!!!!
>>
>> On a Digital UNIX system, I do "/bin/kill -9 -1" often. I expect it to
>> kill the shell. This is a nice way to quickly log out and wipe out any
>> background processes that might try to save state or continue running.
>
> Exactly.
>
> And then init spawns your getty again, and you log in again, and you
> continue doing what you were doing.
No, ssh/sshd drops the connection and you step away from the computer.
If the shell doesn't die like it's supposed to, then you have to kill
it separately. The point is to log out, avoiding left-over processes.
Like this: alias x='/bin/kill -9 -1'
> Or you could just let it not kill the process doing the killing, and
> you'd be more productive.
No, less, because you shouldn't walk away with a shell left running.
You need to kill the shell.
> My point is that I can't see a valid case where we _actually want_ -1 to
> send to itself also.
...
> Does anybody have a case where including itself is actually useful?
The above. It's time to eat or go to bed. Die! Die! All processes die!
Hi, all. To followup on the change in 2.5.1 which sends a signal to
the signalling process when send_pid==-1, I have a definate case where
the new behaviour is highly undesirable, and I would say broken.
shutdown(8) from util-linux (*not* the version that comes with the
bloated monstrosity known as SysVInit) uses the sequence:
kill (-1, SIGTERM);
sleep (2);
kill (-1, SIGKILL);
to ensure that all processes not stuck in 'D' state are killed.
With the new behaviour, shutdown(8) ends up killing itself. This is no
good, because the shutdown process doesn't complete (i.e. unmounting
of filesystems, calling sync(2) and good stuff like that).
If this change remains, it will break all users of
simpleinit(8)/shutdown(8). I'm not happy about moving logic for
shutdown(8) into simpleinit(8), since it will just end up bloating it
without good reason.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Monday 17 December 2001 05:01, Richard Gooch wrote:
> Hi, all. To followup on the change in 2.5.1 which sends a signal to
> the signalling process when send_pid==-1, I have a definate case where
> the new behaviour is highly undesirable, and I would say broken.
>
> shutdown(8) from util-linux (*not* the version that comes with the
> bloated monstrosity known as SysVInit) uses the sequence:
Hi Richard, I'm using your new init and happy with it (thanks!).
I am very willing to discuss other side of a coin (i.e. shutdown sequence),
let's do it off the list.
> kill (-1, SIGTERM);
> sleep (2);
> kill (-1, SIGKILL);
>
> to ensure that all processes not stuck in 'D' state are killed.
>
> With the new behaviour, shutdown(8) ends up killing itself. This is no
> good, because the shutdown process doesn't complete (i.e. unmounting
> of filesystems, calling sync(2) and good stuff like that).
I don't use your shutdown, I found it possible to spawn a shell script
in a new process group and use killall5 to term/kill everything except this
process group. It works. (But yesterday I saw fsck again... something did not
get umounted?) I can mail my scripts to you for a little discussion. Mail me.
--
vda
Linus Torvalds wrote:
> Count one for the complaints, but I want more to overrule a published
> standard.
>
> (Of course, a language lawyer will call "self" a "system process",
> although I cannot for the life of me really see what kind of excuse we
> would come up with to do se ;)
Root doing a kill -1 -9 is definitely doing system administration,
hence it is a "system process." I never do this as a user,
but think about what happens at shutdown time. At least a
root process ought to survive this.
Helge Hafting
* Linus Torvalds ([email protected]) wrote:
>
> On Fri, 14 Dec 2001 [email protected] wrote:
> >
> > The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
> > is supposed to do. Maybe we should follow it.
>
> Well, we should definitely not do it in 2.4.x, at least not until proven
> that no real applications break.
>
> But I applied it to 2.5.x, let's see who (if anybody) hollers.
I had to back this change out of 2.5.1 in order to get a sane shutdown.
killall5 -15 is commiting suicide ;-(
cheers,
-chris
On Monday 17 December 2001 07:34, Chris Wright wrote:
> * Linus Torvalds ([email protected]) wrote:
> > On Fri, 14 Dec 2001 [email protected] wrote:
> > > The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
> > > is supposed to do. Maybe we should follow it.
> >
> > Well, we should definitely not do it in 2.4.x, at least not until proven
> > that no real applications break.
> >
> > But I applied it to 2.5.x, let's see who (if anybody) hollers.
>
> I had to back this change out of 2.5.1 in order to get a sane shutdown.
> killall5 -15 is commiting suicide ;-(
Hmm. Looking at killall5 source I see
kill(-1, STOP);
for(each proc with p.sid!=my_sid) kill(proc, sig);
kill(-1, CONT);
I guess STOP will stop killall5 too? Not good indeed.
We have two choices: either back it out or find a sane way to implement
killall5 with new kill -1 behaviour.
--
vda
On Mon, 17 Dec 2001, Sean Hunter wrote:
> > Hmm. Looking at killall5 source I see
> >
> > kill(-1, STOP);
> > for(each proc with p.sid!=my_sid) kill(proc, sig);
> > kill(-1, CONT);
> >
> > I guess STOP will stop killall5 too? Not good indeed.
> Couldn't it just do:
[..]
> ... in other words, block signals, do the killing, then unblock?
SIGSTOP and SIGKILL can't be blocked.
Matthew.
On Mon, Dec 17, 2001 at 12:41:21PM -0200, vda wrote:
> On Monday 17 December 2001 07:34, Chris Wright wrote:
> > * Linus Torvalds ([email protected]) wrote:
> > > On Fri, 14 Dec 2001 [email protected] wrote:
> > > > The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
> > > > is supposed to do. Maybe we should follow it.
> > >
> > > Well, we should definitely not do it in 2.4.x, at least not until proven
> > > that no real applications break.
> > >
> > > But I applied it to 2.5.x, let's see who (if anybody) hollers.
> >
> > I had to back this change out of 2.5.1 in order to get a sane shutdown.
> > killall5 -15 is commiting suicide ;-(
>
> Hmm. Looking at killall5 source I see
>
> kill(-1, STOP);
> for(each proc with p.sid!=my_sid) kill(proc, sig);
> kill(-1, CONT);
>
> I guess STOP will stop killall5 too? Not good indeed.
>
> We have two choices: either back it out or find a sane way to implement
> killall5 with new kill -1 behaviour.
Couldn't it just do:
sigset_t new;
sigset_t savemask;
sigfillset (&new);
sigprocmask (SIG_BLOCK, &new, &savemask);
kill(-1, STOP);
for(each proc with p.sid!=my_sid) kill(proc, sig);
kill(-1, CONT);
sigprocmask (SIG_SETMASK, &savemask, (sigset_t *) 0);
... in other words, block signals, do the killing, then unblock?
Sean
On Monday 17 December 2001 09:53, Sean Hunter wrote:
> > Hmm. Looking at killall5 source I see
> >
> > kill(-1, STOP);
> > for(each proc with p.sid!=my_sid) kill(proc, sig);
> > kill(-1, CONT);
> >
> > I guess STOP will stop killall5 too? Not good indeed.
> >
> > We have two choices: either back it out or find a sane way to implement
> > killall5 with new kill -1 behaviour.
>
> Couldn't it just do:
>
> sigset_t new;
> sigset_t savemask;
> sigfillset (&new);
> sigprocmask (SIG_BLOCK, &new, &savemask);
>
> kill(-1, STOP);
> for(each proc with p.sid!=my_sid) kill(proc, sig);
> kill(-1, CONT);
>
> sigprocmask (SIG_SETMASK, &savemask, (sigset_t *) 0);
>
> ... in other words, block signals, do the killing, then unblock?
STOP cannot be blocked or trapped AFAIK.
--
vda
In article <[email protected]>,
Sean Hunter <[email protected]> wrote:
>On Mon, Dec 17, 2001 at 12:41:21PM -0200, vda wrote:
>> Hmm. Looking at killall5 source I see
>>
>> kill(-1, STOP);
>> I guess STOP will stop killall5 too? Not good indeed.
>>
>Couldn't it just do:
>
>sigprocmask (SIG_BLOCK, &new, &savemask);
>... in other words, block signals, do the killing, then unblock?
You can't block SIGSTOP and SIGKILL
Mike.
--
Deadlock, n.:
Deceased rastaman.
Doh!</slaps head>
Sean
On Mon, Dec 17, 2001 at 12:06:30PM +0000, Matthew Kirkwood wrote:
> On Mon, 17 Dec 2001, Sean Hunter wrote:
>
> > > Hmm. Looking at killall5 source I see
> > >
> > > kill(-1, STOP);
> > > for(each proc with p.sid!=my_sid) kill(proc, sig);
> > > kill(-1, CONT);
> > >
> > > I guess STOP will stop killall5 too? Not good indeed.
>
> > Couldn't it just do:
> [..]
> > ... in other words, block signals, do the killing, then unblock?
>
> SIGSTOP and SIGKILL can't be blocked.
>
> Matthew.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
[email protected] writes:
> On Monday 17 December 2001 05:01, Richard Gooch wrote:
> > Hi, all. To followup on the change in 2.5.1 which sends a signal to
> > the signalling process when send_pid==-1, I have a definate case where
> > the new behaviour is highly undesirable, and I would say broken.
> >
> > shutdown(8) from util-linux (*not* the version that comes with the
> > bloated monstrosity known as SysVInit) uses the sequence:
>
> Hi Richard, I'm using your new init and happy with it (thanks!).
> I am very willing to discuss other side of a coin (i.e. shutdown sequence),
> let's do it off the list.
>
> > kill (-1, SIGTERM);
> > sleep (2);
> > kill (-1, SIGKILL);
> >
> > to ensure that all processes not stuck in 'D' state are killed.
> >
> > With the new behaviour, shutdown(8) ends up killing itself. This is no
> > good, because the shutdown process doesn't complete (i.e. unmounting
> > of filesystems, calling sync(2) and good stuff like that).
>
> I don't use your shutdown, I found it possible to spawn a shell
> script in a new process group and use killall5 to term/kill
> everything except this process group. It works. (But yesterday I saw
> fsck again... something did not get umounted?) I can mail my scripts
> to you for a little discussion. Mail me.
You're welcome to use killall to do this, but I don't think you should
*have to*. What if /proc isn't mounted? But more importantly, I don't
think shutdown(8) should be broken by such a change.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Linus Torvalds wrote:
> > Argh, I hate this. I fail to see what progress a process could make if
> > it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
> > everything except my shell, and now I'll have to kill everything else
> > manually, one by one.
>
> I do agree, I've used "kill -9 -1" myself.
>
> However, let's see how problematic it is to try to follow it (in 2.5.x,
> not 2.4.x) and if people really complain.
>
> Count one for the complaints, but I want more to overrule a published
> standard.
Hi,
This change also breaks my shutdown script (Slackware 8.0).
This script contains:
if [ "$1" != "fast" ]; then # shutdown did not already kill all processes
killall5 -15
sleep 5
killall5 -9
fi
It never gets beyond that point, probably because the script itself is
zapped. According to killall5 manual the processes in its own session are
unaffected by this, but that doesn't seem to be entirely true.
Granted, reboots are rare with Linux, but having to fsck every time from
now on is not my notion of fun ;)
Regards,
Udo.
Note that I've reverted the kill(-1...) thing in my personal tree: so far
I've gotten a lot of negative feedback, and the change doesn't seem to
actually buy us anything except for conformance to a unclearly weasel-
worded standards sentence where we could be even more weasely and just say
that "self" is a special process from the systems perspective.
Linus
On Mon, 17 Dec 2001, Linus Torvalds wrote:
>
> Note that I've reverted the kill(-1...) thing in my personal tree: so far
> I've gotten a lot of negative feedback, and the change doesn't seem to
> actually buy us anything except for conformance to a unclearly weasel-
> worded standards sentence where we could be even more weasely and just say
> that "self" is a special process from the systems perspective.
>
> Linus
>
Isn't the de-facto standard that:
kill -<sig> -1
... should send the signal to everyone but the one executing the call?
For years, the "quick way" to shut down a Unix system was:
kill -TERM -1
sync
kill -KILL -1
sync
umount -a
... hit power switch...
Eliminating the ability to shut down a system in a few seconds is
gonna make a lot of persons unhappy --especially if one has to run
the RH kiddie scripts that take forever......
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
Santa Claus is coming to town...
He knows if you've been sleeping,
He knows if you're awake;
He knows if you've been bad or good,
So he must be Attorney General Ashcroft.
Andries:
The new POSIX 1003.1-2001 is explicit about what kill(-1,sig)
is supposed to do. Maybe we should follow it.
Linus:
Note that I've reverted the kill(-1...) thing in my personal tree: so far
I've gotten a lot of negative feedback, and the change doesn't seem to
actually buy us anything except for conformance to a unclearly weasel-
worded standards sentence where we could be even more weasely and just say
that "self" is a special process from the systems perspective.
Well, maybe you are too pessimistic, but I do not disagree
with your action (since I cannot easily see a better one).
There have been two discussion fragments: firstly people that muttered
that it is a pity when "kill -9 -1" kills their shell.
I do not care, especially since we got the reports that that also
happens on Digital UNIX and on Solaris.
And secondly people that complain that now their shutdown sequence
is broken. That is more serious: it became difficult for a program
other than init to handle the shutdown.
"self" is a nice and clean concept; I do not see anything clean
it could be replaced with. I wonder what other systems do.
Andries
> On Fri, Dec 14, 2001 at 05:34:48PM +0000, [email protected] wrote:
>
> > + * POSIX (2001) specifies "If pid is -1, sig shall be sent to all processes
> > + * (excluding an unspecified set of system processes) for which the process
> > + * has permission to send that signal."
> > + * So, probably the process should also signal itself.
> > - if (p->pid > 1 && p != current) {
> > + if (p->pid > 1) {
>
> Argh, I hate this. I fail to see what progress a process could make if
> it kills everything _and_ itself. I frequently use "kill -9 -1" to kill
> everything except my shell, and now I'll have to kill everything else
> manually, one by one.
>
> If a process wants to commit suicide too, why doesn't it just do that
> after?
This is the best suggestion I've yet seen. kill() is defined at C library
level so glibc can do the self kill at the end if POSIX_ME_HARDER is
in the environment