[patch] EAGAIN error when writing to stdout

[nielsen@…]

On certain systems (running FreeBSD 5.4, python 2.3 etc…) I get this error all over the place:

Oops...
Trac detected an internal error:

[Errno 35] Resource temporarily unavailable

If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team.

Go to http://trac.edgewall.com/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below.

TracGuide — The Trac User and Administration Guide
Python traceback

Traceback (most recent call last):
  File "/usr/local/lib/python2.3/site-packages/trac/core.py", line 525, in cgi_start
    real_cgi_start()
  File "/usr/local/lib/python2.3/site-packages/trac/core.py", line 520, in real_cgi_start
    dispatch_request(path_info, args, req, env)
  File "/usr/local/lib/python2.3/site-packages/trac/core.py", line 435, in dispatch_request
    module.run()
  File "/usr/local/lib/python2.3/site-packages/trac/Module.py", line 46, in run
    disp()
  File "/usr/local/lib/python2.3/site-packages/trac/Module.py", line 81, in display
    self.req.display(self.template_name)
  File "/usr/local/lib/python2.3/site-packages/trac/core.py", line 331, in display
    self.write(data)
  File "/usr/local/lib/python2.3/site-packages/trac/core.py", line 378, in write
    return sys.stdout.write(data)
IOError: [Errno 35] Resource temporarily unavailable

The EAGAIN error should be caught. I'll attach a patch which fixes this problem.

[nielsen@…]

Patch which fixes the issue.

[Matthew Good]

Well, apparently FreeBSD's threading library automatically sets stdin and stdout to be non-blocking. I guess for C apps this wouldn't be a big deal since it'd only occur when you explicitly use threading, but since threading support in Python needs compiled in at the interpreter level this will always happen, regardless of whether the Python app itself is threaded.

Since CGI doesn't use threading, and the FastCGI or mod_python shouldn't be using stdout, I think that it would be sufficient for the CGI script to simply ensure that stdout is in blocking mode.

I believe that the following should do the trick, though I don't have a FreeBSD box to test it on:

cgi-bin/trac.cgi

@@ -15 +15 @@
 #
 # Author: Jonas Borgstr\uffffm <jonas@edgewall.com>
 
+import fcntl
+import os
+import sys
+
+def make_blocking(fd):
+    flags = fcntl.fcntl(fd, fcntl.F_GETFL)
+    if flags & os.O_NONBLOCK:
+        fcntl.fcntl(fd, fcntl.F_SETFL, flags & ~os.NONBLOCK)
+
 try:
     from trac.web import cgi_frontend
+    make_blocking(sys.stdin.fileno())
+    make_blocking(sys.stdout.fileno())
     cgi_frontend.run()
 except Exception, e:
     print 'Content-Type: text/plain\r\n\r\n',

[nielsen@…]

The patch doesn't apply on 0.8.x but I added your function and calls to trac.cgi and tested it. And, yes, this fixes the problem, thanks.

There's just a small typo in the patch: The second 'NONBLOCK' should be 'O_NONBLOCK'.

[Matthew Good]

Oops, I applied it locally, but since the sockets were already blocking on my machine it didn't run the line with the typo.

I'll combine these changes with the fixes for the stdin/stdout mode on Windows from #2052.

[nielsen@…]

That's great. Thanks.

[Matthew Good]

Ok, this should be fixed in [2260]