Suriname0
Suriname0

Reputation: 571

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!

Upvotes: 1

Views: 258

Answers (2)

Suriname0
Suriname0

Reputation: 571

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.

Upvotes: 0

10se1ucgo
10se1ucgo

Reputation: 71

Does the same thing occur when shell=False? You'll have to point to the direct path of the executable when using shell=False.

Upvotes: 1

Related Questions