Yesterday I was debugging a new deployment under uwsgi (behind apache aka httpd on redhat) which failed with a 500 error without any further information. Took me a long time and I resorted to print debugging to find the cause.

It turned out that the local templates in the tracker (in the locale directory) were not translated, i.e., the .mo files were missing.

By default the i18n framework will try to compile the .mo files but when they're not writeable it can't. But of course when deploying behind a webserver we do not want anything to be writeable by the webserver user.

This might be related to issue2551225, seems the error-handling is sub-optimal in wsgi.

Note that normal tracebacks make it to the uwsgi log in my setup. So if there was a traceback I should have seen it. Instead I got nothing at all.

This happens inside RequestDispatcher in cgi/wsgi_handler.py which in turn calls the Client constructor in cgi/client.py and proceeds to call client.main which in turn calls client.inner_main.

inner_main calls
- self.determine_user
- self.determine_context
- self.determine_language
all inside a try/except clause.

It looks like it never comes back from determine_language but this might be due to an ignored IOError in the try/except:

            except IOError:
                # IOErrors here are due to the client disconnecting before
                # receiving the reply.
                pass

So we probably should have more error-checking here, the assumption that IOError is only due to a client disconnect seems to be wrong. Note that this may also be the root-cause of issue2551225 where it seems we're also ignoring an I/O error (generated from a different execution path, though).

Hi Ralf,

I pushed changeset:   8630:9311bb32ddf0
which changed the exception handling. It's a small change and passed CI.
Can you pull it and see if it helps.

I haven't tried reproducing issue2551225, but if I am reading it correctly,
there should be an error logged now.

The commit message is:

Changed exception handling in two places.

There is an inner try/except where I added the more specific
ConnectionAbortedError before the existing IOError
exception. ConnectionAbortedError should be what is returned (in
python 3) when writing on a closed connection caused by the client
going away. Unable to test though.

Then I set up IOError to log/report exception as it is
unexpected. This logs useful error for the issue.

In the outer try/except, I replaced outer IOError handler with
ConnectionAbortdError handler. Then I removed IOError handler and let
an IOError fall through the last resort exception handler.

For this specific translator issue, generating the html error message
also crashes because it is trying to translate it and translation
fails. So I wrap the cgitb.http call in try/except Exception and
logger.exception() the original exception so there is something useful
logged.

Thanks.

-- rouilj