Unable to connect to WSGI daemon process

Mads Kiilerich mads at kiilerich.com
Mon Aug 3 17:53:43 UTC 2020


On 8/2/20 9:03 PM, Louis Bertrand wrote:
> Yes, we are using WSGI to manage Kallithea, on Ubuntu server 18.04.4 LTS with Apache2.


Thanks.

(Kallithea is a WSGI application, so everybody has to use WSGI. The 
important point here is that you are using mod_wsgi.)


> The mod-wsgi that we are using (from apt list):
> libapache2-mod-wsgi-py3/bionic-updates,now 4.5.17-1ubuntu1 amd64 [installed]
>
> We got the configuration option from the WSGI documentation:
> https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html


This hints that it could be related to using Apache PrivilegesMode ... 
which is experimental and Solaris only, so I assume that isn't the case.

Then it hints that you might be using other third party Apache modules. 
Is that the case?

Your problem seems a bit like 
https://modwsgi.readthedocs.io/en/develop/user-guides/configuration-issues.html 
... but evidently different.

I can see your problem and solution are similar to 
https://stackoverflow.com/questions/47542260/django-wrong-permissions-for-created-sock-file-using-mod-wsgi 
... but before recommending your solution, I would still like to 
understand why you have the problem when others doesn't.


> Generally our server configuration matches what you recommend in the installation documentation:
>
>          WSGIDaemonProcess       kallithea processes=5 threads=1 maximum-requests=100 lang=en_US.utf8 user=hg group=hg socket-user=hg python-home=/srv/web/sites/hg.set.durhamcollege.org/kallithea-venv
>          WSGIProcessGroup        kallithea
>          WSGIScriptAlias /       /srv/web/sites/hg.set.durhamcollege.org/kallithea/dispatch.wsgi
>          WSGIPassAuthorization   On


Ok, so the problem and scenario might be related to using `user=hg 
group=hg` ... which (in some cases?) seems to need a corresponding 
`socket-user=hg`. https://github.com/GrahamDumpleton/mod_wsgi/issues/137 
suggest that it only is relevant in some odd setups and shouldn't be a 
general advice.

Our setup documentation could perhaps be changed to say:

   If you want to have the repositories
   owned by a different user, use the ``user`` and ``group`` options to
   WSGIDaemonProcess to set the name of the user and group.
   It might also be necessary to set ``socket-user``.

(but a bit unsatisfying to give such a vague hint in the documentation.)


> The dispatch script is:
>      import os
>      os.environ['PYTHON_EGG_CACHE'] = '/srv/web/sites/hg.set.durhamcollege.org/kallithea/.egg-cache'
>
>      os.chdir('/srv/web/sites/hg.set.durhamcollege.org/kallithea/')
>
>      import site
>      site.addsitedir("/srv/web/sites/hg.set.durhamcollege.org/kallithea-venv/lib/python3.6/site-packages")
>
>      ini = '/srv/web/sites/hg.set.durhamcollege.org/kallithea/my.ini'
>      from logging.config import fileConfig
>      fileConfig(ini, {'__file__': ini, 'here': '/srv/web/sites/hg.set.durhamcollege.org/kallithea'})
>      from paste.deploy import loadapp
>      application = loadapp('config:' + ini)


Thanks for sharing. That allow me to get a bit off topic:

It annoys me that our documenation mention two different WSGI dispatch 
scripts. I wondered why you use the (in my opinion) less elegant one. 
But I realize activate_this.py isn't available when using python3 -m venv .

Based on 
https://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html#daemon-mode-single-application 
, I guess we should advice using python-home=/srv/kallithea/venv (as 
already you do) and stop mentioning the venv in the wsgi dispatch script.

Also, I guess PYTHON_EGG_CACHE no longer is needed with py3?

I currently don't use mod_wsgi myself. Can you help verify if your 
dispatch script works without these?

/Mads


> From: Mads Kiilerich <mads at kiilerich.com>
> Sent: Saturday, August 1, 2020 4:49 PM
> To: Louis Bertrand; Kallithea
> Subject: Re: Unable to connect to WSGI daemon process
>
> [EXTERNAL EMAIL]
>
> On 7/31/20 4:37 PM, Louis Bertrand wrote:
>> There was a disconnect between Apache and the Kallithea WSGI daemon process. The WSGI daemon was unable to read the socket. The exact error message in Apache's logs/ssl-errors is
>>
>> [Thu Jul 30 17:52:34.396927 2020] [wsgi:error] [pid 10169] (13)Permission denied: [client 216.blahblah:58674] mod_wsgi (pid=10169): Unable to connect to WSGI daemon process 'kallithea' on '/var/run/apache2/wsgi.10110.0.1.sock' as user with uid=1003.
>>
>> where user 1003 is 'hg', the Linux Kallithea user.
>>
>> Solved by adding
>> socket-user=hg
>> on the WSGIDaemonProcess line in the Apache WSGI configuration and restarting Apache
>
> This must be when using mod_wsgi. Is it configured pretty much like
> outlined in the Kallithea documentation?
>
> socket-user seems to be a recent addition, and this is might thus not be
> a general solution.
>
> What mod_wsgi version and which OS and version are you using?
>
> To help us review and assess how general this is: What led to this
> solution? Any external references?
>
> /Mads
>
> ________________________________
>
> ________________________________
> This message is intended only for the named recipients. This message may contain information that is confidential or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.




More information about the kallithea-general mailing list