kill tox process does not kill running commands

[dajose]

Tox seems to not being sending the sigterm signal back to the subprocess it is driving.

This can be reproduced with this configuration, and killing the tox process.

tox.ini

[tox]
skipsdist = True

[testenv:papa]
commands =
    {envpython} {toxinidir}/papa.py

papa.py

from time import sleep
while True:
   sleep(1)
   print('papa')

from a terminal run

tox -e papa

and on another, search the process and kill it, for example:

diazdavi@darker:/tmp$ ps -aux | grep tox
diazdavi  779128  6.3  0.1 114196 22588 pts/0    S+   17:00   0:00 /usr/bin/python3 /usr/local/bin/tox -e papa
diazdavi  779140  0.5  0.0  26912  9500 pts/0    S+   17:00   0:00 /tmp/.tox/papa/bin/python papa.py
diazdavi  779178  0.0  0.0  17664  2700 pts/2    S+   17:00   0:00 grep --color=auto tox
diazdavi@darker:/tmp$ kill 779128

The first terminal will keep showing the prints :(

[gaborbernat]

This is a side effects of how sub processes work. If you kill the tox process there's no way you can stop the subprocess. There's no way to mark a subprocess daemon to die with the parent.

[dajose]

@gaborbernat you are right, it is not the "natural" way of handling a parent process being killed. And if it were a SIGKILL signal there would be nothing to be done.

A kill by default sends a SIGTERM, and that you can capture on python using signal. For example (using the same papa.py script above)

import signal
signal.signal(signal.SIGTERM, signal.getsignal(signal.SIGINT))

from subprocess import run
run(['python3', 'papa.py'])

That code above is not my best work, but it takes a SIGTERM and make the parent process handle as it was a Ctrl+C. Which would in turn kill the children.

I wonder if we can reopen the issue, calling it a bug was my mistake. It is most likely an enhance request.

[dajose]

I forgot to mention, I found this while debugging an issue presented while running tox in a Jenkins instance... it seems that jenkins sends a SIGTERM on a job abort (jenkinsci/jenkins#3414)... and my tox commands are continuing to run after the abort.