On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
posix_spawn(p) returns before the spawned process is fully up and running. As a
result, the spawned process can fail to receive signals. The attached test case
illustrates the problem. It spawns a sleep process and then tries to kill it.
On exit, the sleep process is still running.
The following excerpts from the strace output show the issue: The SIGTERM signal
is sent after the main program has forked a subprocess (and posix_spawnp has
returned), but before the forked subprocess has exec'd the sleep process:
559 32069 [main] spawn_test 4125 vfork: stub called
257 48437 [main] spawn_test 4125 dofork: 4126 = fork()
754 9511 [main] spawn_test 4126 dofork: 0 = fork()
66 48503 [main] spawn_test 4125 kill0: kill (4126, 15)
44 9555 [main] spawn_test 4126 find_exec: find_exec (/usr/bin/sleep)
42 10835 [main] spawn_test 4126 spawnve: spawnve (/usr/bin/sleep, sleep,
0x8000281A0)
45 3149 [main] sleep 4126 child_info::ready: signalled 0x164 that I was
ready
6475 21055 [main] spawn_test 4126! child_info::sync: pid 45028, WFMO
returned 0, exit_code 0x103, res 1
--- Process 45028 (pid: 4126) thread 41444 created
I just took a look at the source, and I see that posix_spawn was taken from
FreeBSD. Does FreeBSD have the same problem? Should applications just be aware
of this issue and insert a sleep after posix_spawn before sending signals?
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
