I've read through the docs, and it seems clear.
I have 2 multi-threaded mod_wsgi processes. Normally I just touch the wsgi script and the source code is reloaded. But periodically, changes aren't reloaded, and the problem persists for a few hours. I don't understand what happens to cause it to stop reloading changes, nor what caused it to start reloading again when I've had the problem in the past.
I've tried killing the mod_wsgi processes, but it made no difference. I cannot restart apache myself.
What else can I do to try to force a reload?
How can I prevent this from continuing to happen?
Here is the wsgi configuration:
WSGIScriptAlias /ms20 /var/www-dev/wsgi-scripts/ms20.wsgi
WSGIDaemonProcess ms20 user=glpp group=glab processes=2 display-name=%{GROUP}
WSGIProcessGroup ms20
<Directory "/var/www-dev/wsgi-scripts">
Order allow,deny
Allow from all
</Directory>
You did run the tests in the documentation to validate that requests are handled in the daemon process?
Use the display-name option to WSGIDaemonProcess so you can validate using 'ps' that only the mod_wsgi daemon processes are using a lot of memory and not all the Apache 'httpd' processes. It is possible that your VirtualHost configuration is wrong and your WSGI application is running in embedded mode.
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
Related
So i'm using MacOS Catalina and my Apache environment was running sweet until i decided to move my document root to the iCloud drive, to keep it backed up.
Before my document root was :
/users/admin/www
And now it is
/users/admin/Library/Mobile Documents/com~apple~CloudDocs/www
I edited httpd.conf accordingly :
DocumentRoot "/users/admin/Library/Mobile Documents/com~apple~CloudDocs/www"
<Directory "/users/admin/Library/Mobile Documents/com~apple~CloudDocs/www">
Options FollowSymLinks Multiviews SymLinksIfOwnerMatch
MultiviewsMatch Any
AllowOverride All
Require all granted
</Directory>
<Directory "/users/admin/Library/Mobile Documents/com~apple~CloudDocs/www/myfolder">
Options +FollowSymLinks +Multiviews +SymLinksIfOwnerMatch
MultiviewsMatch Any
AllowOverride All
Allow from All
Require all granted
</Directory>
Restarted Apache, restarted the machine but now i can access 127.0.0.1, EXCEPT one specific folder (let's call it www/myfolder). When i try to access 127.0.0.1/myfolder, i get the error below :
Forbidden
You don't have permission to access / on this server.
Checking the apache log file, this is the error i'm getting :
[Thu Oct 24 14:00:24.830700 2019] [access_compat:error] [pid 61703] [client 127.0.0.1:57804] AH01797: client denied by server configuration: /users/admin/Library/Mobile Documents/com~apple~CloudDocs/www/myfolder/public_html/
What am i missing here ? Please help, i need to work :D
First thing I am seeing is that you are using Apache 2.4 style syntax in your directory block, but then in your error log the module throwing the error is
access_compat. Per the Apache documentation:
The directives provided by mod_access_compat have been deprecated by mod_authz_host. Mixing old directives like Order, Allow or Deny with new ones like Require is technically possible but discouraged. This module was created to support configurations containing only old directives to facilitate the 2.4 upgrade
Next clue is the error code: AH01797. This is caused by a server configuration issue:
Client denied by server configuration
This error means that the access to the directory on the file system was denied by an Apache configuration.
I am assuming here that you are actually using 2.4, and that access_compat is enabled by mistake.
Take a look through your configuration files again, and find the LoadModule directive that is loading mod_access_compat, and comment it out. It might be in your httpd.conf file, but there are numerous different styles of organizing and configuring an Apache install, so it could be elsewhere. If you have a Debian-style install, you need to remove the symbolic link /etc/apache2/mods_enabled/mod_access_compat. Grep -R access_compat * might help.
EDIT 2 more observations:
In the second directory stanza, you have
Allow from all
Require all granted
Which is mixing old directive syntax with new, and is also redundant. Disable access_compat again, and also remove that Allow from all line before restarting Apache.
I don't think the second directory stanza is even necessary. You could probably delete the whole block and restart the server, and it would work.
First try (1) by disabling access_compat and removing that Allow directive from your httpd.conf file, and restart apache using apache2ctl -k graceful. If that doesn't work, comment out the entire second directory stanza and restart again.
I am about 50% sure this will fix it. If it doesn't then I will really need to see your entire httpd.conf file before I can troubleshoot further.
On my virtual server configuration I have this:
DocumentRoot /var/www/project/app/
and also I have this directive:
WSGIScriptAlias / /var/www/project/app/wsgi.py
from mod_wsgi documentation: "avoid placing WSGI scripts under the DocumentRoot in order to avoid accidentally revealing their source code if the configuration is ever changed"
It's clear to me that I must delete the DocumentRoot directive here! I just want to know how it is possible to reveal the code of my wsgi.py file. What kind of request could have a response with that file ?
Change:
WSGIScriptAlias / /var/www/project/app/wsgi.py
to:
WSGIScriptAlias /suburl /var/www/project/app/wsgi.py
Restart Apache and then visit /wsgi.py. It will download and show you your source code.
There is usually no reason to set DocumentRoot to be the directory your WSGI script file is in when using WSGIScriptAlias. By doing it when you don't need to, you are one step away from making your code available if you decided to change your configuration to mount the application at a sub URL and didn't understand the implications of it.
Since it isn't necessary, just don't expose yourself to the extra risk.
I have an Amazon EC2 server running Apache 2.4. I am running one website on there using Python and regular CGI, and then another virtual host using mod_wsgi and an index.wsgi script. When I use a default WSGI callable class object script in my wsgi file, it works fine. However, if I use a WSGI-compatible framework like Flask or Bottle, it loads and works perfectly for about a minute, and then suddenly gives an error 503 ON BOTH OF MY SITES. Even if I change my script back to the default, this error persists for about 5 minutes and then it starts working again. I am using mod_wsgi with the usual daemon mode. Please help. I am using RedHat Linux, Apache 2.4, Python 2.7, and the latest flask and mod_wsgi.
EDIT: Here's my site-specific apache .conf file
<VirtualHost *:80>
ServerName ihave.nolife.lol
WSGIScriptAlias / /var/www/ihave/index.wsgi
WSGIDaemonProcess ihave user=apache group=apache processes=1 threads=5
<Directory /var/www/ihave>
Require all granted
WSGIProcessGroup ihave
WSGIApplicationGroup %{GLOBAL}
</Directory>
ErrorLog /var/www/html/ihave/errorlog
LogLevel debug
CustomLog /var/www/html/ihave/requests combined
Not enough information. But at a guess it is because you are using some third party Python packages which use a C extension module which will not work in sub interpreters. Read the following and set that directive. Also recommended that you make sure you are using daemon mode and not embedded mode.
http://modwsgi.readthedocs.io/en/develop/user-guides/application-issues.html#python-simplified-gil-state-api
I am getting this error while setting up my server for flask and apache on debian.
I've read through similar errors and I have changed all
order allow,deny
Allow from all
to
Options All
AllowOverride All
Require all granted
but still the same error. I've also checked running my applciation with current user (not root) in /var/www and it worked fine and also used a browser on localhost and everything is fine.
I finally succeeded in solving problem by changing
/etc/apache2/sites-available/ispconfig.conf
and commenting out
deny from all
for
<Directory />
but obviously I dont like this solution. It seems I am giving apache permission to root folder.
Any suggestions what is wrong?!
could it be for my python installation or.... I did not use any virtualenv as most tutorials suggested.
Also can I make more debug info available from apache?! I am using LogLevel debug, but I still don't see any more information!
How hard is it for apache to tell me what file has wrong permission!!!
I am attempting to run a Python application within Apache (prefork) with WSGI in such a way that a single Python interpreter will be used. This is necessary since the application uses thread synchronization to prevent race conditions from occurring. Since Apache prefork spawns multiple processes, the code winds up not being shared between the interpreters and thus the thread synchronization is irrelevant (i.e. each thread only sees it own locks which have no bearing on the other processes).
Here is the setup:
Apache 2.0 (prefork)
WSGI
Python 2.5
Here is the relevant Apache configuration:
WSGIApplicationGroup %{GLOBAL}
<VirtualHost _default_:80>
WSGIScriptAlias / /var/convergedsecurity/apache/osvm.wsgi
Alias /admin_media/ /var/www/html/admin_media/
<Directory /var/www/html/admin_media>
Order deny,allow
Allow from all
</Directory>
Alias /media/ /var/www/html/media/
<Directory /var/www/html/media>
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
Here is what I tried so far (none of which worked):
Adding WSGIApplicationGroup %{GLOBAL}
Specifying WSGIDaemonProcess and WSGIProcessGroup within the virtual host:
WSGIDaemonProcess osvm threads=50
WSGIProcessGroup osvm
Is there no way to force Apache prefork to use a single Python interpreter with WSGI? The documents seem to imply you can with the WSGIDaemonProcess and WSGIApplicationGroup options but Apache still creates a separate Python interpreter for each process.
You can't have the WSGI application run in embedded mode on UNIX systems, whether it be prefork or worker MPM, as there will indeed be multiple processes. See:
http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
Creating a daemon process group consisting of single process and delegating WSGI application to that should achieve what you want. You shouldn't even need to use WSGIApplicationGroup if it is only one mounted WSGI application you are talking about. If you want to be absolutely sure though, you can also set it.
Thus configuration within VirtualHost would be:
WSGIDaemonProcess osvm
WSGIProcessGroup osvm
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /var/convergedsecurity/apache/osvm.wsgi
Although 'processes=1' for WSGIDaemonProcess makes it explicit that one process is created, don't provide the option though and just let it default to one process. Any use of 'processes' option, even if for one process will see 'wsgi.multiprocess' set to True.
Rather than use your actual WSGI application, I would suggest you test with the following simple test program.
import cStringIO
import os
def application(environ, start_response):
headers = []
headers.append(('Content-Type', 'text/plain'))
write = start_response('200 OK', headers)
input = environ['wsgi.input']
output = cStringIO.StringIO()
print >> output, "PID: %s" % os.getpid()
print >> output
keys = environ.keys()
keys.sort()
for key in keys:
print >> output, '%s: %s' % (key, repr(environ[key]))
print >> output
output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'))))
return [output.getvalue()]
In the output of that, the PID value should always be the same. The wsgi.multiprocess flag should be False. The mod_wsgi.process_group value should be what ever you called the daemon process group. And the mod_wsgi.application_group should be an empty string.
If this isn't what you are seeing, ensure you actually restarted Apache after making configuration changes. Also add:
LogLevel debug
to Apache configuration for VirtualHost. Doing that will cause mod_wsgi to log a lot more messages in Apache error log about process creation and script loading, including details of process group and application group things are happening for.
For other information on debugging, see:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
If still problems, suggest you go to the mod_wsgi mailing list on Google Groups.