[PATCH] Cygwin: kill(1): skip kill(2) call if '-f -s -' is used

[Christian Franke]

Takashi Yano wrote:
> On Tue, 15 Apr 2025 11:02:37 +0200
> Christian Franke wrote:
>> Hi Takashi,
>>
>> Takashi Yano wrote:
>>> Hi Christian,
>>>
>>> On Fri, 11 Apr 2025 16:46:07 +0200
>>> Christian Franke wrote:
>>>> In rare cases, '/bin/kill -f PID' hangs because kill(2) is always tried
>>>> first. With this patch, this could be prevented with '/bin/kill -f -s -
>>>> PID'.
>>> I wonder why kill(2) hangs. Do you have any idea?
>> Sorry no. I observed this in early (Cygwin 3.5.4) testing of stress-ng
>> for ITP, but could no longer reproduce it.
>>
>> Here are tests which currently (3.7.0-0.51.gd35cc82b5ec1) ignore but not
>> hang kill(pid, SIGKILL):
>>
>> stress-ng --mprotect 1 -t 5 -v
>> stress-ng --priv-instr 1 -t 5 -v
>> stress-ng --sigchld 1 -t 5 -v
>> stress-ng --sigsegv 1 -t 5 -v
>>
>> Run this in another window to see that child processes are left behind:
>>
>> killall -v -9 stress-ng; sleep 4; taskkill /F /T /IM stress-ng.exe
>>
>> For a minimal testcase regarding --priv-instr, see:
>> https://sourceware.org/pipermail/cygwin/2025-March/257726.html
> I could finally fix this issue. See:
> https://cygwin.com/pipermail/cygwin-patches/2025q2/013696.html

Thanks - I will test it soon.


>
>>> If kill(2) hangs in some cases, shouldn't we fix that
>>> rather than patching to kill(1)?
>> Of course. This feature was intended as a first step for an 'onboard'
>> tool for the CI tests suggested by Jon Turney. A second step could be an
>> --all option to replace 'taskill' or 'pskill'.
> Do you think we still need this patch even though the issue
> above has been fixed?

Possibly not. Let's forget the patch for now.

-- 
Thanks,
Christian