2009/4/16 Alen Ribic <alen.ri...@gmail.com>: > >> What you probably want is: >> >> WSGIDaemonProcess mysite user=intrack group=intrack >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages >> processes=2 threads=25 >> >> WSGIProcessGroup mysite >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> > > Thank you kindly, that took me another step forward. > > Now I got the following error in log: > > [Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13) > Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI > daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock' > after multiple attempts. > > I take it, in this case, that my user 'intrack' doesn't have > permission to connect to the socket /etc/httpd/logs/wsgi. > 19713.0.1.sock. Is this right and do you have any suggestions how to > rectify this please? > I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock > does exist hence has been created.
Read: http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets Then try setting: WSGISocketPrefix run/wsgi in Apache configuration as directed. Graham > -Alen > > On Apr 15, 11:17 pm, Graham Dumpleton <graham.dumple...@gmail.com> > wrote: >> 2009/4/16 Alen Ribic <alen.ri...@gmail.com>: >> >> >> >> > Thank you Graham for your reply. >> >> > You are definitely right about the permissions. >> > Apache User and Group directives are both set to 'apache'. >> > My wsgi (django) application is in the /home/intrack which is the >> > 'intrack' user. >> >> > I added the WSGIDaemonProcess directive: >> > # >> > WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/ >> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25 >> > # >> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> This is wrong. See: >> >> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide >> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments >> >> for complete examples. >> >> The mistakes are that you have called the daemon process group >> 'user=intrack' as first argument is supposed to be the name. You also >> don't appear to have WSGIProcessGroup directive to delegate >> application to that process group. >> >> What you probably want is: >> >> WSGIDaemonProcess mysite user=intrack group=intrack >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages >> processes=2 threads=25 >> >> WSGIProcessGroup mysite >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> Graham >> >> > That still gave me a same error "ImportError: No module named >> > django.core.handlers.wsgi" >> >> > Question: who is the .wsgi script ran by? Apache special user? or the >> > one defined on WSGIDaemonProcess (in my case 'intrack' user)? >> >> > Also, am I on the right track here using WSGIDaemonProcess to set the >> > user I wish to run the application as? (I have fully tested the django >> > application using the 'intrack' user. By the way, /home/intrack has >> > the django app and the python virtual environment.) >> >> > I started the httpd service as root by the way. >> >> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the >> > python process? >> >> > -Alen >> >> > On Apr 15, 12:35 pm, Graham Dumpleton <graham.dumple...@gmail.com> >> > wrote: >> >> 2009/4/15 Alen Ribic <alen.ri...@gmail.com>: >> >> >> > I've seen a few posts related to Django, virtualenv and mod_wsgi >> >> > however still can't solve my problem. >> >> >> > I keep getting "ImportError: No module named >> >> > django.core.handlers.wsgi" in my apache error log no matter what I >> >> > try. >> >> >> Read: >> >> >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights... >> >> >> Apache runs as a special user . If you are using embedded mode, or >> >> daemon mode but haven't set 'user' option to be your account, then may >> >> not be able to read directories/files if permissions on them aren't >> >> correct. >> >> >> Try your command line test, but become the user that Apache runs as >> >> first. If that fails you know this is the problem. >> >> >> In your command line test from your account, also do: >> >> >> import django >> >> print django.__file__ >> >> >> Ensure that that is the version you want used. Then check that all the >> >> files readable to others and that directories readable and searchable >> >> to others. For directories, this includes directories back up the >> >> hierarchy to root of file system. >> >> >> Graham >> >> >> > Here is the wsgi script: >> >> >> > #### intrack.wsgi ############################################ >> >> > import os, sys, site >> >> >> > import logging >> >> >> > #create logger >> >> > logger = logging.getLogger("intrack_wsgi") >> >> >> > logger.setLevel(logging.DEBUG) >> >> >> > fh = logging.FileHandler("/tmp/InTrackWSGI.log") >> >> > fh.setLevel(logging.DEBUG) >> >> >> > formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s >> >> > - %(message)s") >> >> >> > fh.setFormatter(formatter) >> >> > logger.addHandler(fh) >> >> >> > sys.path.append('/home/intrack/intrack_pythonenv/projects') >> >> > sys.path.append('/home/intrack/intrack_pythonenv/projects/InTrack') >> >> > os.environ['DJANGO_SETTINGS_MODULE'] = 'InTrack.settings' >> >> >> > ALLDIRS = ['/home/intrack/intrack_pythonenv/lib/python2.5/site- >> >> > packages'] >> >> >> > # Remember original sys.path. >> >> > prev_sys_path = list(sys.path) >> >> >> > # Add each new site-packages directory. >> >> > for directory in ALLDIRS: >> >> > site.addsitedir(directory) >> >> >> > # Reorder sys.path so new directories at the front. >> >> > new_sys_path = [] >> >> > for item in list(sys.path): >> >> > #logger.debug("sys.path item: %s" % item) >> >> > if item not in prev_sys_path: >> >> > new_sys_path.append(item) >> >> > sys.path.remove(item) >> >> > sys.path[:0] = new_sys_path >> >> >> > logger.debug(sys.path) >> >> > logger.debug("exec_prefix: %s" % sys.exec_prefix) >> >> > logger.debug("version: %s" % sys.version) >> >> >> > import django.core.handlers.wsgi >> >> >> > application = django.core.handlers.wsgi.WSGIHandler() >> >> >> > #### end - intrack.wsgi ############################################ >> >> >> > #### apache wsgi.conf >> >> > ################################################# >> >> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> > #### end - apache wsgi.conf >> >> > ############################################ >> >> >> > #### apache error log ############################################ >> >> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] Traceback (most >> >> > recent call last): >> >> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] File "/var/ >> >> > www/wsgi_scripts/InTrack.wsgi", line 44, in <module> >> >> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] import >> >> > django.core.handlers.wsgi >> >> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] ImportError: No >> >> > module named django.core.handlers.wsgi >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi >> >> > (pid=3610): Target WSGI script '/var/www/wsgi_scripts/InTrack.wsgi' >> >> > cannot be loaded as Python module. >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi >> >> > (pid=3610): Exception occurred processing WSGI script '/var/www/ >> >> > wsgi_scripts/InTrack.wsgi'. >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] Traceback (most >> >> > recent call last): >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] File "/var/ >> >> > www/wsgi_scripts/InTrack.wsgi", line 44, in <module> >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] import >> >> > django.core.handlers.wsgi >> >> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] ImportError: No >> >> > module named django.core.handlers.wsgi >> >> > #### end - apache error log >> >> > ############################################ >> >> >> > #### wsgi script log ############################################ >> >> > 2009-04-15 12:14:13,938 - intrack_wsgi - DEBUG - ['/home/intrack/ >> >> > intrack_pythonenv/lib/python2.5/site-packages', '/usr/local/lib/ >> >> > python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/python2.5/ >> >> > plat-linux2', '/usr/local/lib/python2.5/lib-tk', '/usr/local/lib/ >> >> > python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/ >> >> > home/intrack/intrack_pythonenv/projects', '/home/intrack/ >> >> > intrack_pythonenv/projects/InTrack', '/home/intrack/intrack_pythonenv/ >> >> > projects', '/home/intrack/intrack_pythonenv/projects/InTrack', '/home/ >> >> > intrack/intrack_pythonenv/lib/python2.5/site-packages'] >> >> > 2009-04-15 12:14:13,939 - intrack_wsgi - DEBUG - exec_prefix: /usr/ >> >> > local >> >> > 2009-04-15 12:14:13,939 - intrack_wsgi - DEBUG - version: 2.5.4 >> >> > (r254:67916, Apr 14 2009, 15:48:34) >> >> > [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] >> >> > #### end - wsgi script log >> >> > ############################################ >> >> >> > I tried this, from the command shell, running the /usr/local/bin/ >> >> > python (which is the version of python that the wsgi module is running >> >> > as per the log above '/usr/local') and then I manually set the >> >> > sys.path to: >> >> > ['/home/intrack/intrack_pythonenv/lib/python2.5/site-packages', '/usr/ >> >> > local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/ >> >> > python2.5/plat-linux2', '/usr/local/lib/python2.5/lib-tk', '/usr/local/ >> >> > lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', >> >> > '/home/intrack/intrack_pythonenv/projects', '/home/intrack/ >> >> > intrack_pythonenv/projects/InTrack', '/home/intrack/intrack_pythonenv/ >> >> > projects', '/home/intrack/intrack_pythonenv/projects/InTrack', '/home/ >> >> > intrack/intrack_pythonenv/lib/python2.5/site-packages'] >> >> > Exactly as what the log says in the wsgi script that it has the >> >> > sys.path set to and guess what? The "import django.core.handlers.wsgi" >> >> > works 100%. >> >> >> > So why is it that when wsgi module runs in apache that it doesn't >> >> > pickup the django.* when whats in the sys.path works correctly if ran >> >> > manually from interpreter? >> >> >> > I would gladly appreciate if someone could shed some light on this. >> >> >> > Regards, >> >> > -Alen >> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
