[issue34566] pipe read sometimes returns EOF but returncode is still None

[Martin Panter]

Martin Panter  added the comment:

You probably only need to call "wait" once. That blocks the thread until it 
gets a result, so it is more CPU-efficient than calling "poll" in a busy loop.

Since you open a separate pipe for "stderr" in script.py, but don't do anything 
with it, there could be a deadlock with the child writing to the stderr pipe 
versus the parent reading from "stdout" or waiting for the exit status.

I guess your script is an approximation of the "sos" application. I don't have 
time to understand everything it is trying to do, but I added some comments at 
.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34566] pipe read sometimes returns EOF but returncode is still None

[pmoravec]

pmoravec  added the comment:

> The "poll" method does not wait for the child to exit. Normally you use the 
> "wait" method in this situation. I suspect this is a bug in the application, 
> not in Python.

Thanks for clarification. Could you please confirm what code change in that 
script is safe, then?

1) looping "while p.poll() == None   pass" to really ensure some status is 
returned.

2) calling p.wait() before p.poll()

>From a blackbox perspective, I would expect either to provide similar fixing 
>mechanism of my script. But as we call this code snippet concurrently, for 
>random commands that randomly terminates with random outcome / status, can't 
>either fix attempt cause e.g. a deadlock?

Thanks in advance for help / advice.

(just for context if it matters: the snippet is from 
https://github.com/sosreport/sos/blob/master/sos/utilities.py#L158 where the 
sos_get_command_output method is called concurrently by more threads)

--
nosy: +pmoravec

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34566] pipe read sometimes returns EOF but returncode is still None

[Martin Panter]

Martin Panter  added the comment:

The "grep" process may be closing its end of the pipe before it exits. Or if 
Grep leaves the pipe open when it exits, the OS may close the pipe before it 
makes the child exit status available. Either way, I suspect "p.stdout.read()" 
returns an empty string indicating the pipe is closed, but "p.poll()" returns 
None because the exit status is not yet ready. Even if it is the OS closing the 
pipe after the child exits, I doubt there is any guarantee about when that 
happens relative to the child's exit status becoming available.

The "poll" method does not wait for the child to exit. Normally you use the 
"wait" method in this situation. I suspect this is a bug in the application, 
not in Python.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34566] pipe read sometimes returns EOF but returncode is still None

[Marcel Plch]

Change by Marcel Plch :


--
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34566] pipe read sometimes returns EOF but returncode is still None

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34566] pipe read sometimes returns EOF but returncode is still None

[Marcel Plch]

Marcel Plch  added the comment:

original downstream issue - https://bugzilla.redhat.com/show_bug.cgi?id=1623070

--
title: pipe read sometimmes returns EOF but returncode is still None -> pipe 
read sometimes returns EOF but returncode is still None

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com