[issue38435] Start the deprecation cycle for subprocess preexec_fn

Mark Mentovai added the comment: Another use case for preexec_fn: establishing a new controlling terminal, typically in conjunction with start_new_session=True. A preexec_fn may do something like os.close(os.open(os.ttyname(sys.stdin.fileno(), os.O_RDWR))) with discussion at

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: Another use case someone had for preexec_fn popped up today: prctl(PR_SET_PDEATHSIG, SIGTERM) -- ___ Python tracker ___

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: A worthwhile general suggestion on a new path forward for the mess of things between (v)fork+exec from Victor is over in https://bugs.python.org/issue42736#msg383869 TL;DR creating a subprocess.Preexec() recording object with specific interfaces for

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Serhiy Storchaka added the comment: Would not be more consistent with other parameters to name the new parameter "pgid" or "process_group"? And why not use None as default, like for user and group? -- nosy: +serhiy.storchaka ___ Python tracker

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: > "using Python is more portable than relying on a shell." Not in environments I use. :) There isn't an installed python interpreter that can be executed when deploying Python as an embedded interpreter such as anyone using pyoxidizer or similar. Plus

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Change by Alexey Izbyshev : -- nosy: +izbyshev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38435] Start the deprecation cycle for subprocess preexec_fn

STINNER Victor added the comment: I just created bpo-42738: "subprocess: don't close all file descriptors by default (close_fds=False)". -- ___ Python tracker ___

[issue38435] Start the deprecation cycle for subprocess preexec_fn

STINNER Victor added the comment: > Using an intermediate shell script wrapper that changes the rlimit and exec's > the actual process is also an alternative. IMO using Python is more portable than relying on a shell. I dislike relying on a shell since shells are not really portable (behave

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: Doing the code inspection of existing preexec_fn= users within our codebase at work is revealing. But those seem to be the bulk of uses. I expect this deprecation to take a while. Ex: if we mark it as PendingDeprecationWarning in 3.10, I'd still wait

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Change by Gregory P. Smith : -- pull_requests: +22786 pull_request: https://github.com/python/cpython/pull/23936 ___ Python tracker ___

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: signal.signal use case: Calls to signal.signal(x, y) to sometimes to set a non SIG_DFL behavior on a signal. SIGINT -> SIG_IGN for example. I see a lot of legacy looking code calling signal.signal in prexec_fn that appears to set SIG_DFL for the signals

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: I'm also seeing a lot of os.setpgrp() calls, though those are more likely able to use start_new_session to do setsid() as a dropin replacement. -- ___ Python tracker

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: Another preexec_fn use to consider: resource.setrlimit(resource.RLIMIT_CORE, (XXX, XXX)) Using an intermediate shell script wrapper that changes the rlimit and exec's the actual process is also an alternative. --

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: https://bugs.python.org/issue42736 filed to track adding Linux prctl() support. -- ___ Python tracker ___

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: PR up to add setpgid support. From what I've come across, some setpgid() users can use setsid() already available via start_new_session= instead. But rather than getting into the differences between those, making both available makes sense to allow for

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Change by Gregory P. Smith : -- keywords: +patch pull_requests: +22780 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23930 ___ Python tracker

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Mark Diekhans added the comment: calling setpgid() is a common post-fork task that would need to be an explicit parameter to Popen when preexec_fn goes away -- nosy: +diekhans ___ Python tracker

[issue38435] Start the deprecation cycle for subprocess preexec_fn

STINNER Victor added the comment: > We cannot provide a general do everything replacement and should not try. It > not possible. Well, I proposed a solution at: https://bugs.python.org/issue38417#msg354242 I know that this solution has multiple flaws, but a bad solution may be better than

[issue38435] Start the deprecation cycle for subprocess preexec_fn

Gregory P. Smith added the comment: With task specific arguments. cwd, start_new_session, group, extra_groups, user, etc.. We cannot provide a general do everything replacement and should not try. It not possible. -- ___ Python tracker

[issue38435] Start the deprecation cycle for subprocess preexec_fn

STINNER Victor added the comment: What is the recommanded way to replace preexec_fn? -- nosy: +vstinner ___ Python tracker ___ ___

[issue38435] Start the deprecation cycle for subprocess preexec_fn

New submission from Gregory P. Smith : subprocess's preexec_fn feature needs to enter PendingDeprecationWarning state in 3.9, to become a DeprecationWarning in 3.10, with a goal of removing it in 3.11. Rationale: We now live in a world full of threads, it is entirely unsafe to call back