fcgi wrapper shouldn't report "Internal Error" on catching SystemExit

[matthew.johnston@…]

When trac is run under FastCGI 2.4.2 (with Apache 2.2.0, Python 2.4.2), it sometimes prints a traceback at the bottom after rendering pages (see below). As far as I can tell this is harmless, it's just that the trac.fcgi wrapper is catching all exceptions, including SystemExit which gets throw by sys.exit(). Adding a "except SystemExit: pass" in trac.fcgi gets rid of the tracebacks.
Perhaps it should check for an exitcode of 0, I'm not sure.

Traceback:

Oops...

Trac detected an internal error:

0

Traceback (most recent call last):
  File "/usr/local/share/trac/cgi-bin/trac.fcgi", line 20, in ?
    fcgi_frontend.run()
  File "/usr/local/stow/trac-0.9.3/lib/python2.4/site-packages/trac/web/fcgi_frontend.py", line 28, in run
    _fcgi.Server(_handler).run()
  File "/usr/local/stow/trac-0.9.3/lib/python2.4/site-packages/trac/web/_fcgi.py", line 1049, in run
    sock = self._setupSocket()
  File "/usr/local/stow/trac-0.9.3/lib/python2.4/site-packages/trac/web/_fcgi.py", line 994, in _setupSocket
    req.run()
  File "/usr/local/stow/trac-0.9.3/lib/python2.4/site-packages/trac/web/_fcgi.py", line 580, in run
    self._end(appStatus, protocolStatus)
  File "/usr/local/stow/trac-0.9.3/lib/python2.4/site-packages/trac/web/_fcgi.py", line 606, in _end
    sys.exit(appStatus)
SystemExit: 0

[anonymous]

Just to note, that line didn't work for me. I got it working, though I'm not sure if it'll mess other things up. I added the following

except Exception, SystemExit?: pass

just before the line:

except Exception, e:

This is me using fcgid, apache, and Trac 0.9.4

[bga@…]

SystemExit? patch for 0.9.4

[mgood]

Alright, I'll check this out.

[003.tmp@…]

I get the same with Trac v0.96 (and mod_fastcgi v2.4.2). However there is something I'm missing there: the suggested action will obviously suppress the error message, but the problem is that sys.exit() be called after each request. At least in my case that's what happening, and that means the program has to be restarted each time, leading to performance probably slightly worse than CGI.

[003.tmp@…]

Got it. Trac falls back to CGI if FastCGI fails because it is not properly configured.

That's good practice to "degrade well", however I think it would be useful to log the event so that users are made aware they are using CGI, not FastCGI.

[mgood]

Fixed in [3678]

[mgood]

#2139 has been marked as a duplicate.