Author izbyshev
Recipients gregory.p.smith, izbyshev, nanjekyejoannah, pablogsal, pitrou, serhiy.storchaka, vstinner
Date 2019-01-13.21:50:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1547416238.3.0.854926028932.issue35537@roundup.psfhosted.org>
In-reply-to
Content
> * On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn() "file actions" fails, posix_spawn() succeed but the child process exits immediately with exit code 127 without trying to call execv(). If execv() fails, posix_spawn() succeed, but the child process exit with exit code 127.
> * The worst seems to be: "In my test on Ubuntu 14.04, ./python -c "import subprocess; subprocess.call(['/xxx'], close_fds=False, restore_signals=False)" silently returns with zero exit code."

To clarify, in the Ubuntu example only the parent process returns with zero exit code. The child exits with 127, so the behavior is the same as on FreeBSD, as demonstrated by check_call():

$ ./python -c "import subprocess; subprocess.check_call(['/xxx'], close_fds=False, restore_signals=False)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/subprocess.py", line 348, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/xxx']' returned non-zero exit status 127.

> According to Alexey Izbyshev, musl should be safe as well, but I don't know how to test musl on my Fedora, nor how to check if Python is linked to musl, nor what is the minimum musl version which is safe.

musl doesn't have an equivalent of __GLIBC__ macro by design as explained in its FAQ [1], and the same FAQ suggests to use something like "#ifndef __GLIBC__ portable_code() #else glibc_code()". So far musl-related fixes followed this advice (see PR 9288, PR 9224), but in this case it doesn't seem like a good idea to me. POSIX allows asynchronous error notification, so "portable" code shouldn't make assumptions about that, and technically old glibc and FreeBSD are conforming implementations, but not suitable as a replacement for _posixsubprocess.

Maybe we could use configure-time musl detection instead? It seems like config.guess has some support for musl[2], but it uses "ldd" from PATH and hence appears to work out-of-the-box only on musl-based distros like Alpine. See also [3].

Regarding the minimum musl version, in this case it's not important since the relevant change was committed in 2013[4], and given that musl is relatively young, such old versions shouldn't have users now. 

[1] https://wiki.musl-libc.org/faq.html
[2] https://github.com/python/cpython/blob/5bb146aaea1484bcc117ab6cb38dda39ceb5df0f/config.guess#L154
[3] https://github.com/RcppCore/Rcpp/pull/449
[4] https://git.musl-libc.org/cgit/musl/commit/?id=fb6b159d9ec7cf1e037daa974eeeacf3c8b3b3f1
History
Date User Action Args
2019-01-13 21:50:40izbyshevsetrecipients: + izbyshev, gregory.p.smith, pitrou, vstinner, serhiy.storchaka, pablogsal, nanjekyejoannah
2019-01-13 21:50:38izbyshevsetmessageid: <1547416238.3.0.854926028932.issue35537@roundup.psfhosted.org>
2019-01-13 21:50:38izbyshevlinkissue35537 messages
2019-01-13 21:50:38izbyshevcreate