For good measure, set: LogLevel debug WSGIVerboseDebugging On
in the Apache configuration. Start the server and make a single request and capture the mod_wsgi logging or anything related and send it. Will see if that shows anything. Also try: WSGISocketPrefix /tmp/wsgi It is not generally advisable to use /tmp, at least if a shared system, but if your own system is not so bad. Other than looking at that, the only other thing can think of is that the UNIX socket likely will not work in a NFS file system. Unless they are doing something really strange with the type of VPS they run, then that should not be the case though for a subdirectory of '/'. Anyway, as to the sequence of events. Apache would normally start as root so that it can bind port 80. In the Apache parent process, at the point it goes to create the mod_wsgi daemon process group, it will first create as root the UNIX socket. This is the one you are changing the location of with WSGISocketPrefix. That UNIX socket will have its ownership changed to the Apache user as dictated by the Apache User directive. Would typically be www-data, _www or nobody. The permissions of the socket when created will also be 0400 so that it should only be accessible to root or the Apache user which is the owner of the file. All the directories down to that UNIX socket will also though need to be readable/searchable to the Apache user. When the daemon process group process are now forked off the Apache parent process, they will listen for new connections on it. When a request is now received by Apache, they will be received by the Apache child worker processes on port 80 (or other public HTTP/HTTPS port). These will run as the Apache user. If the request is destined for the WSGI application running in a daemon process group, the Apache child worker process will create a connection to the UNIX socket. A mod_wsgi daemon process will accept that connection and then handle the proxied request in the separate daemon process. Now one final thing you could do as a separate sanity check is to try using mod_wsgi-express on that system and see if that even works. https://pypi.python.org/pypi/mod_wsgi It defaults to using /tmp for generated configuration and the location of the UNIX socket. Also therefore try running it with the option: --server-root /some/path to see if works in fails in other directories besides /tmp. Make sure you create that directory first if the parent directory can't be written to by the user you run mod_wsgi-express as, and ensure the directory is writable by the user you are running mod_wsgi-express as. Graham On 10/12/2014, at 11:30 PM, Christiaan Stoudt <[email protected]> wrote: > Hi there... > > From what I can tell it is completely disabled. I do a "getenforce" and it > comes back as Disabled. I will open a ticket with KnownHost to see if they > have anything else that could block things but the hardest thing is I don't > know what file the error is talking about... because how can we have a > permission error with the wsgi.sock file when it is being created????? > > Honestly what might help is if you could quickly explain the series of events > that are happening. I could never find an article or anything that actually > explained the sequence of how mod_wsgi was loaded and executed. Basically > when the Daemon is called what is it doing... do it execute the alias and > wsgi.py in the public_html after it creates the wsgi.sock file or before, > etc? Or is apache doing it or what? > > I noticed that when I did the daemon as a user I could get a new apache > process running under that user but still it failed even if the wsgi.sock and > wsgi.py files were in a folder off of root that the user could read. > > Since I don't understand some of the basic steps the applications and apache > takes I can't even help check for a config issue myself or try other > things... so a basic step sequence would help... > > Thanks for the continued help! > > On Tuesday, 9 December 2014 20:59:28 UTC-8, Graham Dumpleton wrote: > Can you double check that SELinux isn't causing an issue as the only thing > that usually causes this is SELinux. > > Try temporarily disabling SELinux by following steps in: > > http://www.crypt.gen.nz/selinux/disable_selinux.html > > Graham > > On 10/12/2014, at 2:28 PM, Christiaan Stoudt <[email protected]> wrote: > >> Hi there... >> >> I was trying to cover all the options in my first message that I tried and I >> guess I wasn't clear enough in one of the sentences! The >> /usr/local/apache/logs is root:root and I was aware of the permissions issue >> on the folder. So I also tried that by creating a directory straight off >> the root of the drive called wsgisock. >> >> drwxr-xr-x 2 nobody nobody 4096 Dec 9 15:15 wsgisock/ >> >> Then I edited the WSGISocketPrefix like this--- WSGISocketPrefix >> /wsgisock/wsgi and I still had the issue even when I saw a >> wsgi.xxx.0.1.sock file being created in /wsgisock/ >> >> In fact I just tried it again to make sure I wasn't being crazy. So >> technically the only think I did not do was change the permissions on >> /var/run/ to nobody:nobody because there are other programs using it for >> httpd, etc and I didn't want to mess them up with permission issues. So I >> figured creating a new directory off of root should basically provide the >> same solution. >> >> I guess explains why I am at a loss on what else I missed. >> >> >> >> On Tuesday, 9 December 2014 16:33:59 UTC-8, Graham Dumpleton wrote: >> It isn't the permissions on the socket file which can be the issue, the >> directory that the socket file is in must be readable/searchable by the >> 'nobody' user. Same applies to any directories all the way from '/' down to >> that directory. >> >> What do you get for: >> >> ls -las /usr/local/apache/logs >> >> Graham >> >> On 10/12/2014, at 11:06 AM, Christiaan Stoudt <[email protected]> wrote: >> >>> Hello... >>> >>> I was able to get my Django site working with mod_wsgi and Apache after >>> learning all the configuration, etc. Thank you for the great documentation >>> and help. So I want it clearly stated that I have mod_wsgi working. >>> >>> Unfortunately I am running out of RAM so I decided to switch over to a >>> WSGIDaemon configuration. This is where my problem is... I have hit a dead >>> end and no matter how deep I search I continue to have no success. I hope >>> I can get some help here. Below are all the details I have in hopes to get >>> a response... >>> >>> Error: (13)Permission denied: [client xx.xx.xx.xx:xxxx] mod_wsgi >>> (pid=4570): Unable to connect to WSGI daemon process 'mydomain_com' on >>> '/usr/local/apache/logs/wsgi.4560.0.1.sock' after multiple attempts. >>> >>> Server details: >>> -- VPS Provider - KnownHost >>> -- OS Version - CentOS 6.6 (final) >>> -- Python 2.7.5 >>> -- VirtualENV 1.11.6 >>> -- Django 1.7.1 >>> -- mod_wsgi 3.4 >>> -- httpd -V >>> ---- Server version: Apache/2.4.10 (Unix) >>> ---- Architecture: 32-bit >>> ---- Server MPM: prefork / threaded: no / forked: >>> yes (variable process count) >>> -- Note: Apache runs as NOBODY for the chile processes >>> -- SELinux getenforce = Disabled >>> >>> -- In the pre.virtualhost.global.conf file I have these settings (this gets >>> merged with httpd.con): >>> LoadModule wsgi_module /usr/local/apache/extramodules/mod_wsgi.so >>> AddHandler wsgi-script .wsgi >>> WSGISocketPrefix /var/run/wsgi >>> >>> -- In the virtual host conf I have these settings: >>> WSGIDaemonProcess mydomain_com threads=10 inactivity-timeout=300 >>> maximum-requests=2000 display-name=%{GROUP} >>> WSGIProcessGroup mydomain_com >>> WSGIScriptAlias / /home/mydomain/public_html/d171p275/mydomain_com/wsgi.py >>> >>> -- In my wsgi.py file I have these settings: >>> import os, sys >>> sys.path.append('/home/mydomain/public_html/d171p275') >>> sys.path.append('/home/mydomain/venv/d171p275/lib/python2.7/site-packages/') >>> os.environ["DJANGO_SETTINGS_MODULE"] = "mydomain_com.settings" >>> from django.core.wsgi import get_wsgi_application >>> application = get_wsgi_application() >>> >>> ~~~~~~~~~ >>> >>> I see that the wsgi.xx.sock file was originally created in the >>> /etc/httpd/logs/ folder with nobody:root as permissions and a 0 size. >>> After putting in the WSGISocketPrefix setting, it moved to the /var/run >>> folder but the error persists. I have also tried to create a folder off of >>> the / folder with permissions: nobody:nobody and I still get the error. I >>> have also tried to add the user and group entries in WSGIDaemonProcess for >>> both the "nobody" account as well as the "mydomain" account that the >>> virtual host domain was created on. >>> >>> Also I have moved the WSGI.PY file into various other folders (even the >>> same one the wsgi.xx.sock file sat in) to make sure the apache spawned >>> process could see it. It is not a SELinux or MPM issue. I don't have a >>> python-path in the WSGIDaemon process because it seems that WSGI is finding >>> the wsgi.py file in the public_html folder for the domain just fine. >>> >>> Honestly I just have NO OTHER IDEAS!! Since I am still new to this I >>> wouldn't doubt it is something stupid. :) Any suggestions? >>> >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
