Suriname0 Suriname0 - 6 months ago 32
Python Question

Subprocess call stopping asynchronously-executed Python parent process

The following shell session demonstrates the behavior I am seeing:

[user@compname python-test]$ cat test.py
#!/usr/bin/env python
import subprocess
from time import sleep
proc = subprocess.Popen("ffmpeg", stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True)
print "Starting process: " + str(proc)
status = proc.poll()
while status is None:
print "Process still running."
sleep(0.01)
status = proc.poll()
print "Status: " + str(status)
[user@compname python-test]$ python test.py
Starting process: <subprocess.Popen object at 0x7f2893f27150>
Process still running.
Process still running.
Status: 1
[user@compname python-test]$ python test.py &
[4] 6976
[user@compname python-test]$ Starting process: <subprocess.Popen object at 0x7ffa0ea82150>
Process still running.
Process still running.
[4]+ Stopped python test.py
[user@compname python-test]$ ps
PID TTY TIME CMD
4684 pts/101 00:00:00 python
4685 pts/101 00:00:00 ffmpeg
7183 pts/101 00:00:00 ps
14385 pts/101 00:00:00 bash


As you can see, when the simple test Python program is run normally, it completes successfully. When it is run asynchronously (using
&
), the Python process is stopped as soon as the subprocess call is complete (and
poll()
would return a non-
None
value).


  1. The same behavior occurs when using
    Popen.wait()

  2. The behavior is unique to
    ffmpeg
    .

  3. Both the Python process and
    ffmpeg
    are ending up stopped, as seen in the call to
    ps
    .



Can someone help me detangle this behavior? I don't see anything in the documentation for the
subprocess
module, bash's
&
operator, or
ffmpeg
that would explain this.

The Python version is 2.6.6, bash is GNU bash version 4.1.2(1)-release (x86_64-redhat-linux-gnu), ffmpeg is version 3.0.1-static.

Thank you for any help!

Answer

I've discovered that ffmpeg blocks itself when run asynchronously. A mailing list revealed that using nohup avoids the problem. See here for those interested.

Comments