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

mark starnes m.starnes05@imperial.ac...
Tue Dec 2 03:58:34 CST 2008


I'm not sending signals as far as I know.  I will remove
all non essential imports in my code, today, to see if it helps.

There are two modules I'm not sure of.  pypar (my original choice
for a python/MPI interface) and a library for controlling hardware
via usb.  I'll remove them today and see if anything happens.

Best regards,

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