You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fd 4 read 0 comes from the following code in the parent (pid 8000)
observing completion of child (pid 7858) FD_CLOEXEC processing:
## Wait for kid to get to its exec() and see if it fails.
_close $self->{SYNC_WRITER_FD};
my$sync_pulse = _read $sync_reader_fd;
_close $sync_reader_fd;
Testing in C code, I found NetBSD's rules for pending signals at execve() are
different than other kernels I tested. I've reported this at https://gnats.netbsd.org/58268. I can modify the test case to accept both
behaviors, since the point of the test isn't to check kernel behavior.
IPC::Run could partially hide the kernel-specific behavior by retrying SIGTERM.
I'm not inclined to do that, since there's no guarantee that an arbitrary child
process will treat two copies of SIGTERM the same way as one copy. Other
opinions?
Example pass w/ NetBSD 9.3: https://www.cpantesters.org/report/5dd40274-f12f-11ee-be45-8b0dec80b09a
Example fail w/ NetBSD 10.0: https://www.cpantesters.org/report/efbcc1aa-f5f1-11ee-a642-ee3ed50263fb
I've reproduced this via GitHub Actions (uses bsd workflow fixes that I need to polish for inclusion):
https://github.com/nmisch/IPC-Run/actions/runs/8873497758/job/24359422461
I plan to investigate a fix like this:
The text was updated successfully, but these errors were encountered: