Re: Syscall kill() can send signal to thread ID

Cambda Zhu
2022-09-24T03:16:47Z

> On Sep 24, 2022, at 05:21, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> "cambda@linux.alibaba.com" <cambda@linux.alibaba.com> writes:
>
>>> On Sep 22, 2022, at 23:33, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>>
>>> cambda@linux.alibaba.com writes:
>>>
>>>> I found syscall kill() can send signal to a thread id, which is
>>>> not the TGID. But the Linux manual page kill(2) said:
>>>>
>>>> "The kill() system call can be used to send any signal to any
>>>> process group or process."
>>>>
>>>> And the Linux manual page tkill(2) said:
>>>>
>>>> "tgkill() sends the signal sig to the thread with the thread ID
>>>> tid in the thread group tgid. (By contrast, kill(2) can be used
>>>> to send a signal only to a process (i.e., thread group) as a
>>>> whole, and the signal will be delivered to an arbitrary thread
>>>> within that process.)"
>>>>
>>>> I don't know whether the meaning of this 'process' should be
>>>> the TGID? Because I found kill(tid, 0) will return ESRCH on FreeBSD,
>>>> while Linux sends signal to the thread group that the thread belongs
>>>> to.
>>>>
>>>> If this is as expected, should we add a notice to the Linux manual
>>>> page? Because it's a syscall and the pids not equal to tgid are not
>>>> listed under /proc. This may be a little confusing, I guess.
>>>
>>> How did you come across this? Were you just experimenting?
>>>
>>> I am wondering if you were tracking a bug, or a portability problem
>>> or something else. If the current behavior is causing problems in
>>> some way instead of just being a detail that no one really cares about
>>> either way it would be worth considering if we want to maintain the
>>> current behavior.
>>>
>>> Eric
>>
>> I have found I can cd into /proc/tid, and the proc_pid_readdir()
>> uses next_tgid() to filter tid. Also the 'ps' command reads the
>> /proc dir to show processes. That's why I was confused with kill().
>>
>> And yes, I'm tracking a bug. A service monitor, like systemd or
>> some watchdog, uses kill() to check if a pid is valid or not:
>> 1. Store service pid into cache.
>> 2. Check if pid in cache is valid by kill(pid, 0).
>> 3. Check if pid in cache is the service to watch.
>>
>> So if kill(pid, 0) returns success but no process info shows on 'ps'
>> command, the service monitor could be confused. The monitor could
>> check if pid is tid, but this means the odd behavior would be used
>> intentionally. And this workaround may be unsafe on other OS?
>>
>> I'm agreed with you that this behavior shouldn't be removed, in case
>> some userspace applications use it now.
>
> As has already been mentioned using pids and api's like kill is
> fundamentally racy. We try and to keep from reusing pids too quickly.
> Unfortunately what we have is that on average there will be some time
> between pid reuse not an kind of worst case guarantee.
>
> We have slowly been introducing techniques into linux allow combatting
> that. A directory processes directory in proc that you have open will
> never point to another process even after the pid is reused. Similarly
> we have pidfd that will associate with a specific process and will not
> associate with any other process even if the processes pid is reused.
>
> That is we have userspace pid value reuse, but we don't reuse struct pid
> in the kernel.
>
> Unfortunately I don't think there is anything that allows these races to
> be addressed in a portable manner.
>
> Eric

I got it. Thank you!

Regards,
Cambda