New daemon process started for each request when the <Directory> path is incorrect.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Setup mod_wsgi in daemon mode
2. Add a non-existant path to the <Directory>
3. Watch as each request fires up a new daemon

What is the expected output? What do you see instead?
The expected output, when specifying an non-existent path, would be some
sort of error/warning message ("The path you specified does not exist"). 
Instead, there is no warning or error, and the program seems to act
normally -- except the process and thread limits in the WSGIDaemonProcess
are ignored, and a new daemon is fired up for each request.  This makes
your application *crawl*.

What version of the product are you using? On what operating system?
mod_wsgi-2.1-1.fc9.x86_64

Original issue reported on code.google.com by luke.mac...@gmail.com on 17 Aug 2008 at 9:00

[GoogleCodeExporter]

More information required. In particular provide the actual Apache 
configuration snippets used relevant to how mod_wsgi was 
setup to handle specific requests. Also provide the URL accessed and any 
details about the directories in the file system which 
is relevant. Finally, ensure LogLevel directory is set to 'debug' and provide 
any output in Apache error logs, both main and 
VirtualHost is present, relevant to the requests.

As is, the description doesn't make much sense as an incorrect path to the 
<Directory> directive by rights should mean that 
the request isn't even passed to mod_wsgi. This is because even if using 
WSGIScriptAlias with a RHS which doesn't exist, 
Apache should validate the RHS and finding it doesn't exist return a 404 
response without even passing it to mod_wsgi. The 
only time I have seen this process screwed up is when there are odd mod_rewrite 
rules also been applied to the request. This 
has yielded in the past:

  http://code.google.com/p/modwsgi/issues/detail?id=78

So, make sure configuration information you provide also lists any mod_rewrite 
rules that might be getting used in case that is 
causing an issue.

If WSGIScriptAlias isn't used and instead AddHandler/SetHandler inside a 
<Directory> directive is used, then if directory doesn't 
exist, then Apache should again by rights return a 404. Even if it does still 
get passed through to mod_wsgi, its checks should 
block it. Such checks are done though on Apache child worker side and not on 
daemon side and so wouldn't even affect 
daemon.

So, please provide more information so that issue can be investigated properly. 
If there is a problem, it isn't going to be 
because processes/threads option to WSGIDaemonProcess is being ignored, but 
more likely because daemon process is 
crashing. This should be evident in Apache error logs as there will be errors 
about segmentation faults. It is possible that a 
crash is occurring in error path where logging is being done as this has 
happened before, although case was fixed. Other 
option is that some user Python code is being loaded on daemon side and that is 
causing crash due to one of the documented 
shared library conflicts.

Original comment by Graham.Dumpleton@gmail.com on 18 Aug 2008 at 12:05

[GoogleCodeExporter]

To try and track down what poster may have been talking about, try a few test 
scenarios.

1. Use following where /tmp/test1/ directory doesn't exist.

WSGIScriptAlias /test1/ /tmp/test1/
WSGIDaemonProcess test1 threads=10 home=/tmp display-name=%{GROUP}
WSGIProcessGroup test1

<Directory /tmp/test1>
Order deny,allow
Allow from all
</Directory>

As expected, yields a 403 Forbidden response and error log:

[Fri Aug 29 17:25:33 2008] [error] [client ::1] client denied by server 
configuration: /tmp/test1

2. Use following where /tmp/test1/ directory doesn't exist.

WSGIScriptAlias /test1 /tmp/test1/foo.py
WSGIDaemonProcess test1 threads=10 home=/tmp display-name=%{GROUP}
WSGIProcessGroup test1

<Directory /tmp/test1>
Order deny,allow
Allow from all
</Directory>

As expected, yields a 403 Forbidden response and error log:

[Fri Aug 29 17:28:28 2008] [error] [client ::1] client denied by server 
configuration: /tmp/test1

3. Use following where /tmp/test1/ directory doesn't exist.

Alias /test1/ /tmp/test1/

WSGIDaemonProcess test1 threads=10 home=/tmp display-name=%{GROUP}
WSGIProcessGroup test1

<Directory /tmp/test1>
SetHandler wsgi-script
Options ExecCGI
Order deny,allow
Allow from all
</Directory>

As expected, yields a 403 Forbidden response and error log:

[Fri Aug 29 17:32:35 2008] [error] [client ::1] client denied by server 
configuration: /tmp/test1

So, at total loss as to what complaint was actually about. Marking as Invalid 
given don't know what to fix and poster hasn't 
provided further information.

Original comment by Graham.Dumpleton@gmail.com on 29 Aug 2008 at 7:35

• Changed state: Invalid