I've been trying to get MOD_WSGI working on Apache via XAMPP on my Mac OS X Snow Leopard all day today without any success. I've followed all the instructions, searched the internet for solutions, etc but no luck so far. Below are my exact steps and details. When I run localhost all I get is a white screen. When I remove "LoadModule wsgi_module modules/mod_wsgi.so" from httpd.conf localhost runs as expected.
Downloaded and installed Xcode.
XAMPP is already installed and working.
I Don't need to install Python as OS X already has Python 2.6 in 64-bit mode.
Download and unpack mod_wsgi-2.6.tar.gz to desktop.
Terminal "./configure --with-apxs=/Applications/XAMPP/xamppfiles/bin/apxs --with-python=/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6" (no errors)
Terminal "make" (message "make: Nothing to be done for `all'.")
Terminal "sudo make install" (no errors)
Add to XAMPP's httpd.conf file:
LoadModule wsgi_module modules/mod_wsgi.so
AddType text/html .py
WSGIScriptAlias /app-sample "/Applications/xampp/xamppfiles/htdocs/app-sample/main.py"
<Directory "/Applications/xampp/xamppfiles/htdocs/app-sample">
Order deny,allow
Allow from all
</Directory>
Restart Apache via XAMPP
First off, run 'make distclean' and then redo configure/make/make install for mod_wsgi. Where you have 'Terminal "make" (message "make: Nothing to be done for `all'.")' indicates there were prior build results in directory and nothing got built for that execution of make.
Next, use '.wsgi' extension instead of '.py' to ensure that you don't have a conflict with an existing definition saying that '.py' files should be executed as CGI scripts. This is one common reason for blank responses. The Apache error logs should give you clues as to this being the problem.
Also, what does your sample application do? Have you tried with a simple hello world program as per the documentation on the mod_wsgi site rather than jump to using your own program. If using your own program only, then you may possibly be causing Apache processes to crash due to some shared library conflict between Apache and Python modules being used, something else that will cause blank responses. Again, carefully check the Apache error logs for information logged at time request is made.
Finally your program could just be buggy and have bad syntax in returned HTML response causing it to not be displayed. Ask the browser to show the source for the page returned by the request and make sure it isn't malformed HTML.
Related
System:
Windows 10 x64 (enterprise computer with some restrictions)
Apache 2.4 64-bit
Python 3.7.1 64-bit
mod_wsgi (built today from github using python setup.py install)
I am working on getting an Apache server with Python on a Windows machine and I have the server configured correctly in order to get the Hello World! example from mod_wsig documentation working.
If I simply launch C:\Apache24\bin\httpd.exe, this works and I see Hello World at http://localhost:5000/
Then I wanted to get it running as a service, so I call
httpd.exe -k install
In the ApacheMonitor I start the new Apache2.4 service but I get a failed to start error. In the Windows system event log it says Event ID: 7024 with a service specific error: Incorrect function.
When I run httpd.exe -k start -n "Apache2.4" -t it says Syntax OK
What I can't find is any more information about the service error. Nothing populates in the error.log file and I don't know where else to look, and I am asking for any further information on how to diagnose this.
Before I started configuring Apache to use mod_wsgi, launching the service was successful, so this happened after doing that, and I haven't configured anything else at this point.
Go to the Command Prompt move to the apache/bin folder and type
>httpd -t
This will give you more information about the error preventing Apache from start.
I was getting this error after updating my httpd.conf file. The problem was that my final xml tag in httpd.conf was unclosed </directory without the closing >.
This days I was facing the same situation, windows 10, apache24, django app, python3.8, failing to start as service, service events showing error 7024...
So, after a lot of struggling and research, I would like to add my solution even this is an old question.
The solution was to add two environment variables, no in httpd.conf, not in python code/conf but at SO level (windows > environment variables)
PYTHONHOME = c:\your\path\to\installed\python
PYTHONPATH = c:\your\path\to\installed\virtualenv
And magic! apache now works as service and the django app is always available on localhost
I am using Windows 8.1. and trying to configure XAMPP (apache 2.4, VC11) to work with Python (I have 2.7) and Django (1.7). Have downloaded mod_wsgi (VC9), changed httpd.conf but still getting Apache shut down: Any clues?
Error: Apache shutdown unexpectedly. 06:24:31 [Apache] This may be
due to a blocked port, missing dependencies, 06:24:31 [Apache]
improper privileges, a crash, or a shutdown by another method.
06:24:31 [Apache] Press the Logs button to view error logs and check
06:24:31 [Apache] the Windows Event Viewer for more clues 06:24:31
[Apache] If you need more help, copy and post this 06:24:31 [Apache]
entire log window on the forums
Since you are using python 2.7, Your Apache must be compiled with VC9, You can download the required Apache from - (https://www.apachehaus.com/cgi-bin/download.plx#APACHE24VC09). Make sure you download the 32 bit version if you are running a 32 bit python installation or the 64 bit version if your python installation is 64 bit.
I have a strange issue, if I restart Apache with my DJANGO Application then static files respond just fine (like the Apache Status Page shows it is handling requests). There are no errors in the log files, and WSGI loads as far as the logfile is concerned.
The problem is that my DJANGO/Python/WSGI Application is not responding to any requests, the web page just times out. I have to restart Apache over and over again, sometimes for up to an hour before the application finally responds. The strange part is that sometimes it will restart immediately. Nothing helps, boot order has no affect, restarting the entire server has not helped. I chased down linked libraries and cleared out the duplicate loading from other requests that I have seen.
A few environment items:
Windows Server Apache 2.2
Python 2.6
Django 1.4.5
MOD_WSGI 3.5 for Windows Apache (http://www.lfd.uci.edu/~gohlke/pythonlibs/#mod_wsgi)
One last detail:
If I block HTTP and HTTPS ports using the firewall and restart Apache then enable the firewall then the service comes right up. So there seams to be some problem with active sessions and Apache/WSGI/Pyhton/Django.
Any ideas on what I can tweak in my WSGI or Apache configuration to get the application to come right up?
I am not able to log the apache2 crashes in CoreDumpDirectory on ubuntu 10.10. I am using Django 1.2.3 and apache2 with mod_wsgi. I followed the steps listed in response to this question but to no avail. I added - CoreDumpDirectory /var/cache/apache2/
at the end of apache2.conf file and then after executing
'ulimit -c unlimited', restarted the apache server. Then I replicated the condition that causes apache error log to show- "child pid 27288 exit signal Segmentation fault (11)" but there is no mention of apache2 logging that crash in CoreDumpDirectory and also there is nothing in /var/cache/apache2.
I also ran into this problem of mod_wsgi children not dumping core. Long story short: You need to edit /etc/sysctl.conf and set fs.suid_dumpable=2.
Long story:
Linux prevents dumping core for processes that started as root and then dropped privileges. (This is a security feature, so SUID executables don't leak their memory to the user). Setting suid_dumpable=2 means that core files will be owned by root, so there's no direct security problem there either.
Why this affects mod_wsgi? Apparently mod_wsgi's child processes are forked off from Apache's main process. Apache usually starts up as root, since it needs to bind privileged port numbers like 80, and then drops privileges.
(Original bug report: https://code.google.com/p/modwsgi/issues/detail?id=247)
I was able to solve this problem. The issue was with PyLucene environment being initialized on the run time. I was executing initvm() call everytime a request comes and it was causing segmentation fault. This link directed that I should do it in .wsgi file and after I did that there were no segmentation faults.
My Apache server runs on some non-default (not-root) account. When it tries to run a python script which in turn executes a subversion check-out command, 'svn checkout' fails with the following error message:
svn: Can't open file '/root/.subversion/servers': Permission denied
At the same time running that python script with subversion checkout command inside from command line under the same user account goes on perfectly well.
Apache server 2.2.6 with mod_python 3.2.8 runs on Fedora Core 6 machine.
Can anybody help me out? Thanks a lot.
It sounds like the environment you apache process is running under is a little unusual. For whatever reason, svn seems to think the user configuration files it needs are in /root. You can avoid having svn use the root versions of the files by specifying on the command line which config directory to use, like so:
svn --config-dir /home/myuser/.subversion checkout http://example.com/path
While not fixing your enviornment, it will at least allow you to have your script run properly...
Try granting the Apache user (the user that the apache service is running under) r+w permissions on that file.
Doesn't Apache's error log give you a clue?
Maybe it has to do with SELinux. Check /var/log/audit/audit.log and adjust your SELinux configuration accordingly, if the audit.log file indicates that it's SELinux which denies Apache access.
The Permission Denied error is showing that the script is running with root credentials, because it's looking in root's home dir for files.
I suggest you change the hook script to something that does:
id > /tmp/id
so that you can check the results of that to make sure what the uid/gid and euid/egid are. You will probably find it's not actually running as the user you think it is.
My first guess, like Troels, was also SELinux, but that would only be my guess if you are absolutely sure the script through Apache is running with exactly the same user/group as your manual test.
Well, thanks to all who answered the question. Anyway, I think I solved the mistery.
SELinux is completely disabled on the machine, so the problem is definitely in 'svn co' not being able to found config_dir for the user account it runs under.
Apache / mod_python doesn't read in shell environment of the user account which apache is running on. Thus for examle no $HOME is seen by mod_python when apache
is running under some real user ( not nobody )
Now 'svn co' has a flag --config-dir which points to configuration directory to read params from. By default it is $HOME/.subversion, i.e. it corresponds to the user account home directory. Apparently when no $HOME exists mod_python goes to root home dir ( /root) and tries to fiddle with .subversion content over there - which is obviously
fails miserably.
putting
SetEnv HOME /home/qa
into the /etc/httpd/conf/httpd.conf doesn't solve the problem because of SetEnv having nothing to do with shell environment - it only sets apache related environment
Likewise PythonOption - sets only mod_python related variables which can be read with req.get_options() after that
Running 'svn co --config-dir /home/ ...' definitely gives a workaround for running from within mod_python, but gets in the way of those who will try to run the script from command line.
So the proposed ( and working) solution is to set HOME environment variable prior to starting appache.
For example in /etc/init.d/httpd script
QAHOME=/home/qa
...
HOME=$QAHOME LANG=$HTTPD_LANG daemon $httpd $OPTIONS
What is happening is apache is being started with the environment variables of root, so it thinks that it should find its config files in /root/. This is NOT the case.
what happens is if you do sudo apache2ctl start, it pulls your $HOME variable from the sudo $HOME=/root/
I have just found a solution to this problem myself (although with mod_perl, but same thing)
run this command (if its apache 1, remove the 2):
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start
When /etc/init.d/apache2 starts apache, it sets all the proper environment variables that apache should be running under.