Reputation: 571
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).
Popen.wait()
ffmpeg
.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
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
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