I am wishing someone's seen this -

I am running django-compressor, benefiting from the lessc setup to render/compress the less into CSS around the file. It really works perfectly when invoked in the development server, however when run underneath apache+mod_wsgi it's consistently coming back a mistake.

To debug this, I've run the precise command the filter is invoking because the www-data user (which is understood to be the wsgi user within the WSGIDaemonProcess directive) and verified it works properly, including permissions to read the files it's adjusting.

I've also compromised around the django-compressor code in compressor/filters/base.py on that system, also it appears that ANY command trying to obtain invoked gets a returncode of -6 following the proc.communicate() invocation.

I am wishing someone's seen this before - or it rings some bell. It really works fine about this machine outdoors from the apache+mod_wsgi process (i.e. running the procedure like a dev server) too. I am simply not obvious on which may be obstructing the subprocess.Popen() invocations.

Are you currently using Python 2.7.2 by accident?

That version of Python introduced a bug which cause fork() in sub interpreters to fail:

http://bugs.python.org/issue13156

You'll have to pressure WSGI application to operate in primary Python interpreter from the process by setting:

WSGIApplicationGroup %{GLOBAL}

If running multiple Django programs you have to make sure that just the one affected has this configuration directive put on it else you'd cause all Django programs to operate in a single interpreter which is not possible because of how Django configuration works.