Getting “(2)No such file or directory” errrors when running apache/django/mod_wsgi web site.

[Chintan Tank]

Since past 2 days I have been getting the following error -

(2)No such file or directory: mod_wsgi (pid=2709): Unable to connect
to WSGI daemon process 'my_site' on '/var/run/apache2/wsgi.
2688.2.1.sock' after multiple attempts.

Since it was working before, I dont know why the error has been
caused. I have tried following without success -

1. Providing WSGISocketPrefix http://www.mail-archive.com/pytho...@python.org/msg180917.html
2. Kill all the apache daemons manually & then restarting the
server.
3. I have made sure that the mod_wsgi exists in the location
pointed to in the httpd.conf

Any help or pointers towards this will be great.

I am at my wit's end, especially this was working just 2 days back & I
cant recall making any system updates. Not sure if this is relevant
but I did run apache & django dev server on this machine. But mostly
never in parallel.

P.S. My httpd.conf snippet

WSGIDaemonProcess my_site python-path=/usr/local/code/pinax/pinax-env/
lib/python2.6/site-packages threads=25 user=daemon group=daemon
WSGIProcessGroup my_site


WSGIScriptAlias / /usr/local/code/my_site/deploy/pinax.wsgi
#WSGISocketPrefix /var/run/apache2/wsgi


<Directory /usr/local/code/my_site/deploy>
Order deny,allow
Allow from all
</Directory>

<Directory /usr/local/my_site_db>
Order deny,allow
Allow from all
</Directory>

Please help.

[Carl Nobile]

I have seen this issue before it is usually caused by permission
changes in the path leading to the socket file. You can test this by
setting the socket file to be put into /tmp. If it starts to work
correctly check the path to the old location and be sure apache can
write to every directory in it.

~Carl

> --
> 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.
>
>

--
-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
carl....@gmail.com
-------------------------------------------------------------------------------

[Graham Dumpleton]

It is ability of Apache user to read files created, not write them. When being created the process is run as root, so no problem at that point.

That error can occur for other reasons as well.

On really bad Internet from my phone right now, so can't elaborate.

[Carl Nobile]

Below is a link to the docs where Graham gives some solutions to this issue.

http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets

~Carl

[Chintan Tank]

I actually did read up on all the issues docs & tried to use the plausible solutions as well.
In the ended up creating a folder in "/var/run/apache2" for the socket files. And then changing permissions to 755 & then doing chown. I know that this is not the ideal solution & if I had more time then I would have done what Graham D. suggested in this thread.

But Thanks guys for the help.

Thanks & Regards,

Chintan Tank
Software Developer
School of Library & Information Science
Indiana University, Bloomington.

http://www.cs.indiana.edu/~cdtank/

[Graham Dumpleton]

On 18 October 2010 03:31, Chintan Tank <tankc...@gmail.com> wrote:
> I actually did read up on all the issues docs & tried to use the plausible
> solutions as well.
> In the ended up creating a folder in "/var/run/apache2" for the socket
> files.

You had to recreate '/var/run/apache2' or are you saying you created a
new sub directory within that existing directory, and then changed
WSGISocketPrefix directive.

If you had to recreate /var/run/apache2, then possible you simply
deleted that directory when it wasn't meant to be.

There was an issue at one point where one of the Linux distributions
wanted to play with the permissions on /var/run/apache2 to lock it
down further, but their intended changes would have locked out Apache
user from accessing the WSGI socket files, which would have given
symptoms you saw. I believe they got convinced the change was wrong
and did it slightly differently so mod_wsgi would still work. Doesn't
mean that some other Linux distribution hasn't tried the same thing.

Did you do any operating system package updates just prior to when
this issue started?

What Linux distribution are you using?

Graham