I want to run my Django app created in virtualenv on ubuntu with python3. Folder structure in virtualenv folder:
-bin
-include
-lib
-myapp
-share
pip-selfcheck.json
The myapp folder contains my application with apache folder configured as specified in this tutorial: https://www.sitepoint.com/deploying-a-django-app-with-mod_wsgi-on-ubuntu-14-04/
I have all apps installed I need in my virtualenv, after 'sudo service apache2 restart' I see only Apache2 Ubuntu Default Page.
File /etc/apache2/sites-enabled/000-default.conf is like in the tutorial:
<VirtualHost *:80>
WSGIScriptAlias / /home/myuser/mysite/apache/wsgi.py
<Directory "/home/myuser/mysite/apache/">
Require all granted
</Directory>
</VirtualHost>
Of course with correct paths pointing to my project location in 'venv' folder.
No idea where to move on, what to check, thanks for suggestions.
EDIT:
I realy dont get this, I edited the mentioned file, had a try, nothing happened so I edited it back and after restart it it worked.
The official Django documentation on using mod_wsgi can be found at:
https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/modwsgi/
It may be better to consult that for how to set things up specifically for Django, you are missing various required configuration elements.
As to why you are still getting the default page, it could be because you added that configuration as an extra thing to the end of the default sites file, rather than inserting the contents of the VirtualHost you have into the existing VirtualHost in that file. If you added it after, it will be ignored as it will still use the existing VirtualHost as it comes first and you haven't set up correctly named based hosting.
Also be aware that where other people say you should use something else, every solution will have a learning curve if this is all new. No solution is simple if you want to integrate into your existing host system. So jumping around looking at different solutions can be a great waste of time. Select one which you think you like and stick with it. The idea that one is superior to others is in general nonsense as their performance is similar.
I would actually suggest you skip even trying to integrate it into your host system to begin with if you are just playing. Use a WSGI server that you can run from the command line, even if it is just the bundled development server with Django. Options which are simple to run from the command line are:
mod_wsgi-express
gunicorn
So after editing the file, restarting apache, editing the file back it works (/etc/apache2/sites-enabled/000-default.conf). Really dont get it, several restarts yesterday did not help...
I have Ubuntu 20.04 and Apache2. I followed the mod_wsgi installation instructions linked to here but forgot to enable the module in /etc/apache2/apache2.conf (or to include a file from apache2.conf that does so). I added that and then the WSGIScriptAlias / /home/myuser/mysite/apache/wsgi.py directive in my 000-default.conf did not cause an error when I restarted the server with systemctl restart apache2
I'm in a university and I'm provided with a public_html folder where I can put my CGI scripts. For eg. when I put PHP scripts and visit them from my browser, it works correctly and the PHP is properly interpreted.
I wish to run Django apps in this environment and I know that the university runs an apache server and had mod_php and mod_python installed, although I think I'm not allowed to modify the httpd.conf etc.
All the tutorials that I've read about Django on mod_python ask me to modify the httpd.conf, is there any way I can get my Django site running by making non-sudo changes only?
You can try to put your directives in a .htaccess file in your directory. Dependent on the server config, it might work.
I recently migrated a python django application from a debian system to a redhat enterprise distribution. The application is hosted using httpd, mod_wsgi and running in a venv in an daemon process. On large requests I now get following error message in the log file:
"Truncated or oversized response headers received from daemon process"
I have never experienced anything like this and Google is not the key here as well.
I checked configuration of apache, but no config is related to response headers in there.
My httpd.conf configuration looks like this ( pretty standard):
WSGIPassAuthorization On
WSGIScriptAlias / /var/www/myapp/wsgi.py
WSGIDaemonProcess my.name python-path=/path/to/myapp/:/path/to/venv/lib/python2.7/site-packages display-name=%{GROUP}
WSGIProcessGroup my.name
Does any Guru have a hint in which direction I should look?
We recently ran into this issue, and after days of vigorous ugoogleizing and massive headache, we discovered that we were using psycopg2-binary as our database connector dependency (I know, newbs)! It states right in their documentation not to use the package in a production environment.
We did add all the other proposed answers such as adding 'WSGIApplicationGroup %{GLOBAL}' to our settings (which we kept), but all of them alone and together didn't solve the issue.
We also found that other C libraries like numpy, cause issues.
Hope this helps someone some day.
Django Webfaction 'Timeout when reading response headers from daemon process'
http://initd.org/psycopg/docs/install.html#prerequisites
The code used from Apache by mod_wsgi applies a limit on the size of a single response header returned from mod_wsgi daemon mode processes. This would result in a really cryptic error message from Apache which didn't at all point to the problem. From memory the previous error was:
Premature end of script headers
The size limit was also hard coded in Apache and couldn't be changed. This has caused problems for some Python web applications such as Keystone in OpenStack which generates very large authentication headers.
In mod_wsgi 4.1+, the reliance on the Apache code has been removed and the limit is now configurable. The error message is also more specific as you have seen.
The default maximum header size for what is returned from mod_wsgi daemon mode, that is header name and value, is about 8192 bytes. You can override this by using the header-buffer-size option to WSGIDaemonProcess.
Can you indicate what application and what header was so large that the limit was reached as would like to know what other Python web applications besides Keystone are generating such large headers if is a commonly used application.
A second possibility, deriving from the 'truncated' reference in that message, is that your mod_wsgi daemon process crashed. You don't say though that you saw a 'Segmentation fault' or similar message indicating that a crash occurred. Check for that and if there are other messages in the error log at the time, then indicate what they were and can look at that as the primary problem.
Turned out to be not the actual problem. The problem was lying deeper, as I changed Cairo to CairoCffi and the RSVG-Handler couldn't deal with the Context-Object coming from Cffi.
No my actuall problem is having an up-to-date python lib that allows me to convert svg into png. Using svg2png from CairoSVG isn't working for me. I get an
cairo returned CAIRO_STATUS_NO_MEMORY: out of memory
Error, which I'm sure of, that it does not tell the truth again and the problem lies somewhere else. But lets see.
I had an issue with this in CentOS 7 server when deploying Django using httpd with mod_wsgi 4.5.4. I had to revert back to using mod_wsgi 4.3.2 which solved my problem.
I have installed filebeat which changed my ssl version so that psycopy2 needs to be updated and the error was Truncated or oversized response headers received from daemon process
Do the following:-
Uninstall your psycopy2 package using pip. I am using pip3 because my python version is 3.6.8
sudo pip3 uninstall psycopg2
Reinstall psycopy2 using pip.
sudo pip3 install psycopg2
Before psycopg2-2.7.4 now psycopg2-2.8.3
I suddenly had this same problem after an update. The next update fixed the problem... I run arch, as of the date of this post, the WSGI version in repo works.
I had the same error message "Truncated or oversized response headers received from daemon process '...': /var/www/dev.audiocont.com/index.wsgi" in my Django project (without any other error message).
My error was that I changed the virtual environment and forgot to adapt the Apache settings "dev.conf" to the new venv path.
Change Deadlock time out in httpd.conf
I tried everything ,none of the answer work for me .Then i change the deadlock timeout and everything works fine now .Server Goes in to idle state for long processing just change the deadlock timeout.
I got into the same problem "Truncated or Oversized Response Headers".
I Resolved it by adding,
"WSGIDaemonProcess test user=apache group=apache processes=1 display-name=%{GROUP} header-buffer-size=65536"
in app.conf/httpd.conf depends upon your configuration file.
Based on your server's RAM size change the Processes and header-buffer-size. Default is header-buffer-size is 65536
For me SQLite turned out to be the problem.
I migrated a Django application with SQLite, on a new server, and this error started appearing, and the HTTP requests hanging.
I manage to solve the issue with:
WSGIApplicationGroup %{GLOBAL}'
But, I wanted to get to the bottom of the problem, as this application was not using any different python modules than other applications on the same server.
I realized that the only difference is the SQLite database, and after migrating from SQLite to Postgres, the problem went away.
In the past, I've had other grievances with using Django with SQLite, so I would advise against using SQLite for anything that needs to go into production.
I am very new to apache and django, so execuse me if this question is simple. I am trying to deploy an existing site to an apache server. For the time being, the site is still in development so I am only deploying it as a virtualhost on my local machine.
I am using Django's WSGI module in the deployment. In my site's config file, I have the following aliases:
Alias /media/ /home/tester/Desktop/siteRootDir/media
Alias /content/ /home/tester/Desktop/siteRootDir/content
WSGIScriptAlias /c /home/tester/Desktop/siteRootDir/deploy/site.wsgi
When I run apache and go to localhost/c I was getting the (13)PermissionDenied error in the apache log. To get around that error, I (admitedly stupidly) ran
chmod -R 777 /home/tester/Desktop/siteRootDir
I know that is not the way to deal with the issue, but I just wanted the site to work so I can continue its development.
So my question is, what are the correct permission settings to the siteRootDir directory and its sub-directories such that the site will run and I do not expose unnecessary files in the directory.
Also, I realize that this is not an ideal set up and I will likely run into problems when I deploy the site in production. Can anyone please suggest a better organizational approach to this?
Thanks!
The tightest permissions possible would be 0600 for files and 0700 for dir's and as a owner the user owning the apache processes. This user differs per OS and flavor (e.g. for OSX it's www, for Debian/Ubuntu it's www-data).
This would probably too tight for a development server. At least would you like to be able to modify all your files through your IDE of text editor, so either you should add ACLs for yourself (i.e. the user that edits the Django files, templates and static files).
Also, in a production server you want the apache user to be able to write to directories that hold web uploaded content. That would be somewhere in your static files section (or on a different dedicated static files server).
When I try to run a djapian based search it freezes the applications and I dont get any response from the server. Am deploying the site using mod_wsgi. The search runs fine when i run it in the python shell or in the django dev server. The problem seems to arise only when I deploy my site to apache. Does anyone know how I can get around this issue?
I ran into the same problem when I started using Djapian. You should be able to work around this problem by adding the following to your Apache site
configuration file:
WSGIApplicationGroup %{GLOBAL}
More information on the subject is available here: http://trac.xapian.org/ticket/185 and there's a related ticket for Djapian here: http://code.google.com/p/djapian/issues/detail?id=35