On 16 September 2010 15:31, Sameer Sundresh <sam...@sundresh.org> wrote: > I'm using apache2 with mod_wsgi to host several different sites on the same > server. I'm using VirtualHost directives to define each site, and I'm > running a separate WSGI process (with a different application) for each. > The strange thing I'm running into is that all log files defined for all > VirtualHosts (access.log and error.log files) are open in all WSGI > applications. This means one application can interfere with another's log > files, even if the two applications are running in different WSGI processes > with different UIDs and GIDs.
What version of mod_wsgi are you using? If you are using mod_wsgi 3.X, provided that WSGIDaemonProcess is defined inside of the VirtualHost, then log files for other VirtualHost's for different ServerName will be closed. Further, if the VirtualHost has its own access/error log defined by ErrorLog and CustomLog, then the main Apache error log should be closed as well and stdout/stderr or daemon process should be associated with the VirtualHost error log instead. See changes 11 and 12 in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300 Note that the main Apache access log isn't however able to be closed, as it is impossible to find out what its file descriptor is from Apache. If you always ensure that all VirtualHost's have a CustomLog directive, including any default VirtualHost, then the CustomLog in global scope should be commented out. So, if you are still using out of date mod_wsgi 1.X or 2.X then what you say is true, but shouldn't be for mod_wsgi 3.X under stated conditions. > I observed this behavior by looking in /proc/<pid>/fd, where <pid> is the > PID of my WSGI process (which I was able to find because I provided the > display-name argument to WSGIDaemonProcess, see below). > What I'd like to know is > (a) Is this known behavior? > (b) If known, is it intentional? > (c) Is there a configuration parameter which causes apache or mod_wsgi to > close these file descriptors before calling my WSGI process? > (d) If not, is there a way my WSGI application can find out which file > descriptors it needs to keep open, so I can close the rest? (without > resorting to lots of calls to stat() or looking at /proc/<pid>/fd) > Experimentally, it looks like one pipe and one socket that are open need to > be kept open, and the rest are unused. You can't assume that as you don't know what other Apache modules may have opened and no way to know. Best you can do is strip out all Apache modules that aren't needed. > For each site, I have an apache config file like the following in > /etc/apaches/sites-available (and enabled in sites-enabled). Testapp is an > example of one application name; imagine a few copies of this with different > names substituted in for testapp. > <VirtualHost *:80> > ServerName testapp.sundresh.org > ServerAdmin sam...@sundresh.org > DocumentRoot /var/www/testapp/content > WSGIScriptAlias / /var/www/testapp/code/wsgi.py > WSGIDaemonProcess testapp display-name=testapp user=#100103 group=#100102 Why can't you use actual user/group names. There must be a corresponding user/group in existence for them anyway. If no actual user account entry for user then mod_wgsi will fail. > processes=1 Don't set 'processes=1', let it default to 1. If you use 'processes' option, no matter way value, 'wsgi.multiprocess' is set to True, which isn't likely what you want. Using 'processes=1' should only be done when you are load balancing across multiple Apache's where each runs one process and need to mark it as still being multiprocess across all Apache's. > threads=1 umask=0077 That is a really bad umask as created files will be writable by other users. > home=/var/www/testapp > WSGIProcessGroup testapp > WSGIScriptReloading Off There is there little reason having WSGIScriptReloading set to Off as it will force you to do a complete Apache restart when making changes and cant restart individual daemon process groups by touching the WSGI script file. Thus, should only be done for very good reasons. If it is because you share one WSGI script file, then there are other ways of handling per daemon process reloading, not all documented. > <Directory /var/www/testapp> > AllowOverride None > Order allow,deny > Allow from all > </Directory> > ErrorLog /var/log/testapp/error.log > CustomLog /var/log/testapp/access.log combined > </VirtualHost> Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to modw...@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.
