'premature end of script headers' not solved with the FAQ
Iván
with embed mode. I'm getting "Premature end of script headers:
test.wsgi" in the error log. I've read the FAQ and
ConfigurationIssues, and I think it's a sockets problem, but no idea
how to solve it.
I've tried "WSGISocketPrefix run/wsgi" and "WSGISocketPrefix /var/run/
wsgi" and the sockets are being created but when I "ls -al" I get the
following:
drwxr-xr-x 21 root root 4096 Nov 23 18:05 ..
..
srwx------ 1 apache root 0 Nov 23 18:24 wsgi.12235.25.1.sock"
I've even tried "WSGISocketPrefix /tmp/wsgi"!!!!
My config:
CentOS
Linux mindpulse.net 2.6.9-023stab051.2-enterprise #1 SMP Thu Sep 24
23:38:21 MSD 2009 i686 i686 i386 GNU/Linux
Server version: Apache/2.2.3
mod_wsgi 3.0 (compiled from source)
running on mediatemple.net dv 3.5 (dedicated server)
<vhost>
WSGIDaemonProcess sesestudio user=sesestudio threads=10 display-name=%
{GROUP} python-path=/var/www/vhosts/sesestudio.com.ar/mindpulse/ses-
estudio/bootstrap/lib/python2.4/site-packages
WSGIProcessGroup sesestudio
WSGIScriptAlias /ses /var/www/vhosts/sesestudio.com.ar/mindpulse/
test.wsgi
<test.wsgi>
def application(environ, start_response):
start_response('200 OK', [('content-Type', 'text/html')])
return ['Hello World']
When I comment WSGIDaemonProcess and WSGIProcessGroup it works
flawlessly. What can I do to fix this?? Thanks in advance,
Iván
Graham Dumpleton
> with embed mode. I'm getting "Premature end of script headers:
> test.wsgi" in the error log. I've read the FAQ and
> ConfigurationIssues, and I think it's a sockets problem, but no idea
> how to solve it.
>
> I've tried "WSGISocketPrefix run/wsgi" and "WSGISocketPrefix /var/run/
> wsgi"
with WSGISocketPrefix. Not sure where you got that idea. The FAQ says:
"""Q: Why am I seeing the error message 'premature end of script
headers' in the Apache error logs.
A: If using daemon mode, this is a symptom of the mod_wsgi daemon
process crashing when handling a request. You would probably also see
the message 'segmentation fault'. See answer for question about
'segmentation fault' above.
This error message can also occur where you haven't configured Apache
correctly and your WSGI script file is being executed as a CGI script
instead."""
So, no mention of the socket issues, which will manifest as totally
different problem.
> and the sockets are being created but when I "ls -al" I get the
> following:
>
> drwxr-xr-x 21 root root 4096 Nov 23 18:05 ..
> ..
> srwx------ 1 apache root 0 Nov 23 18:24 wsgi.12235.25.1.sock"
> I've even tried "WSGISocketPrefix /tmp/wsgi"!!!!
>
>
> My config:
> CentOS
> Linux mindpulse.net 2.6.9-023stab051.2-enterprise #1 SMP Thu Sep 24
> 23:38:21 MSD 2009 i686 i686 i386 GNU/Linux
> Server version: Apache/2.2.3
> mod_wsgi 3.0 (compiled from source)
> running on mediatemple.net dv 3.5 (dedicated server)
>
>
> <vhost>
> WSGIDaemonProcess sesestudio user=sesestudio threads=10 display-name=%
> {GROUP} python-path=/var/www/vhosts/sesestudio.com.ar/mindpulse/ses-
> estudio/bootstrap/lib/python2.4/site-packages
> WSGIProcessGroup sesestudio
> WSGIScriptAlias /ses /var/www/vhosts/sesestudio.com.ar/mindpulse/
> test.wsgi
>
>
> <test.wsgi>
> def application(environ, start_response):
> start_response('200 OK', [('content-Type', 'text/html')])
> return ['Hello World']
>
>
> When I comment WSGIDaemonProcess and WSGIProcessGroup it works
> flawlessly. What can I do to fix this?? Thanks in advance,
LogLevel info
in the Apache configuration and restart Apache.
Tail the Apache error log file and make a request.
Then capture all output in Apache error log file related to the
request and post it here.
There are a couple of possibilities of why you are having problems as
documented.
1. You are loading mod_python at same time and one of the other is
using static library for Python causing daemon process to crash.
2. You have SELinux enabled and it is prohibiting daemon mode from
working properly.
Lets start with the actual content of error log for the request, not
just a single extract as you quote, but all the lines triggered by the
request so can see them and comment.
Also indicate what version of Python you are using. Your python-path
suggests 2.4, however if mod_wsgi not actually compiled against 2.4
and you are forcing it to use 2.4 site-packages directory, that itself
can cause problems due to mixing of Python versions.
As guide, post output from running:
ldd mod_wsgi.so
for compiled mod_wsgi module file.
Graham
杨小勇
when I upgrade mod_wsgi2.5 to mod_wsgi2.6 , the problem gone, so it will be the bug of mod_wsgi2.5 I think
you alse can try compile the newest mod_wsig
Hope it can work
--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To post to this group, send email to mod...@googlegroups.com.
To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
--
+---------------------------------+
| .... #### #### #### .... |
| .... #### #### #### .... |
| .... #### #### #### .... |
| #### #### .... #### #### |
| #### #### .... #### #### |
| #### #### .... #### #### |
| .... #### .... #### .... |
| .... #### .... #### .... |
| .... #### .... #### .... |
| #### .... #### .... #### |
| #### .... #### .... #### |
| #### .... #### .... #### |
| .... #### .... #### .... |
| .... #### .... #### .... |
| .... #### .... #### .... |
+------------------------------+
-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=
Eric_yang
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==
Graham Dumpleton
>
> when I upgrade mod_wsgi2.5 to mod_wsgi2.6 , the problem gone, so it will be
> the bug of mod_wsgi2.5 I think
>
> you alse can try compile the newest mod_wsig
I don't believe there was a issue with mod_wsgi 2.4 either but that it
was some how related to how it had been built on your system or some
other factor.
It needs to be investigated and last thing we want is for it to just
go away as then don't know what actual cause for it may be.
Graham
Graham Dumpleton
script headers' error message appear?
There was a case where someone was getting behaviour that suggested
their operating system was screwing up and thinking it had connected
on UNIX socket where server side never saw the connection arrive.
Tweaks were made in 3.0 to ensure default Apache timeout got triggered
in this case to at least unblock the Apache process, which would have
hung. It getting stuck and then recovering would have presented as
'Premature end of script headers' error.
How long before that message would have come out would have been
dictated by value of the Timeout directive in your Apache
configuration. What do you have Timeout directive set to in Apache
configuration? Have you fiddled it so it isn't the default 300
seconds?
FWIW, that area of code in mod_wsgi hadn't changed for quite a long
time. So, had to be operating system, with only other possibility
being that Apache Runtime Library had been screwed up in some way.
That or mod_wsgi was compiled against different APR to what was
actually being used although that is probably unlikely.
Graham
Iván
On Nov 24, 8:11 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/11/24 Graham Dumpleton <graham.dumple...@gmail.com>:
>
>
>
> > 2009/11/24 Iván <raskov...@gmail.com>:
I'll follow what you asked for in order:
The ErrorLog was set to info and the only line I get when using it in
daemon mode is (after graceful restart)
[Wed Nov 25 13:00:18 2009] [error] [client 190.247.74.168] Premature
end of script headers: ses-estudio.wsgi
if I run it in embedded mode I get:
[Wed Nov 25 13:06:38 2009] [info] [client 190.247.74.168] mod_wsgi
(pid=7784, process='', application='sesestudio.com.ar|/ses'): Loading
WSGI script '/var/www/vhosts/sesestudio.com.ar/mindpulse/ses-
estudio.wsgi'.
and it works fine. This is when I set "WSGISocketPrefix /var/run/wsgi"
if not I get:
[Wed Nov 25 13:11:10 2009] [error] [client 190.247.74.168] (13)
Permission denied: mod_wsgi (pid=11290): Unable to connect to WSGI
daemon process 'sesestudio' on '/etc/httpd/logs/wsgi.12235.114.1.sock'
after multiple attempts.
Maybe this is why I got confused earlier.
My python version is "Python 2.4.3"
> ldd /usr/lib/httpd/modules/mod_wsgi.so
libpython2.4.so.1.0 => /usr/lib/libpython2.4.so.1.0 (0x0039c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0097c000)
libdl.so.2 => /lib/libdl.so.2 (0x001c4000)
libutil.so.1 => /lib/libutil.so.1 (0x00111000)
libm.so.6 => /lib/libm.so.6 (0x00134000)
libc.so.6 => /lib/libc.so.6 (0x001c8000)
/lib/ld-linux.so.2 (0x00ab4000)
It takes around 20 seconds to appear and my apache Timeout is set to
20! I've tried changing it to 40 and now it's around 42 seconds... I
guess my mississippies are a bit off xD What else should I try? Thanks
a lot,
Iván
Graham Dumpleton
If it is and since it is on a publicly accessible box I might trouble
you to give me access so I can investigate.
The one other time this issue has come up, and which triggered
changing how timeouts handled, was an intermittent problem and not
reproducible.
If providing access is okay, contact me off list about it.
Would really like to understand this one a bit better as is baffling
me at present if it is the same issue as last time.
Graham
2009/11/26 Iván <rask...@gmail.com>:
TheDeadOne
> Hi, I can't make WSGi work on daemon mode. It works perfectly well
> test.wsgi" in the error log.
I have the same problem. Is any solutions?
Graham Dumpleton
As there are various causes, we first need to ensure you have
eliminated the known causes.
1. What is the Apache configuration you are using for mod_wsgi?
2. What is the URL you are using to make requests against the application?
3. Do you have an existing AddHandler for .py extension denoting it is
a cgi-script?
4. Have you disabled use of mod_python in same Apache installation?
5. Have you disable SELinux extensions?
6. Have you tried with a hello world WSGI application rather than some
fat Python web application/framework with lots of dependencies?
Graham
TheDeadOne
> 2009/12/18 TheDeadOne <thedead...@mail.ru>:
Sorry. My mistake:
> /usr/local/apache2/bin/httpd -V
Server version: Apache/2.2.11 (Unix)
Server built: Apr 14 2009 12:48:52
Server's Module Magic Number: 20051115:21
Server loaded: APR 1.2.8, APR-Util 1.2.8
Compiled using: APR 1.2.8, APR-Util 1.2.8
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_FLOCK_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/usr/local/apache2"
-D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
>
Graham Dumpleton
> On 18 дек, 12:33, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
>> 2009/12/18 TheDeadOne <thedead...@mail.ru>:
>>
>> > On 24 ноя, 10:41, Iván <raskov...@gmail.com> wrote:
>> >> Hi, I can't make WSGi work on daemon mode. It works perfectly well
>> >> with embed mode. I'm getting "Prematureend of script headers:
>> >> test.wsgi" in the error log.
>>
>> > I have the same problem. Is any solutions?
>>
>> As there are various causes, we first need to ensure you have
>> eliminated the known causes.
>>
>> 1. What is the Apache configuration you are using for mod_wsgi?
>>
>> 2. What is the URL you are using to make requests against the application?
>>
>> 3. Do you have an existing AddHandler for .py extension denoting it is
>> a cgi-script?
>>
>> 4. Have you disabled use of mod_python in same Apache installation?
>>
>> 5. Have you disable SELinux extensions?
>>
>> 6. Have you tried with a hello world WSGI application rather than some
>> fat Python web application/framework with lots of dependencies?
>>
>> Graham
>
> Sorry. My mistake:
That doesn't answer any of the questions I asked. :-(
Graham
TheDeadOne
> That doesn't answer any of the questions I asked. :-(
>
> Graham
>
>
Problem was with apache. It was build with no thread support.
1. I didn't understand question. What actually did you want to know?
Httd.conf file content?
2. Something like http://10.18.4.245/mysite/test. I'm use mod_wsgi
with Django.
3. No.
4. Yes.
5. My OS is FreeBSD.
6. No, I tried Django.
Jason Garber
Problem was with apache. It was build with no thread support.
1. I didn't understand question. What actually did you want to know?
Httd.conf file content?
2. Something like http://10.18.4.245/mysite/test. I'm use mod_wsgi
with Django.
3. No.
4. Yes.
5. My OS is FreeBSD.
6. No, I tried Django.
--
Graham Dumpleton
>>
>> That doesn't answer any of the questions I asked. :-(
>>
>> Graham
>>
>>
>
> Problem was with apache. It was build with no thread support.
If you have solved the issue then fine, but there should be no issue
in respect of whether Apache itself is compiled for threaded versus
non threaded MPM, ie., worker vs prefork MPM.
On the other hand, if the underlying Apache run time libraries have
not been compiled with threading awareness then there would, but your
messages indicate that Apache was at least running. If APR was not
compiled with threading then mod_wsgi probably wouldn't even load and
Apache would fail to start, so lack of threading in APR can't be the
issue either as you were indicating that you were getting an error
when a request was being handled.
So, you obviously had something wrong in your setup, but what it was
is still debatable as insufficient information to tell.
Graham
> 1. I didn't understand question. What actually did you want to know?
> Httd.conf file content?
> 2. Something like http://10.18.4.245/mysite/test. I'm use mod_wsgi
> with Django.
> 3. No.
> 4. Yes.
> 5. My OS is FreeBSD.
> 6. No, I tried Django.
>
Mark Sapiro
- embedded mode worked fine, but daemon mode would hang and eventually
time out with 500 Premature end of script headers and no other log
output from Apache or the application. This is on CentOS 5 with These
RPM installs
httpd.i386 2.2.3-31.el5.centos.2
installed
httpd-devel.i386 2.2.3-31.el5.centos.2
installed
mod_python.i386 3.2.8-3.1
installed
python.i386 2.4.3-19.el5
installed
python-devel.i386 2.4.3-19.el5
installed
mod_wsgi 3.1 was built from source.
The problem turned out to be a mod_python conflict. I finally stumbled
across this in InstallationIssues
----------------------------------------------------------------------------------------------
Incompatible ModPython Versions
The dual loading of mod_python and mod_wsgi together has only been
tested and verified as working for mod_python 3.3.1. It is possible
that mod_python 3.2.X may also work, but older mod_python versions
2.7.X and 3.1.X may give problems.
In particular, it has been noted that dual loading of mod_python 3.1.4
will cause mod_wsgi daemon mode to fail. This occurs because older
mod_python versions setup threads differently when initialising the
Python interpreter. This appears to cause the mod_wsgi daemon
processes to deadlock on the Python GIL at startup. This would be
evident through any request to a WSGI application delegated to that
daemon process appearing to hang and the browser client having to
timeout.
----------------------------------------------------------------------------------------------
In spite of my mod_python being 3.2.8 which "may also work", as soon
as I stopped loading it, mod_wsgi daemon mode started working.