[IPython-user] [0:execute]: IOError: [Errno 4] Interrupted system call

Andrew Straw strawman@astraw....
Mon Dec 1 16:21:22 CST 2008

Brian Granger wrote:
>> Sorry I don't have any specific information concerning your situation,
>> but as it's been a few days with no response, I figured I'd chime in. My
>> understanding is that an interrupted system call (EINTR) happens when a
>> system call (e.g. select(), fread(), fwrite(), and so on) is interrupted
>> by a signal that the kernel decides your thread is going to handle. The
>> correct behavior is to deal appropriately with the signal (possibly
>> ignoring it) and then repeat your system call.
> Yep, I think that is what is going on.  Is there a chance that the
> signal is anything other than EINTR?  I ask as that will help us track
> this down.
Sorry, I wasn't clear here. EINTR is the errno value that's returned
here. The signal could be anything.
>> I've found lots of code in the wild that is not robust to being
>> interrupted this way (including in core Python), but luckily very little
>> code that sends signals and thus interrupts code that way. So, I think
>> the best solution will be to find what is sending the signal and
>> eliminate it. Hopefully this will ring some bells with someone more
>> knowledgeable in the ipython internals than I. Also, are you running any
>> third party code that could be sending signals?
> There are a couple of possibilities:
> 1.  Something deep in the internals of Python itself.
> 2.  Something deep in Twisted
> 3.  It wouldn't be in IPython as we (as far as I know) are not sending
> any signals.
> 4.  Deep somewhere in user code that they are not aware of.
> My best guesses are Twisted or in user code.  I will look at Twisted
> to see if it sends signals anywhere.  Is it also possible that the
> kernel itself sends the signal?
I've never experienced the kernel sending unrequested signals other than
the usual things like SIGINT and SIGKILL... But I suppose it could be
configured to do so somehow.

My best guess is that this is more likely to be in user code than in
Twisted or the other sources you list. I suspect that if signals were
used as part of Python or Twisted, folks attempting to  use
non-EINTR-safe code (there's a lot of it) would've come screaming by
now. My relatively naive understanding of this stuff is that signals are
the blunt tool of inter-process communication and I see the Twisted crew
as more the fine surgeon types... But I haven't grepped for os.kill() in
the Twisted sources, either, so I could be wrong. Likewise I don't know
about IPython, but I'd be surprised if it was doing IPC via signals. If
it is, I'd suggest it be removed, as it will come back to haunt anyone
without non-EINTR-safe code.

It's debugging these types of things that turns my hair gray...


More information about the IPython-user mailing list