[Zope-dev] Re: [Zope] select.error: (4, 'Interrupted system call')

Jeremy Hylton jeremy@zope.com
Wed, 22 Aug 2001 13:12:15 -0400 (EDT)


>>>>> "JZ" == John Ziniti <jziniti@speakeasy.org> writes:

  >> John; Could you put this in the collector....
  JZ> Sure

I'm following up here, perhaps a little late.  John also reported this
bug in the Python bug tracker at SF.  I think he's right that asyncore
should catch EINTR and retry.  The right thing, in probably every
case, is to retry the select.  Thus, asyncore should be doing it and
not burdening every application (like Zope) with the need to add a
try/except. 

  JZ> Let me apologize and clarify.  Zope *does* crash if there is no
  JZ> try/except around the select, at least in the way that I think
  JZ> of crashing.  It needs to restart itself in any case.

Right.

  JZ> I am pretty sure EINTR *is* the problem, but when I add the try,
  JZ> it seems that a later call to accept() throws EWOULDBLOCK (??).
  JZ> This doesn't crash Zope, but brings down the FCGI and PCGI
  JZ> Servers.

Did you retry the select() or did you do something else?

  JZ> See the trace below.  I added the print 'system.error' line
  JZ> inside the except block.

The last error in your traceback is quite interesting:

  JZ> ------ 2001-08-16T13:16:01 PROBLEM(100) ZServer warning: server
  JZ> accept() threw EWOULDBLOCK ------ 2001-08-16T13:16:01 ERROR(200)
  JZ> ZServer uncaptured python exception, closing channel
  JZ> <select-trigger (pipe) at 248024> (exceptions.OSError:[Errno 11]
  JZ> Resource temporarily unavailable
  JZ> [/u01/zope/lib/python2.1/asyncore.py|poll|101]
  JZ> [/u01/zope/lib/python2.1/asyncore.py|handle_read_event|389]
  JZ> [/u01/zope/Zope-2.4.0-src/ZServer/medusa/thread/select_trigger.py|handle_read|77]
  JZ> [/u01/zope/lib/python2.1/asyncore.py|recv|341]
  JZ> [/u01/zope/lib/python2.1/asyncore.py|recv|523])

John Heintz has been seeing a similar problem with the latest beta of
ZEO 1.0.  It doesn't really make sense that select() reports the
socket is ready for reading, but recv() fails with EWOULDBLOCK.

Is it easy to reproduce this error?  Could you isolate a test case
that I could run locally?  Also, what platform are you running on?

Jeremy