Alexey Izbyshev <izbys...@ispras.ru> added the comment:
> * 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
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
