Apache/WSGI Deployment Issues

Locale Issues

If deploying via Apache/WSGI, in EL7 (CentOS 7, RHEL7) there’s a serious problem which can occur if any non-ASCII characters are found in your filenames. Basically, by default the WSGI process will be launched with a $LANG of C, making ascii the default encoding for various things, including the filesystem encoding as reported by sys.getfilesystemencoding(). If you try and import any files with non-ASCII characters in the filename, you can end up with absurd errors like this in your logs:

UnicodeEncodeError: 'utf-8' codec can't encode character '\\udcc3' in position 7160: surrogates not allowed

This behavior is especially difficult to track down since it will NOT be repeatable in any unit tests, nor will it be repeatable when running the development test server - it’ll only ever show up in the WSGI deployment.

Currently Exordium doesn’t have a check for this - I’ll hope to eventually add that in - but for now just make sure that you’re specifying the following after your WSGIDaemonProcess line:

lang='en_US.UTF-8' locale='en_US.UTF-8'

Of course, replacing the encoding with the proper one for the data stored on your filesystem.

There may be some similar problems if more than one encoding is found in your system’s filenames - that’s another thing I have yet to investigate.

You can read a bit more on this problem here, FWIW: http://blog.dscpl.com.au/2014/09/setting-lang-and-lcall-when-using.html

It’s worth noting that this problem was discovered on CentOS 7. When deploying on Rocky 8, I’d kept those lang and locale lines in my WSGI config without really doublechecking that this was still necessary, so it’s possible that this might not be actually needed anymore.

Process Count

The WSGIDaemonProcess parameter in Apache lets you specify an arbitrary number of processes (in addition to threads). If processes is set to more than 1, problems can be encountered when setting preferences (such as library path, download URLs, live album display, etc). Namely, the preference change will often only be seen by the process in which it was changed, which can lead to some vexing behavior.

I believe the root of this problem is that the dynamic_preferences module probably uses a cache (presumably a builtin Django cache), and that cache must be configured properly so that multiple processes can share it. I have not actually investigated this, though. Given that my personal activity needs with Exordium are quite light, I’ve just made do with a single process.