Recently I had a mysterious error cropping up on a Satchmo Store I set up for a client. Every so often I would have an HTTP 500 error with the error log indicating that a template could not be read because the specified charset wasn't available. I edited the Django template loader code to produce more information and only managed to push the exception down into the Python source code.

str = codecs.open(filepath, encoding="utf-8").read()
File "/opt/python2.6/lib/python2.6/codecs.py", line 865, in open
    file = __builtin__.open(filename, mode, buffering)
LookupError: unknown encoding: ANSI_X3.4-1968

The template that was being opened was valid UTF-8 and even stranger - as the same user and using the same virtualenv as the WSGI app I can open a file specifying an ANSI_X3.4-1968 encoding.

It occurred to me that it must be problem with the environment somehow so I spent some time reading the WSGI documentation. Eventually I changed one line in my wsgi config for the app and resolved my problem. The configuration:

    WSGIDaemonProcess sitename user=sitename threads=1 display-name=%{GROUP}
    WSGIProcessGroup sitename
    WSGIApplicationGroup sitename
    # Previous setting:
    # WSGIApplicationGroup %{GLOBAL}

If I understand correctly all my wsgi applications configured using %{GLOBAL} were sharing the same interpreter. Somehow another process must be messing up the state of the interpreter somehow - using WSGIApplicationGroup with a value forces this application to run in its own sub-interpreter and this cleared up my problem. What I don't have is any insight into why my original error was occuring. Any thought?