Roundup Tracker - Issues

Issue 2551405

classification
Missing locale .mo files create 500 error on uwsgi without further info
Type: behavior Severity: normal
Components: Versions: devel, 2.5.0
process
Status: new
:
: : rouilj, schlatterbeck
Priority: :

Created on 2025-05-23 07:08 by schlatterbeck, last changed 2025-05-23 07:08 by schlatterbeck.

Messages
msg8390 Author: [hidden] (schlatterbeck) Date: 2025-05-23 07:08
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).
History
Date User Action Args
2025-05-23 07:08:15schlatterbeckcreate