I'm using Django 1.0, mod_wsgi 2.3 in daemon mode. My application is
hosted at Webfaction.
Sometimes (it is not deterministic) I get errors like:
[Sat Sep 27 01:51:06 2008] [error] [client 127.0.0.1] Premature end of
script headers: rek.wsgi
[Sat Sep 27 01:51:06 2008] [notice] child pid 15592 exit signal
Segmentation fault (11)
My apache is not running mod_python. It uses mpm-worker threads.
Apache conf is like:
(...)
WSGIDaemonProcess rek-prod user=xyz group=xyz processes=2 threads=1
maximum-requests=500 inactivity-timeout=7200 stack-size=524288 display-
name=%{GROUP}
(...)
<VirtualHost *:2867>
ServerName my-domain.xyz
WSGIProcessGroup rek-prod
WSGIScriptAlias / /home2/(...)/rek.wsgi
<Directory /home2/(...)/rek_project/>
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
User that apache is running is, say, 'xyz', same as set to
WSGIDaemonProcess directive.
I've set additional logging for wsgi (as described at
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques).
What I see is that output headers and output content are both empty (0
bytes).
Interesting is that the errors logged are appearing when daemon-
processes are reching max-limit. Saved files are:
size | date | filename
0 Sep 27 00:15 1222492508.42-26504-498.ocontent
136 Sep 27 00:15 1222492508.42-26504-498.oheaders
0 Sep 27 00:20 1222492841.42-26505-500.icontent
1813 Sep 27 00:20 1222492841.42-26505-500.iheaders
0 Sep 27 00:20 1222492841.42-26505-500.ocontent
136 Sep 27 00:20 1222492841.42-26505-500.oheaders
0 Sep 27 00:30 1222493410.86-26504-499.icontent
1813 Sep 27 00:30 1222493410.86-26504-499.iheaders
0 Sep 27 00:30 1222493410.86-26504-499.ocontent
136 Sep 27 00:30 1222493410.86-26504-499.oheaders
0 Sep 27 00:35 1222493743.3-9633-1.icontent
1813 Sep 27 00:35 1222493743.3-9633-1.iheaders
0 Sep 27 00:35 1222493743.3-9633-1.ocontent
0 Sep 27 00:35 1222493743.3-9633-1.oheaders
0 Sep 27 00:45 1222494313.46-26504-500.icontent
1813 Sep 27 00:45 1222494313.46-26504-500.iheaders
0 Sep 27 00:45 1222494313.46-26504-500.ocontent
136 Sep 27 00:45 1222494313.46-26504-500.oheaders
0 Sep 27 00:50 1222494648.64-10774-1.icontent
1813 Sep 27 00:50 1222494648.64-10774-1.iheaders
0 Sep 27 00:50 1222494648.64-10774-1.ocontent
0 Sep 27 00:50 1222494648.64-10774-1.oheaders
0 Sep 27 01:00 1222495215.96-11502-1.icontent
1813 Sep 27 01:00 1222495215.96-11502-1.iheaders
0 Sep 27 01:00 1222495215.96-11502-1.ocontent
0 Sep 27 01:00 1222495215.96-11502-1.oheaders
0 Sep 27 01:05 1222495558.97-11941-1.icontent
1813 Sep 27 01:05 1222495558.97-11941-1.iheaders
0 Sep 27 01:05 1222495558.97-11941-1.ocontent
0 Sep 27 01:05 1222495558.97-11941-1.oheaders
0 Sep 27 01:15 1222496119.36-12730-1.icontent
1813 Sep 27 01:15 1222496119.36-12730-1.iheaders
0 Sep 27 01:15 1222496119.36-12730-1.ocontent
0 Sep 27 01:15 1222496119.36-12730-1.oheaders
0 Sep 27 01:21 1222496460.87-13182-1.icontent
1813 Sep 27 01:21 1222496460.87-13182-1.iheaders
0 Sep 27 01:21 1222496460.87-13182-1.ocontent
0 Sep 27 01:21 1222496460.87-13182-1.oheaders
0 Sep 27 01:30 1222497021.53-13961-1.icontent
1813 Sep 27 01:30 1222497021.53-13961-1.iheaders
0 Sep 27 01:30 1222497021.53-13961-1.ocontent
0 Sep 27 01:30 1222497021.53-13961-1.oheaders
0 Sep 27 01:36 1222497362.97-14450-1.icontent
1813 Sep 27 01:36 1222497362.97-14450-1.iheaders
0 Sep 27 01:36 1222497362.97-14450-1.ocontent
0 Sep 27 01:36 1222497362.97-14450-1.oheaders
0 Sep 27 01:45 1222497924.66-15209-1.icontent
1813 Sep 27 01:45 1222497924.66-15209-1.iheaders
0 Sep 27 01:45 1222497924.66-15209-1.ocontent
0 Sep 27 01:45 1222497924.66-15209-1.oheaders
0 Sep 27 01:51 1222498265.33-15592-1.icontent
1813 Sep 27 01:51 1222498265.33-15592-1.iheaders
0 Sep 27 01:51 1222498265.33-15592-1.ocontent
0 Sep 27 01:51 1222498265.33-15592-1.oheaders
0 Sep 27 01:56 1222498563.45-16320-1.icontent
2300 Sep 27 01:56 1222498563.45-16320-1.iheaders
24720 Sep 27 01:56 1222498563.45-16320-1.ocontent
136 Sep 27 01:56 1222498563.45-16320-1.oheaders
0 Sep 27 01:56 1222498565.66-16794-1.icontent
2275 Sep 27 01:56 1222498565.66-16794-1.iheaders
3641 Sep 27 01:56 1222498565.66-16794-1.ocontent
127 Sep 27 01:56 1222498565.66-16794-1.oheaders
0 Sep 27 02:00 1222498840.89-16320-2.icontent
1813 Sep 27 02:00 1222498840.89-16320-2.iheaders
0 Sep 27 02:00 1222498840.89-16320-2.ocontent
136 Sep 27 02:00 1222498840.89-16320-2.oheaders
0 Sep 27 02:06 1222499167.12-16794-2.icontent
1813 Sep 27 02:06 1222499167.12-16794-2.iheaders
0 Sep 27 02:06 1222499167.12-16794-2.ocontent
136 Sep 27 02:06 1222499167.12-16794-2.oheaders
What can be read from the above is that after reaching count 500 (by
daemon process) there is a number of errors (premature end of script
headers in apache logs) causing that output headers are 0 length.
All the requests (iheaders) are same - from the application that is
monitoring my server every minute.
Additionally I sometimes see situations like:
1. After restart of wsgi daemon (by changing content of rek.wsgi) I
get segmentation fault
2. Then I change the code of my application (eg. I comment out
cache.set and cache.get lines)
3. I do restart of wsgi daemon again.
4. Everything works now
5. I'm changing the code of my application back
6. restart of daemon
7. I get segmentation fault this time
8. I'm adding logging to rek.wsgi
9. Everything works again
10. I remove logging from rek.wsgi (caching is on - everyting as in
point 1. above)
11. Everything works...
So.. this is very strange, unpredictable and not recurrent. Any ideas
what else can I check and how?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
