You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo and believe that this is not a duplicate.
If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
OS version and name: any
Poetry version: 11.5
Link of a Gist with the contents of your pyproject.toml file:
Issue
When running a program through poetry run, subprocess.call is used to execute the command. This has the negative side effect of causing poetry to swallow all signals, making it difficult to wrap commands that depend on signals to be handled properly.
I think the behavior that poetry run should have is that the command provided is exec'd using the exceve syscall, which will replace the process and allow signals to be handled properly. This is similar to the behavior of similar utilities, like bundle exec in ruby.
Poetry should play nice with other unix utilities.
Steps to reproduce
$ cd$(mktemp -d)
$ poetry init
$ go get -u github.com/ejholmes/sigp
$ sigp sleep 60 &
$ kill -TERM $!signal 15 received (terminated)signal 20 received (child exited)
$ poetry run sigp sleep 60 &
$ kill -TERM $!# notice that sigp doesn't print anything, because it didn't get the TERM signal
$ ps -A | grep sigp # zombie process now18862 ttys013 0:00.01 sigp sleep 60
Reacted by Michael Floering, philip trauner, Christopher Dignam, Maxim Koltsov, 이강욱 (Kangwook Lee), joe, Steve Dignam and Jeffrey Bian
AFAIK both subprocess.run() and subprocess.call() create subprocess. os.execve would be suffice.
And I think execve() should be a new default of poetry run. Maintaining an intermediate process between user shell and actual process gives you only burdens to care without good benefit.
I've noticed killing poetry processes with SIGTERM creates a status code of 143. While that error code does indicate graceful termination after receiving SIGTERM, why not just return 0?
Activity
drunkwcodes commentedon Mar 28, 2019
subprocess.run()is good for it. But supported platforms has to be updated to python 3.5+.floer32 commentedon Mar 28, 2019
I agree with OP that this is a great idea; should probably be a flag though, ie
poetry run --exec(short formpoetry run -xor something)simnalamburt commentedon Jul 18, 2019
AFAIK both
subprocess.run()andsubprocess.call()create subprocess.os.execvewould be suffice.And I think execve() should be a new default of
poetry run. Maintaining an intermediate process between user shell and actual process gives you only burdens to care without good benefit.digitalresistor commentedon Jul 23, 2019
https://github.com/bertjwregeer/vrun/blob/master/src/vrun/oscompat.py
Someone please steal that code... unfortunately on Windows you can't use
os.execve, so you have to use popen instead.joekohlsdorf commentedon Aug 7, 2019
poetry shellshould do the samebenjirewis commentedon Mar 30, 2023
I've noticed killing poetry processes with SIGTERM creates a status code of 143. While that error code does indicate graceful termination after receiving SIGTERM, why not just return 0?
github-actions commentedon Feb 29, 2024
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.