This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author izbyshev
Recipients gregory.p.smith, izbyshev, nanjekyejoannah, pablogsal, pitrou, serhiy.storchaka, vstinner
Date 2018-12-23.19:12:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1545592366.23.0.0770528567349.issue35537@roundup.psfhosted.org>
In-reply-to
Content
> * cwd

posix_spawn_file_actions_addchdir_np() is scheduled for glibc 2.29 [1] and exists in Solaris [2] (though its suffix indicates that it's "non-portable" -- not in POSIX). POSIX also has a bug for this [7].

> * start_new_session

posix_spawnattr_setflags() supports POSIX_SPAWN_SETSID in musl [3] and glibc 2.26 [4] and is scheduled to be added into POSIX. Solaris also has POSIX_SPAWN_SETSID_NP.

> * pass_fds: there is not API to mark a fd as inheritable (clear O_CLOEXEC flag)

POSIX has a bug for this [5]. It's marked fixed, but the current POSIX docs doesn't reflect the changes. The idea is to make posix_spawn_file_actions_adddup2() clear O_CLOEXEC if the source and the destination are the same (unlike dup2(), which would do nothing). musl has already implemented the new behavior [6], but glibc hasn't.

Another alternative (also described in the POSIX bug report) is to remove O_CLOEXEC via a side-effect of posix_spawn_file_actions_adddup2() to a dummy descriptor and then dup2() it back again. This is not correct in general case -- record locks (fcntl(F_SETLK)) associated with the file referred to by the descriptor are released on the second dup2() -- but in our case those locks are not preserved for the new process anyway, so this is not a problem. I'm not aware of other correctness problems with this, but one needs to check for platforms where a file descriptor may have associated flags other than O_CLOEXEC (such flags would be cleared by dup2).

> For pipes like stdout=PIPE or stdout=fd, I didn't look yet how to implement that properly

You'd need to reimplement the corresponding logic from _posixsubprocess. Basically, posix_spawn_file_actions_adddup2() and posix_spawn_file_actions_addclose() do the job, but you need to avoid corner cases regarding low fds (0, 1, 2) that might have been reused for pipes.

I don't know correct solutions for close_fds. It is already hard: it's implemented in async-safe way only for Linux now (and only if /proc is available) or if /proc is not available and the brute-force implementation is used.

And of course, in theory you could implement any of the above by a helper binary as you did for prlimit.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17405
[2] https://docs.oracle.com/cd/E88353_01/html/E37843/posix-spawn-file-actions-addchdir-np-3c.html
[3] https://git.musl-libc.org/cgit/musl/commit/?id=bb439bb17108b67f3df9c9af824d3a607b5b059d
[4] https://www.sourceware.org/ml/libc-alpha/2017-08/msg00010.html
[5] http://austingroupbugs.net/view.php?id=411
[6] https://git.musl-libc.org/cgit/musl/commit/?id=6fc6ca1a323bc0b6b9e9cdc8fa72221ae18fe206
[7] http://austingroupbugs.net/view.php?id=1208
History
Date User Action Args
2018-12-23 19:12:47izbyshevsetrecipients: + izbyshev, gregory.p.smith, pitrou, vstinner, serhiy.storchaka, pablogsal, nanjekyejoannah
2018-12-23 19:12:46izbyshevsetmessageid: <1545592366.23.0.0770528567349.issue35537@roundup.psfhosted.org>
2018-12-23 19:12:46izbyshevlinkissue35537 messages
2018-12-23 19:12:45izbyshevcreate