I’m trying to host a django project on my server with apache2 and mod_wsgi. I’ve followed the tutorial on the Django documentation and some other tutorial however, none of them worked.
I want to have my Django Project at myurl.com/recettes but actually I have the 404 error of Apache.
My Server is on Ubuntu 20.04 with Apache 2.4.41, my venv is with Python 3.8 and Django 4.0.5
My VHost :
<VirtualHost *:80>
ServerName myurl.com
ServerAlias www.myurl.com
Alias /static /home/myurl.com/static
<Directory /home/myurl.com/static>
Require all granted
</Directory>
WSGIScriptAlias /recettes /home/myurl.com/MyProject/wsgi.py process-group=myurl.com
<Directory /home/myurl.com/MyProject>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
WSGIDaemonProcess MyProject python-home=/home/myurl.com/env python-path=/home/myurl.com
WSGIProcessGroup MyProject
</VirtualHost>
My wsgi.py
import os, sys
sys.path.append("/home/myurl.com/recettes")
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'recettes.settings')
application = get_wsgi_application()
I can give more informations if you want. Thanks for helping me ^^
Note that your process-group reference in the first quote below does not match the process group definitions shown in the second and third quotes.
(Note, this may not be the only problem here, just the first one I spotted.)
Also, for all cases like this, it may be worthwhile for you to set your Apache instance to debug and check your logs carefully. Usually the logs have some hints in them when trying to diagnose problems.
It may be useful to review the docs at Quick Configuration Guide — mod_wsgi 5.0.0 documentation
In addition to restarting Apache, you may also want to verify that the daemon process is running.
I fixed the first problem and i was watching if the daemon is running but it seems not.
For the logs, actually I have no error. I will read again the docs of mod_wsgi.
I try a few things but it doesn’t work, i didn’t understand why the daemon isn’t running.
I’d set the log level for Apache to debug, and I’d check both the apache logs and syslog to see if mod_wsgi is even trying to start. (If it starts and fails, there should be syslog messages for it.)
I’d also double/triple check that your file and directory permissions are correct. Apache needs access to those files, so that entire directory tree should be owned either by the user or group that apache runs as.
I think think the daemon start, I have a log :
But after, I have another strange log :
Furthermore, permissions seems correct.
I can’t quite read these images, but if those first messages contain the PID for the daemons, then you can use the ps command to verify that they’re still running.
I really can’t tell what that second image is supposed to be showing.
The Daemons seems good :
UID PID PPID C STIME TTY STAT TIME CMD
www-data 87227 29250 0 14:30 ? Sl 0:00 /usr/sbin/apache2 -k start
The second picture shows that :
||[Tue Jul 12 14:34:14.815932 2022] [ssl:debug] [pid 87229] ssl_engine_kernel.c(415): [client 81.220.149.245:58853] AH02034: Initial (No.1) HTTPS request received for child 1 (server les-roseaux.dev:443)
││[Tue Jul 12 14:34:14.816098 2022] [authz_core:debug] [pid 87229] mod_authz_core.c(817): [client 81.220.149.245:58853] AH01626: authorization result of Require all granted: granted ││[Tue Jul 12 14:34:14.816114 2022] [authz_core:debug] [pid 87229] mod_authz_core.c(817): [client 81.220.149.245:58853] AH01626: authorization result of <RequireAny>: granted ││[Tue Jul 12 14:34:14.816232 2022] [core:info] [pid 87229] [client 81.220.149.245:58853] AH00128: File does not exist: /var/www/html/recettes/
││[Tue Jul 12 14:34:14.896071 2022] [ssl:debug] [pid 87229] ssl_engine_kernel.c(415): [client 81.220.149.245:58853] AH02034: Subsequent (No.2) HTTPS request received for child 1 (server les-roseaux.dev:443), referer: https://les-roseaux.
││[Tue Jul 12 14:34:14.896091 2022] [authz_core:debug] [pid 87229] mod_authz_core.c(817): [client 81.220.149.245:58853] AH01626: authorization result of Require all granted: granted, referer: https://les-roseaux.dev/recettes/
││[Tue Jul 12 14:34:14.896095 2022] [authz_core:debug] [pid 87229] mod_authz_core.c(817): [client 81.220.149.245:58853] AH01626: authorization result of <RequireAny>: granted, referer: https://les-roseaux.dev/recettes/
││[Tue Jul 12 14:34:14.896108 2022] [core:info] [pid 87229] [client 81.220.149.245:58853] AH00128: File does not exist: /var/www/html/favicon.ico, referer: https://les-roseaux.dev/recettes/
││[Tue Jul 12 14:34:14.897012 2022] [ssl:debug] [pid 87229] ssl_engine_io.c(1102): [client 81.220.149.245:58853] AH02001: Connection closed to child 1 with standard shutdown (server les-roseaux.dev:443)
Sorry for the precedent pictures ^^
The pid you show here is for the apache master process itself. I would expect the mod_wsgi daemons to show up as a list of one or more separate processes. (You should also have multiple apache worker processes as well.)
Unfortunately, I no longer have an apache instance that I can verify this with. (It’s been almost 10 years since I’ve deployed to Apache at all, and closer to 15 since I’ve used mod_wsgi.) If you’re not getting more useful detail than this in the logs, I’m beginning to doubt that I’m going to be able to help you.
Ok, I will continue to search, thanks for the help ^^
There is multiple process for Apache but 0 for wsgi.
I will toss out one more item that I know trip some people up.
From: Virtual Environments — mod_wsgi 5.0.0 documentation
When using a Python virtual environment with mod_wsgi, it is very important that it has been created using the same Python installation that mod_wsgi was originally compiled for. It is not possible to use a Python virtual environment to force mod_wsgi to use a different Python version, or even a different Python installation.
(more details follow on that page)
1 Like
I have already corrected this problem yesterday, so it isn’t that… I’ll continue to search 
Did you find the solution? Coz I am new too and trying to deploy my first app into production and getting something same problems.
Finally I move entirely to nginx, it’s easier.
