kill(-1, ..) currently will try to signal kernel threads, which of
course won't die off even with SIGKILL, meaning that ESRCH will never be
returned. Instead, allow kill() to return ESRCH if the only processes
left are simply unkillable (kernel threads). This does not violate
POSIX which says that "an unspecified set of system processes" may be
excluded when killing -1.
Signed-off-by: Chris Spiegel <[email protected]>
---
(please CC replies to me)
There is a comment in signal.c which says that Linux's kill(-1, ..) does
something that is probably wrong and should be like BSD or SysV. Well,
this is a bit more like the modern BSDs (possibly SysV, I'm not familiar
with it), although we still don't kill the calling process, a choice I
agree with.
This isn't just a pathological fix, it's a problem I ran into with the
following code (from NetBSD's /sbin/reboot):
for (i = 1;; ++i) {
if (kill(-1, SIGKILL) == -1) {
if (errno == ESRCH)
break;
goto restart;
}
if (i > 5) {
warnx("WARNING: some process(es) wouldn't die");
break;
}
(void)sleep(2 * i);
}
So it fixes a real-world (my world, anyway) problem.
--- linux-2.6/kernel/signal.c.orig 2006-04-21 15:44:17.618784128 -0700
+++ linux-2.6/kernel/signal.c 2006-04-21 16:20:52.269454557 -0700
@@ -1156,7 +1156,8 @@ static int kill_something_info(int sig,
read_lock(&tasklist_lock);
for_each_process(p) {
- if (p->pid > 1 && p->tgid != current->tgid) {
+ if (p->pid > 1 && p->tgid != current->tgid &&
+ p->mm != NULL) {
int err = group_send_sig_info(sig, info, p);
++count;
if (err != -EPERM)
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
