Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #2763
| From | Pierre GM <pierregmcode@gmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Trapping the segfault of a subprocess.Popen |
| Date | 2011-04-07 01:44 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <b5ea8afc-0dba-48d8-ae4c-55d79d5cbe06@1g2000yqq.googlegroups.com> (permalink) |
| References | <5adc9111-e7a5-4486-9809-f6a74f96a965@i14g2000yqe.googlegroups.com> <pan.2011.04.06.23.58.02.172000@nowhere.com> |
On Apr 7, 1:58 am, Nobody <nob...@nowhere.com> wrote: > On Wed, 06 Apr 2011 02:20:22 -0700, Pierre GM wrote: > > I need to run a third-party binary from a python script and retrieve > > its output (and its error messages). I use something like > >>>> process = subprocess.Popen(options, stdout=subprocess.PIPE, > > stderr=subprocess.PIPE) > >>>> (info_out, info_err) = process.communicate() > > That works fine, except that the third-party binary in question doesn't > > behave very nicely and tend to segfaults without returning any error. In > > that case, `process.communicate` hangs for ever. > > Odd. The .communicate method should return once both stdout and stderr > report EOF and the process is no longer running. Whether it terminates > normally or on a signal makes no difference. > > The only thing I can think of which would cause the situation which you > describe is if the child process spawns a child of its own before > terminating. In that case, stdout/stderr won't report EOF until any > processes which inherited them have terminated. I think you nailed it. Running the incriminating command line in a terminal doesn't return to the prompt. In fact, a ps shows that the process is sleeping in the foreground. Guess I should change the subject of this thread... > > I thought about calling a `threading.Timer` that would call > > `process.terminate` if `process.wait` doesn't return after a given > > time... But it's not really a solution: the process in question can > > sometimes take a long time to run, and I wouldn't want to kill a > > process still running. > > I also thought about polling every x s and stopping when the result of > > a subprocess.Popen(["ps","-p",str(initialprocess.pid)], > > stdout=subprocess.PIPE) becomes only the header line, but my script > > needs to run on Windows as well (and no ps over there)... > > It should suffice to call .poll() on the process. In case that doesn't > work, the usual alternative would be to send signal 0 to the process (this > will fail with ESRCH if the process doesn't exist and do nothing > otherwise), e.g.: > > import os > import errno > > def exists(process): > try: > os.kill(process.pid, 0) > except OSError, e: > if e.errno == errno.ESRCH: > return False > raise > return True OK, gonna try that, thx. > You might need to take a different approach for Windows, but the above is > preferable to trying to parse "ps" output. Note that this only tells you > if /some/ process exists with the given PID, not whether the original > process exists; that information can only be obtained from the Popen > object.
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
Trapping the segfault of a subprocess.Popen Pierre GM <pierregmcode@gmail.com> - 2011-04-06 02:20 -0700
Re: Trapping the segfault of a subprocess.Popen Nobody <nobody@nowhere.com> - 2011-04-07 00:58 +0100
Re: Trapping the segfault of a subprocess.Popen Terry Reedy <tjreedy@udel.edu> - 2011-04-06 23:12 -0400
Re: Trapping the segfault of a subprocess.Popen Pierre GM <pierregmcode@gmail.com> - 2011-04-07 01:45 -0700
Re: Trapping the segfault of a subprocess.Popen Pierre GM <pierregmcode@gmail.com> - 2011-04-07 01:44 -0700
csiph-web