Apache/WSGI Deployment 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
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
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
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.
WSGIDaemonProcess parameter in Apache lets you specify an arbitrary
processes (in addition to
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.