Bug 81951 - EINTR for commands.getoutput()
Summary: EINTR for commands.getoutput()
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: python (Show other bugs)
(Show other bugs)
Version: phoebe
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 79579
TreeView+ depends on / blocked
 
Reported: 2003-01-15 18:25 UTC by Harald Hoyer
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-03 09:56:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Harald Hoyer 2003-01-15 18:25:28 UTC
commands.getoutput() does 
#define EINTR            4      /* Interrupted system call */

This doesn't make any sense to me..

  File "./netconfpkg/NCDevice.py", line 282, in save
    broadcast = commands.getoutput('ipcalc --broadcast ' + \
  File "//usr/lib/python2.2/commands.py", line 44, in getoutput
    return getstatusoutput(cmd)[1]
  File "//usr/lib/python2.2/commands.py", line 54, in getstatusoutput
    text = pipe.read()
IOError: [Errno 4] Interrupted system call

Comment 1 Mihai Ibanescu 2003-01-17 20:54:55 UTC
Not sure I understand - what is the problem?

Comment 2 Harald Hoyer 2003-01-20 10:55:57 UTC
  File "//usr/lib/python2.2/commands.py", line 54, in getstatusoutput
    text = pipe.read()
IOError: [Errno 4] Interrupted system call

seems like pipe.read() gets interrupted ... this must not happen!

Comment 3 Mihai Ibanescu 2003-01-21 13:14:42 UTC
Why don't you try-except it? This is what you're supposed to do anyway - there
are plenty of other problems that can happen and could raise IOError, besides
EINTR. You do that in a C program - why can't you do it in python?

It's arguable if python, as a high-level language, should hide or propagate this
error upstream - but exception handling is usually a good practice.



Comment 4 Harald Hoyer 2003-01-21 13:19:15 UTC
it is correct that I should catch the exceptions.. I did, and always wondered
why the execution failed there and then... this is strange behaviour, cause 1
minute later it workx.. do you want a testcase?

Comment 5 Mihai Ibanescu 2003-01-21 13:22:19 UTC
Sure, please attach it. I'd like to see how python 1.5.2 behaves, as well as
python 2.2.2 on pre-Phoebe.

Comment 6 Mihai Ibanescu 2003-01-31 17:39:38 UTC
Harald, does this still happen?

Comment 7 Harald Hoyer 2003-02-03 09:56:59 UTC
no, thx... haven't seen that. Must have been the kernel.


Note You need to log in before you can comment on or make changes to this bug.