Tag Info

Hot answers tagged

12

Well, how much traffic do the actual Superuser and Serverfault sites have? Hypotheticals aren't much use if they don't have enough info to make the answer easier... Your worst-case process count should be the peak number of requests per second you want the site to be able to handle, divided by the number of requests per second that one process can handle ...


6

The default MPM is prefork, which creates (as you've seen) a pre-forked Apache process that is waiting for a connection to serve a request. It does not fire off different processes for different VirtualHost declarations, so any given process could serve any of your sites. As processes are restarted after a configurable number of requests have been served ...


5

A given Apache worker isn't associated with any particular virtual host. If you want more detailed information on what Apache is doing (including resource usage), you should turn on Apache's status pages and look at the extended status information: http://articles.slicehost.com/2010/3/26/enabling-and-using-apache-s-mod_status-on-ubuntu For example, this ...


5

The error your saw can also occur as a transient issue if you have done an Apache graceful restart and an Apache worker process had socket connections still alive that hadn't yet called through to mod_wsgi daemon process for initial request or subsequent request due to keep alive on socket. This will occur because on graceful restart the mod_wsgi daemon ...


5

The important bit is to rebuild Python with --enable-shared. The symlink comments are not relevant if you haven't done that and should't even apply with recent Python/mod_WSGI versions.


5

Read the documentation for mod_wsgi and it tells you what to do. See: http://code.google.com/p/modwsgi/wiki/InstallationIssues#Multiple_Python_Versions Specifically, use the WSGIPythonHome directive to tell mod_wsgi that your Python is actually in a different location. If this doesn't work, then make sure you are no longer loading mod_python into same ...


5

I have found that this is a known bug with mod_wsgi apt-get package that is over a year old! Details at http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1147225.html. The apt-get package did not have the wsgi.load file so that needed to be created by doing the steps in the link above. Thanks to everyone that helped!


5

See if the module is actually loaded properly with: apache2ctl -t -D DUMP_MODULES


5

Updates, updates, updates. Are you running Debian stable or testing? Sometimes keeping testing up to date is a bit more complicated than stable. Are you running everything as Debian packages? Make sure you are not running extraneous services. Run netstat -nap and check all processes that are listening on ports, make sure there's nothing there which is ...


5

Run: sudo apachectl -t and you will clearly see that you made an error in your configuration. Use: LoadModule wsgi_module /usr/local/Cellar/mod_wsgi/3.2/libexec/mod_wsgi.so as instructions should tell you. Ie., use 'wsgi_module' and not 'mod_wsgi_module'. See: http://code.google.com/p/modwsgi/wiki/QuickInstallationGuide#Loading_Module_Into_Apache If ...


5

Take a look in /proc/<PID>/fd which should list all of the open files that PID has open. On my CentOS system fd 7 is lrwx------. 1 root root 64 Aug 28 22:01 7 -> socket:[1872522] I can then use netstat -ane | grep 1872522 to get tcp 0 0 :::443 :::* LISTEN 0 1872522 You can use lsof | grep ...


5

The line: LoadModule mod_wsgi modules/mod_wsgi.so is wrong. It should have been: LoadModule wsgi_module modules/mod_wsgi.so Upgrading itself should not have made any difference.


4

I've confirmed that the mod_wsgi package (libapache-mod-wsgi) supports both python 2.6 and 2.7. Checking /usr/lib/apache2/modules revealed the existence of both mod_wsgi.so-2.6 and mod_wsgi.so-2.7. To install the package without having to install python 2.6 I've used apt-get download libapache2-mod-wsgi to download the package without installing, and then ...


4

Curious... as a quick test, try running chmod o+rx /var/run/postgresql -- if that fixes the problem (as I suspect it will) then you'll need to diagnose why the permissions are screwed up on the directory. On my system (Debian Squeeze) the perms are 2775 postgres:postgres; while it isn't necessary to have that particular mode, you'll want (at least) o+x to ...


4

A few comments about your configuration. MaxSpareThreads and MinSpareThreads should really be a multiple of ThreadsPerChild. If it isn't, with some combinations of values you can get Apache cycling between creating new processes because it thinks it needs them and then deciding the next moment to kill them again because it then changes its mind and sees ...


4

Look for /usr/lib/apache2/modules/mod_wsgi.so*, at least on ubuntu I have: /usr/lib/apache2/modules/mod_wsgi.so -> mod_wsgi.so-2.6 /usr/lib/apache2/modules/mod_wsgi.so-2.5 /usr/lib/apache2/modules/mod_wsgi.so-2.6 If you change the symlink, you change the default mod_wsgi. An alternative is to look in /etc/apache2/mods-enabled/wsgi.load, for me ...


4

As far as I can see, you haven't loaded the mod_wsgi module into your httpd.conf. I'd first try adding the wsgi files to the mods-enabled directory of Apache. sudo ln -s /etc/apache2/mods-available/wsgi.load /etc/apache2/mods-enabled sudo ln -s /etc/apache2/mods-available/wsgi.conf /etc/apache2/mods-enabled Then restart Apache and it should work.


4

If this is a uni project, I would really consult with them, not just to determine what you can run, but also what they will accept as a project deliverable. Otherwise you could waste a lot of time working on a project that nobody is prepared to mark.


4

The mod_status module in Apache will show you which virtualhost / request a particular process is handling, but this will only be useful to you if the requests are long-lived. Adding execution time (%D) to your Apache LogFormat is also useful. More important is tracking down the bottleneck. For this you need to investigate iostat and vmstat (usually ...


4

Your mod_wsgi was compiled for Python 2.7. You cannot then try and point it at a Python 2.5 virtual environment. Also, the setting: WSGIPythonHome /home/rory/tix/virtualenv2.5/lib/python2.5/ is pointing at the wrong thing even if it was a Python 2.7 virtual environment. The settings: UnSetEnv PYTHONSTARTUP SetEnv PYTHONPATH ...


4

Quoting the documentation at: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess behaviour is: If the WSGIDaemonProcess directive is specified outside of all virtual host containers, any WSGI application can be delegated to be run within that daemon process group. If the WSGIDaemonProcess directive is specified within ...


3

See if the module was loaded properly by issuing apache2ctl -t -D DUMP_MODULES or apachectl -t -D DUMP_MODULES. If it wasn't, edit your httpd.conf or an included file to include the following (replace lib with lib64 if needed): LoadModule wsgi_module /usr/lib/httpd/modules/mod_wsgi.so Do note that you can't execute any python script with WSGI - it has to ...


3

Problem solved. mod_python was also loaded, disabling it did the trick. As it is the vanilla mod_python shipped with Lenny’s Apache, it is compiled against Python 2.5.2—naturally, this cannot work in combination with mod_wsgi compiled against a different version.


3

You are reading it wrong. Apache does start as 'root' and the parent Apache process stays as 'root', only the Apache server child process run as 'www-data'. The mod_wsgi daemon processes are forked from the parent 'root' process and so will still be able to change to that user. What the comment is saying is that if you start Apache from a totally non ...


3

You can comment out the line: WSGIDaemonProcess django processes=5 \ python-path=/home/pllee/webapps/django:/home/pllee/webapps/django/lib/python2.7 \ threads=1 for a start. This line is doing absolutely nothing except for causing five processes to be started which then sit there idle and do nothing. This is the mistake WebFaction has had for a ...


3

As pointed out in comment to question, most likely filesystem permissions with Apache user unable to read from where WSGI script file is or read the WSGI script file itself. This specific error is described in the presentation: http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Conference_Presentations


3

You have: WSGIDaemonProcess xxx display-name=xxx group=www-data user=www-data processes=25 threads=1 but then have: WSGIProcessGroup %{GLOBAL} which means that you aren't delegating the WSGI application to run in that daemon process group. In other words, you are running your WSGI application in embedded mode instead and the WSGIDaemonProcess ...


3

The mod_wsgi warnings are notifying you of a potential dependency problem. While it is unlikely to be an issue (it is not common for there to be significant API differences between a x.y.z release and x.y.z+1) it does not know this for sure so warns you that there is a potential issue. The only way to sort this is to recompile the module against the newer ...


3

This is how I did it on my django site, where the path is set in the apache file (as MY_PATH). Notice that I copy it into the os.environ variable. import os, sys, django.core.handlers.wsgi _application = django.core.handlers.wsgi.WSGIHandler() def application(environ, start_response): path = environ['MY_PATH'] if path not in sys.path: ...


3

Use WSGIRestrictStdout option: WSGIRestrictStdout Off or replace sys.stdout with sys.stderr in Django WSGI star script: import sys sys.stdout = sys.stderr Writing To Standard Output No WSGI application component which claims to be portable should write to standard output. That is, an application should not use the Python print statement without ...



Only top voted, non community-wiki answers of a minimum length are eligible