Re: Kill system call

Linus Torvalds (torvalds@cs.helsinki.fi)
Fri, 22 Mar 1996 09:38:37 +0200 (EET)


> Theodore Ts'o said this, and I just had to respond:
> >
> > POSIX.1 states:
> >
> > 3.2.2.2 Description of kill()
> >
> > "...If sig is zero (the null signal), error checking is performed, but no
> > signal is actually sent. The null signal can be used to check the
> > validity of pid...."

Note that it does NOT say that to check the validity of the pid it has to
return zero.. Under linux too, you can check any PID with a kill(0), because
the error value differs.

> I have never understood 3.2.2.2 to mean that a null signal can be sent to
> detect the validity of a pid *as long as you have signal priveledges on
> that pid*. It seems at least that the INTENT of the null signal is to
> allow any process to determine if a pid exists.

Right. And that's exactly what it allows:

int exists(pid_t pid)
{
int ok = 1;
if (kill(pid, 0) < 0 && errno = ESEARCH)
ok = 0;
return ok;
}

So the linux kill() is fine for checking existence, and follows the INTENT just
dandy.

> Since 3.2.2.2 implies that this is acceptable, many people are assuming
> it works, and these programs will break on Linux.

No, only badly written tests break on linux. POSIX expressly states that
ESEARCH means that the process doesn't exist, so THAT is what you should check
against. POSIX also very expressly sais that EPERM means you don't have the
permissions to send a signal to the process, so if you get EPERM you know that
yes, the process exists, but I don't have the rights to signal it.

> In fact, Linux is the
> only OS I've heard of that treats the null signal this way. We should
> probably consider this broken -- and fix it.

Is it broken? It would be reasonably easy to fix, but do we really want to?

Linus