On Wed, Sep 15, 2010 at 10:47 PM, Graham Dumpleton < [email protected]> wrote:
> On 16 September 2010 15:31, Sameer Sundresh <[email protected]> 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 > Thanks, it appears that I'm still using mod_wsgi 2.6. I'll try 3.x, and hopefully that will solve my problem. 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. > Good idea. 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. I agree, it's just an observation. > 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 [email protected] > > 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. > Is mod_wsgi's notion of umask different from the standard unix umask? My understanding was that this would deny r/w/x from group and other. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<modwsgi%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
