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

Brian Granger ellisonbg.net@gmail....
Tue Dec 2 14:39:05 CST 2008


Could be, but I really have no idea.

On Tue, Dec 2, 2008 at 11:31 AM, mark starnes
<m.starnes05@imperial.ac.uk> wrote:
> Hi,
>
> Could the problem be to do with my mixing of 32 and 64 bit operating
> systems?  I just ran into a problem with a routine that was compiled
> on the 32 bit machine; it threw an exception on the 64 bit machine....
>
> BR,
>
> Mark.
>
> Brian Granger wrote:
>> Just checked in Twisted and IPython and there are no os.kill's
>> anywhere in the core that would show up here.  That leaves:
>>
>> 1.  User code
>> 2.  Some other process.  Is there a chance that the engines are being
>> started using some batch system (like PBS) that ends up sending the
>> process signals?
>>
>> Brian
>>
>>
>>
>> On Mon, Dec 1, 2008 at 2:21 PM, Andrew Straw <strawman@astraw.com> wrote:
>>> 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...
>>>
>>> -Andrew
>>>
>>
>


More information about the IPython-user mailing list