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 > > 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? -- Takashi Yano <takashi.y...@nifty.ne.jp>
