Fix a rare but potential pre-exec child process deadlock in subprocess on POSIX systems when marking file descriptors inheritable on exec in the child process. This bug appears to have been introduced in 3.4 with the inheritable file descriptors support.
This also changes Python/fileutils.c `set_inheritable` to use the "slow" two `fcntl` syscall path instead of the "fast" single `ioctl` syscall path when asked to be async signal safe (by way of being asked not to raise exceptions). `ioctl` is not a POSIX async-signal-safe approved function.
ref: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
(cherry picked from commit c1e46e94de)
Co-authored-by: Alexey Izbyshev <izbyshev@users.noreply.github.com>
* bpo-16500: Allow registering at-fork handlers
* Address Serhiy's comments
* Add doc for new C API
* Add doc for new Python-facing function
* Add NEWS entry + doc nit
Don't call _Py_open() from _close_open_fds_safe() because it is call just after
fork(). It's not good to play with locks (the GIL) between fork() and exec().
Use instead _Py_open_noraise() which doesn't touch to the GIL.
* _Py_open() now raises exceptions on error. If open() fails, it raises an
OSError with the filename.
* _Py_open() now releases the GIL while calling open()
* Add _Py_open_noraise() when _Py_open() cannot be used because the GIL is not
held
* Don't call the garbage collector with an exception set: it causes an
assertion to fail in debug mode.
* Enhance also error handling if allocating an array for the executable list
failed.
* Add an unit test for 4 different errors in the _posixsubprocess module.
when we have a way to get an actual list of all open fds from the OS.
Fixes issue #21618: The subprocess module would ignore fds that were
inherited by the calling process and already higher than POSIX resource
limits would otherwise allow. On systems with a functioning /proc/self/fd
or /dev/fd interface the max is now ignored and all fds are closed.
misleading error message stating that args[0] did not exist when
either the cwd or executable keyword arguments specified a path that
did not exist.
It now keeps track of if the child got as far as preexec and reports it if
not back to the parent via a special "noexec" error message value in
the error pipe so that the cwd can be blamed for a failed chdir
instead of the exec of the executable being blamed instead.
The executable is also always reported accurately when exec fails.
Unittests enhanced to cover these cases.