Allow signaling a process by all its thread ids?

Allow signaling a process by all its thread ids?

[Simon Holm Thøgersen]

There is a bug report at https://bugs.launchpad.net/bugs/341239 where
the question is asked. Should it be possible to signal a process with
kill(2) by passing any of the thread ids belong to the process as
argument to kill?

Current behaviour allows that but the reporter argues that it shouldn't
be allowed by the following argument:

"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"


Simon Holm Thøgersen

Re: Allow signaling a process by all its thread ids?

[Alan Cox]

> 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.

If there was a specific explicit statement it might be an argument to add
a separate poxix_kill(), but the existing kill(2) interface the kernel
has is API, its been that way forever and you need *very* strong reasons
to make such changes that might break things.

You need to show that
- The current API breaks stuff
- The current API is absolutely invalid in posix
- Changing it improves the functionality and power of the kernel
- Changing it doesn't break existing applications

> 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.

Either your pid files are secure, or they are not. If collisions can
occur by accident I can cause them deliberately. If I can cause them
deliberately your system is insecure and you need to fix it.

Re: Allow signaling a process by all its thread ids?

[Chris Friesen]

Simon Holm Thøgersen wrote:
> There is a bug report at https://bugs.launchpad.net/bugs/341239 where
> the question is asked. Should it be possible to signal a process with
> kill(2) by passing any of the thread ids belong to the process as
> argument to kill?

Based on POSIX, from the perspective of the kernel I think that a tid
that is not a tgid should result in ESRCH for the kill() syscall.

Such a tid would however be valid for the tgkill or tkill syscalls.

Makes sense to me.  I suspect such a change would break a lot of
not-strictly-compliant programs though.

In the meantime, the pid file scenario could be modified to store both
the tid and pid (using userspace terminology now) and use the tgkill()
syscall.  It should be noted that tgkill() is linux-specific.

Chris

Re: Allow signaling a process by all its thread ids?

[Chris Friesen]

Alan Cox wrote:

> You need to show that
> - The current API breaks stuff
> - The current API is absolutely invalid in posix
> - Changing it improves the functionality and power of the kernel

I think an argument could be made for these.  A task is not necessarily
a process, and kill() is only defined to send a signal to one or more
processes.  This introduces potential problems if a) it is possible to
send a signal to an individual tid, and b) a tid can be reused in a
different process.

We already have the tgkill() syscall, which fixes the ambiguity by
specifying both the pid and tid.  This is what pthread_kill() uses under
the hood.  The fact that it was seen as necessary (back in 2.5)
indicates that there are problems with kill() as currently implemented.

> - Changing it doesn't break existing applications

This last one is the kicker.  As I mentioned in my other reply, I
suspect that making such a change would break a lot of (not-quite-POSIX)
applications that assume they can send a signal to particular threads
using kill().

I see analogies to the whole fsync() issue.

Chris