If we temporarily neuter the reader threads, we get the same behavior as under Fabric 1 - control returns to the run caller immediately, and the Python process can even exit without affecting the now orphaned child.I've determined that the child process does actually get assigned as a child of init even in this scenario, but Invoke still "blocks" to completion because of those reader threads.If one says pty=True, we get even stranger behavior where the subprocess appears to either not run or exit instantly (pending investigation - this is less critical for now).If one says pty=False (the default), the ampersand appears to be ignored the run call hangs out until the subprocess completes.
Under Invoke, this doesn't currently work because we keep much tighter track of the subprocess, including the reader threads hooked up to its pipes, which don't shut down until forced to by the subprocess closing those pipes.at least under Linux, this is equivalent to /bin/sh -c "shell command &", which (for reasons I don't fully understand yet) results in the subprocess being a child of PID 1/init, instead of the Python process as normal.Under Fabric 1's local(., capture=False) (the default behavior), it's possible to do local("shell command &") to background a shell command in a way that's completely disassociated from the parent Python process.Plus the normal adage that if one set of users is doing an unusual thing, there will be others, and I'd rather the software cope gracefully with this instead of surprising users. Roughly analogous to sourcing a shell script that uses & a bunch.Īn obvious counter-argument to this case is "use real process supervision" - but I've determined that my local users have a good-enough need for true "orphaned children" subprocesses that this falls under a legit, if corner, use case for a toolset like Invoke.
The tl dr use case is to have a (long running in their case, but that's actually orthogonal) Python process using Fabric 1 or Invoke to kick off subprocesses that then live outside the control of the main program. Kind of an odd duck, but this came out of an internal need at my dayjob and I think it's worth examining for public use.
0 kommentar(er)
