Problem with daemon mode on Apache2.4

[r van dam]

On my old server with apache2.2 I use mod_wsgi in daemon mode without problems. I use this configuration in the virtual host part of httpd.conf:

WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25
WSGIProcessGroup stacaravan
WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py

On my new server I use Apache2.4 with mod_wsgi-4.3.2
Without daemon mode everything works fine, but with daemon mode I got this error:
[wsgi:error] [pid 13199] (13)Permission denied: [client 81.58.150.99:58714] mod_wsgi (pid=13199): Unable to connect to WSGI daemon process 'stacaravan' on '/tmp.13194.0.2.sock'., referer:

I solved this by making a /var/run/apache2 directory with 755 permission, and use the WSGISocketPrefix run/apache2 directive (Is this the right way to solve?)

When I add "WSGIProcessGroup stacaravan" to the httpd.conf of the virtual server I get the following error:
[wsgi:error] [pid 13915] [client 81.58.150.99:58850] No WSGI daemon process called 'stacaravan' has been configured: /home/stacaravan/stacaravan/stacaravan/wsgi.py

Any help is highly appreciated.

- OS debian 7.7
- Custombuild apache 2.4 (Directadmin)
- Mod_wsgi version: 4.3.2 (compiled)
- used with Django 1.7

[Graham Dumpleton]

What is ServerRoot directive set in your Apache configuration?

And what do you get if you run:

    apxs -q runtimedir

I have seen one case before where the socket prefix calculation was totally wrong and never did get to the bottom of it.

The code has:

    object->socket_prefix = DEFAULT_REL_RUNTIMEDIR "/wsgi";

    object->socket_prefix = ap_server_root_relative(p, object->socket_prefix);

DEFAULT_REL_RUNTIMEDIR is a compile time constant most likely derived from 'runtimedir' as shown by 'apxs'.

But then it goes through ap_server_root_relative() and that is what seemed to be screwing things up last time.

I could well be using it wrong and a strange configuration may be mucking things up.

So if can know what those values are, may give a clue.

Graham

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To post to this group, send email to mod...@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

[r van dam]

Thank you for your reply!

The ServerRoot is set to "/etc/httpd"

When I run apxs -q runtimedir, I get: /var/logs

Rob

Op maandag 1 december 2014 09:09:19 UTC+1 schreef Graham Dumpleton:

[r van dam]

On my old server both values are the same btw. I use an old version of mod_wsgi there: 3.4

[r van dam]

On my new server I tried mod_wsgi version 3.4 to see what happend. With 3.4 I get the same error as with the latest version, so there must be something with the Apache2.4 setup...

[Graham Dumpleton]

Going back to your original mail to explain some more.

On 01/12/2014, at 6:50 PM, r van dam <het.o...@gmail.com> wrote:

On my old server with apache2.2 I use mod_wsgi in daemon mode without problems. I use this configuration in the virtual host part of httpd.conf:

WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25

WSGIProcessGroup stacaravan
WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py

On my new server I use Apache2.4 with mod_wsgi-4.3.2

Do you know what Apache MPM the Apache 2.4 installation is set up with? It should matter, but will be interested to know.

You should be able to work it out if you don't know by running:

    httpd -V

Without daemon mode everything works fine, but with daemon mode I got this error:
[wsgi:error] [pid 13199] (13)Permission denied: [client 81.58.150.99:58714] mod_wsgi (pid=13199): Unable to connect to WSGI daemon process 'stacaravan' on '/tmp.13194.0.2.sock'., referer:

What is troubling about this value is that if you hadn't already set WSGISocketPrefix then it should be of the form:

    /some/path/wsgi.13194.0.2.sock

That is, the 'wsgi' part in the name has gone.

This suggests that WSGISocketPrefix may have already been set in the configuration and possibly with it set to '/tmp'. That would be the only thing that could account for it being set the way it is.

So check the Apache configuration to make sure WSGISocketPrefix isn't set somewhere already by mistake.

FWIW, one should never attempt to put the socket in /tmp anyway as that provides questionable security.

I solved this by making a /var/run/apache2 directory with 755 permission, and use the WSGISocketPrefix run/apache2 directive (Is this the right way to solve?)

Using 'run/apache2' as argument to WSGISocketPrefix doesn't see correct. Did you mean 'var/run/apache2'?

When I add "WSGIProcessGroup stacaravan" to the httpd.conf of the virtual server I get the following error:
[wsgi:error] [pid 13915] [client 81.58.150.99:58850] No WSGI daemon process called 'stacaravan' has been configured: /home/stacaravan/stacaravan/stacaravan/wsgi.py

That error would suggest there was no WSGIDaemonProcess directive for stacaravan defined. Or not one in a context where the WSGIProcessGroup was allowed to use it.

Where was the WSGIDaemonProcess directive set in the configuration?

Where was the WSGIProcessGroup directive set in the configuration?

For a WSGIProcessGroup to be able to always set the same named WSGIDaemonProcess, the WSGIDaemonProcess would have to be at global scope outside of any VirtualHost.

Otherwise, the WSGIDaemonProcess directive for the same named group must be inside of the same VirtualHost, or if the VirtualHost for port 80 or 443, inside of the VirtualHost for the alternate port with same ServerName.

In the latter case of a 80/443 pair, the WSGIDaemonprocess must be in the VirtualHost which was first seen by Apache when the configuration was being read in.

IOW, this is wrong:

<VirtualHost *:80>

ServerName xxx

WSGIProcessGroup yyy

</VirtualHost>

<VirtualHost *443>

ServerName xxx

WSGIDaemonProcess yyy

WSGIProcessGroup yyy

</VirtualHost>

but this is right:

<VirtualHost *:80>

ServerName xxx

WSGIDaemonProcess yyy

WSGIProcessGroup yyy

</VirtualHost>

<VirtualHost *443>

ServerName xxx

WSGIProcessGroup yyy

</VirtualHost>

Graham

Any help is highly appreciated.

- OS debian 7.7
- Custombuild apache 2.4 (Directadmin)
- Mod_wsgi version: 4.3.2 (compiled)
- used with Django 1.7

[r van dam]

httpd -V gives me:

Server version: Apache/2.4.10 (Unix)
Server built:   Dec  1 2014 10:32:19
Server's Module Magic Number: 20120211:36
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_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=256
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 
I have set this option in the global httpd.conf;

WSGISocketPrefix var/run/apache

I have no more socket errors anymore, so that part seems to work fine

Here is the httpd.conf for my virtual host (I have only setup port 80):

<Directory "/home/stacaravan/public_html">
    <IfModule mod_ruid2.c>
        RMode config
        RUidGid stacaravan stacaravan
        #RGroups apache access
        RGroups @none
    </IfModule>
    <IfModule mod_fcgid.c>
        SuexecUserGroup stacaravan stacaravan
    </IfModule>
</Directory>

<VirtualHost 5.9.88.25:80 >
RewriteEngine on
RewriteCond %{HTTP_HOST} ^stacaravanachterhoek\.nl
RewriteRule ^(.*)$ http://www.stacaravanachterhoek$1 [R=permanent,L]
Alias /media/ /home/stacaravan/stacaravan/media/
Alias /static/ /home/stacaravan/stacaravan/static/

WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25
WSGIProcessGroup stacaravan
WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py

<Directory /home/stacaravan/stacaravan/stacaravan>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
    ServerName www.stacaravanachterhoek.nl
    ServerAlias www.stacaravanachterhoek.nl stacaravanachterhoek.nl
    ServerAdmin mymail
    DocumentRoot /home/stacaravan/domains/stacaravanachterhoek.nl/public_html
    UseCanonicalName OFF
    <IfModule !mod_ruid2.c>
        SuexecUserGroup stacaravan stacaravan
    </IfModule>
    <IfModule mod_ruid2.c>
        RMode config
        RUidGid stacaravan stacaravan
        #RGroups apache access
        RGroups @none
    </IfModule>
    CustomLog /var/log/httpd/domains/stacaravanachterhoek.nl.bytes bytes
    CustomLog /var/log/httpd/domains/stacaravanachterhoek.nl.log combined
    ErrorLog /var/log/httpd/domains/stacaravanachterhoek.nl.error.log
    <Directory /home/stacaravan/domains/stacaravanachterhoek.nl/public_html>
        AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,Includes,IncludesNOEXEC,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks,None
        Options -ExecCGI
        php_admin_flag engine ON
        php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f mymail'
        php_admin_value mail.log /home/stacaravan/.php/php-mail.log
        php_admin_value open_basedir /home/stacaravan/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php55/lib/php/
    </Directory>
</VirtualHost>

<VirtualHost 5.9.88.25:443 >
RewriteEngine on
RewriteCond %{HTTP_HOST} ^stacaravanachterhoek\.nl
RewriteRule ^(.*)$ http://www.stacaravanachterhoek$1 [R=permanent,L]
Alias /media/ /home/stacaravan/stacaravan/media/
Alias /static/ /home/stacaravan/stacaravan/static/
Alias /robots.txt /home/stacaravan/stacaravan/static/robots.txt

<Directory /home/stacaravan/stacaravan/stacaravan>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
    SSLEngine on
    SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
    SSLCACertificateFile /etc/httpd/conf/ssl.crt/server.ca
    ServerName www.stacaravanachterhoek.nl
    ServerAlias www.stacaravanachterhoek.nl stacaravanachterhoek.nl
    ServerAdmin mymail
    DocumentRoot /home/stacaravan/domains/stacaravanachterhoek.nl/private_html
    UseCanonicalName OFF
    <IfModule !mod_ruid2.c>
        SuexecUserGroup stacaravan stacaravan
    </IfModule>
    <IfModule mod_ruid2.c>
        RMode config
        RUidGid stacaravan stacaravan
        #RGroups apache access
        RGroups @none
    </IfModule>
    CustomLog /var/log/httpd/domains/stacaravanachterhoek.nl.bytes bytes
    CustomLog /var/log/httpd/domains/stacaravanachterhoek.nl.log combined
    ErrorLog /var/log/httpd/domains/stacaravanachterhoek.nl.error.log
    <Directory /home/stacaravan/domains/stacaravanachterhoek.nl/private_html>
        AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,Includes,IncludesNOEXEC,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks,None
        Options -ExecCGI
        php_admin_flag engine ON
        php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f mymail'
        php_admin_value mail.log /home/stacaravan/.php/php-mail.log
        php_admin_value open_basedir /home/stacaravan/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php55/lib/php/
    </Directory>
</VirtualHost>

[Graham Dumpleton]

On 01/12/2014, at 9:01 PM, r van dam <het.o...@gmail.com> wrote:

> I have set this option in the global httpd.conf;
>
> WSGISocketPrefix var/run/apache

The argument should be an absolute path, not relative.

The only reason it works at all is because the current working directory of Apache when it runs is the root directory of '/'.

I wouldn't rule out that things would break is some misbehaving Apache module (or PHP), changed the working directory of the process.

> <VirtualHost 5.9.88.25:443 >
> RewriteEngine on
> RewriteCond %{HTTP_HOST} ^stacaravanachterhoek\.nl
> RewriteRule ^(.*)$ http://www.stacaravanachterhoek$1 [R=permanent,L]

Since you have a rewrite rule here to redirect everything over to the http (port 80) virtual host, seems like everything below is redundant.

Anyway, are you saying you are still getting the error about unknown WSGI daemon process group at this point?

What happens if instead of using:

WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25
WSGIProcessGroup stacaravan
WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py

you use:

WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25

WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py process-group= stacaravan

Graham

[Graham Dumpleton]

>
> Anyway, are you saying you are still getting the error about unknown WSGI daemon process group at this point?
>
> What happens if instead of using:
>
> WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25
> WSGIProcessGroup stacaravan
> WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py
>
> you use:
>
> WSGIDaemonProcess stacaravan user=stacaravan group=stacaravan threads=25
> WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py process-group= stacaravan

There is not meant to be a space in that.

WSGIScriptAlias / /home/stacaravan/stacaravan/stacaravan/wsgi.py process-group=stacaravan

Graham

[r van dam]

I get the same error:
[Mon Dec 01 11:30:38.236493 2014] [wsgi:error] [pid 17290] [client 81.58.150.99:60362] No WSGI daemon process called 'stacaravan' has been configured: /home/stacaravan/stacaravan/stacaravan/wsgi.py



Op maandag 1 december 2014 11:14:35 UTC+1 schreef Graham Dumpleton:

[r van dam]

Strange, when I setup a second domain for daemon mode this domain has this error in his logs:

[Mon Dec 01 11:32:38.383772 2014] [wsgi:error] [pid 17357] (2)No such file or directory: [client 81.58.150.99:60383] mod_wsgi (pid=17357): Unable to connect to WSGI daemon process 'jouwsta' on '/etc/httpd/var/run/apache.17353.0.1.sock'., referer: http://www.jouwstacaravan.nl/achterhoek/

[Graham Dumpleton]

On 01/12/2014, at 9:38 PM, r van dam <het.o...@gmail.com> wrote:

> Strange, when I setup a second domain for daemon mode this domain has this error in his logs:
>
> [Mon Dec 01 11:32:38.383772 2014] [wsgi:error] [pid 17357] (2)No such file or directory: [client 81.58.150.99:60383] mod_wsgi (pid=17357): Unable to connect to WSGI daemon process 'jouwsta' on '/etc/httpd/var/run/apache.17353.0.1.sock'., referer: http://www.jouwstacaravan.nl/achterhoek/

This gets back to what I said about WSGISocketPrefix needing to be an absolute path. Looks like it will still actually be added below server root if you don't.

It also is meant to still have the 'wsgi' name at the end.

http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGISocketPrefix

Thus:

WSGISocketPrefix /var/run/apache2/wsgi

If you don't, it is actually trying to create them in a directory above where you intended them to be.

If that is now only just showing up when you add a new virtual host, there is really something screwy going on with how your Apache configuration files are organised.

Do you have everything in the one httpd.conf, or using a Lunux like setup where spread over many files and with sites in separate files?

Graham

[r van dam]

@Graham I really appreciate your help!

I noticed that the .sock files are actually created. I think there is something strange with the permissions:
srwx------ 1 apache root 0 Dec  1 11:54 wsgi.18278.0.1.sock
srwx------ 1 apache root 0 Dec  1 11:54 wsgi.18278.0.2.sock

There are lots of spread configuration files for apache...

 
Op maandag 1 december 2014 11:47:33 UTC+1 schreef Graham Dumpleton:

[Graham Dumpleton]

On 01/12/2014, at 9:58 PM, r van dam <het.o...@gmail.com> wrote:

@Graham I really appreciate your help!

I noticed that the .sock files are actually created. I think there is something strange with the permissions:
srwx------ 1 apache root 0 Dec  1 11:54 wsgi.18278.0.1.sock
srwx------ 1 apache root 0 Dec  1 11:54 wsgi.18278.0.2.sock

Permissions look fine to me. They should be owned by the Apache user and not accessible to anything else. 

There are lots of spread configuration files for apache…

I would check very closely how you have them all being included in with each other and whether you have stray WSGI??? directives at global scope that shouldn't be there.

Can you clarify though whether the Apache configuration layout is the standard one for your Linux distro.

Are you properly using the sites-available directory for your site stuff? With then then being enabled by enabling script or otherwise being symlinked into sites-enabled directory.

Similar, is mod_wsgi being loaded from wsgi.load (???) file in mods-available and symlinked into mods-enabled? What is in the wsgi.load file.

Basically find every place you have WSGI??? directives and check them.

Graham

Op maandag 1 december 2014 11:47:33 UTC+1 schreef Graham Dumpleton:

On 01/12/2014, at 9:38 PM, r van dam <het.o...@gmail.com> wrote:

> Strange, when I setup a second domain for daemon mode this domain has this error in his logs:
>
> [Mon Dec 01 11:32:38.383772 2014] [wsgi:error] [pid 17357] (2)No such file or directory: [client 81.58.150.99:60383] mod_wsgi (pid=17357): Unable to connect to WSGI daemon process 'jouwsta' on '/etc/httpd/var/run/apache.17353.0.1.sock'., referer: http://www.jouwstacaravan.nl/achterhoek/

This gets back to what I said about WSGISocketPrefix needing to be an absolute path. Looks like it will still actually be added below server root if you don't.

It also is meant to still have the 'wsgi' name at the end.

  http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGISocketPrefix

Thus:

  WSGISocketPrefix /var/run/apache2/wsgi

If you don't, it is actually trying to create them in a directory above where you intended them to be.

If that is now only just showing up when you add a new virtual host, there is really something screwy going on with how your Apache configuration files are organised.

Do you have everything in the one httpd.conf, or using a Lunux like setup where spread over many files and with sites in separate files?

Graham

[r van dam]

I use Directadmin and therefore apache is custombuild. There is no mod-enabled directory in my case.

I load the mod_wsgi directly from the global httpd.conf:
LoadModule wsgi_module /usr/lib/apache/mod_wsgi.so

The only global wsgi directions are the one above, and the WSGISocketPrefix direction.

Everything is the same is on the old apache2.2 setup....

[Graham Dumpleton]

One last stupid suggestion before I sleep. There hasn't been any strange characters got into the names for the daemon process group has there. Some unicode character that looks the same but isn't actually.

Do an 'od -c' on the configuration file and just make sure the names are actually ASCII.

[r van dam]

od -c show no strange characters. Running "file httpd.conf" says it's an ascii file. I manually retyped the groupnames etc. but the problem remains...

Good night for now, and thank your for your help!

[r van dam]

I gave up yesterday. Checked selinux (was disabled). But nothing worked. Therefore I switched to Nginx with Uwsgi, and this works like a charme so far.

Thanks for the help.

[Graham Dumpleton]

On 02/12/2014, at 9:51 PM, r van dam <het.o...@gmail.com> wrote:

> I gave up yesterday. Checked selinux (was disabled). But nothing worked. Therefore I switched to Nginx with Uwsgi, and this works like a charme so far.

Perhaps try the pip installable mod_wsgi-express.

https://pypi.python.org/pypi/mod_wsgi

I didn't suggest this before as you seemed to have PHP stuff tied up with your Apache configuration.

But then, mod_wsgi-express can actually also handle having PHP files as well if need be.

Graham