howto solve "Premature end of script headers"?
Aljosa Mohorovic
"Premature end of script headers: project.wsgi"
Aljosa Mohorovic
Graham Dumpleton
> anybody knows why this happens and how to solve this problem?
> "Premature end of script headers: project.wsgi"
In short, this is caused when the mod_wsgi daemon process exits before
an active request completes. The error message is generated from the
Apache server child process which is proxying the request through to
the mod_wsgi daemon process.
Premature exit of the mod_wsgi daemon process can happen for a few reasons.
1. The mod_wsgi daemon process crashes.
This can occur for various reasons including shared library version
discrepancies, buggy C extension modules, or C extension modules for
Python which haven't been coded to work properly in Python sub
interpreters.
A crash can usually be detected by the presence of a 'Segmentation
Fault' or similar error message in the main Apache error log file. If
the issue is reproducible, ie., a specific request causes it, then you
can always just monitor the daemon processes when you make the request
and see if they vanish.
Also, you can ensure that in Apache configuration you set Apache log
level to at least 'info'. Ie.,
LogLevel info
This should be done at global Apache scope and in virtual hosts
affected if it was being explicitly set in the virtual host as well.
By setting the additional logging information you will get additional
log messages about when processes are restarting and whether it was
deliberate or whether it just crashed.
For the case of C extension modules causing problems due to not
working in a sub interpreter, one may be able to avoid issues by
forcing WSGI application to run in main interpreter within the
processes.
2. The maximum-requests option is being used with daemon process group
but when this is reached an restart scheduled there is a long running
request that doesn't complete within the shutdown timeout period and
so process forcibly shutdown.
3. The inactivity-timeout option is being used and due to no long
running requests returning any response in time or process deadlock,
this is triggered and those requests still don't complete within the
shutdown timeout period and so process forcibly shutdown.
4. WSGI script file is touched and triggers a daemon process restart,
but again active requests prevent process shutting down cleanly.
5. User code or actual user sends signal to daemon process to trigger
restart, but again active requests prevent process shutting down
cleanly.
Key to working out which of these it may be is to get that extra
logging enabled, plus for you to post the mod_wsgi configuration
snippet from Apache configuration file so can see how you are setting
up the mod_wsgi daemon process. If you are using certain options, such
as maximum-requests with very low value for amount of traffic
received, you could be exacerbating chances of issues occurring if you
have many long running requests.
Graham