[Bug 341239] Re: kill(2) succeeds when no process corresponds to the given PID

[Jean-Paul Calderone]

Hi Simon,

I'm no expert in interpreting POSIX.  A casual (but careful) reading of
POSIX 1003.1-2004 suggests that this isn't the intended behavior.  It is
implied in a few places, most notably the getpid[1] documentation, that
a process has only one PID (by use of the definite article when
referring to it - ie, "the process ID").  The kill function[2] operates
on "a process or a group of processes".  It sends a signal "to the
process whose process ID is equal to pid".  Combined with the previous
point, this suggests there should be only one process ID which can be
passed to kill to send a signal to a particular process.

It may be that POSIX is weakly worded enough that either allowing or
disallowing this behavior is valid.  I think that allowing it is a
violation of POSIX, but I can find no single, explicit, direct statement
in POSIX to back this up.

There is at least one other argument to disallow this behavior even if
it is not technically illegal.  Consider the traditional, widespread
convention of pid files.  This behavior drastically reduces their
utility, as it greatly increases the chance of PID collisions, a case in
which it is difficult to automatically (that is, without human
intervention) recognize that a pid file no longer corresponds to a
running process which created it.  This is the case in which I
encountered the behavior - when it repeatedly caused services not to
restart because they encountered a thread of another process and
misinterpreted it to mean the service was already running.

I hope this is convincing.  If not, what kind of argument would be?

[1]: http://www.opengroup.org/onlinepubs/009695399/functions/getpid.html
[2]: http://www.opengroup.org/onlinepubs/009695399/functions/kill.html

-- 
kill(2) succeeds when no process corresponds to the given PID
https://bugs.launchpad.net/bugs/341239
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.