Django code changes not reflecting on production server - python

I changed a .py file and changes reflected on local dev. server for Django after deleting .pyc.
The production server does not even have .pyc for this specific file. Tried touching apache wsgi and restarting apache on prod. server but no luck.
Even deleting this .py file makes application work the same. There is memcached installed but I don't have much idea how it caches, there is .git as well and 5 servers are hosting - one main, 4 load balancers.
Regards !

Are 100% sure you are looking at the right server you are making the changes to? I know that sounds stupid but, why don't you stop Apache, can you still run the page then? IF you can then you definitely don't have the correct server.
If not, next try reloading Apache (thats different from restarting).
sudo service apache2 reload
If this still does not work then post your Apache setup, if must be looking on the wrong folder to the one your pushing to.

You have to restart your server (WSGI, UWSGI or whatever your use on production environment)

If you use uwsgi as gateway set touch-reload param in uwsgi settings
and you need just
$ touch <your-touch-reload-file>
in console for reflecting on changes
If you use apache with mod_python or mod_wsgi, you have to restart apache for apply changes

Related

django - Changes in template files are not shown

I'm working on a django project, after changing some templates, it works on my local machine, but after uploading to production server (+restarting Apache) webserver shows the old code!
Its about few specific base template files.
I have tried to restart server, reload webserver and reinstall venv.
None of it worked.
Do I use template/fragment caching? No.
Do I use apache's caching? No.
UPDATE :
i just made some changes to one of another app's template files and uploaded it
after refresh, it updated right away!
now i am pretty sure that this problem is happening to only 1 of my apps
In my case, using gunicorn, I solved it this way:
sudo systemctl restart gunicorn-django-tutorial.service
The changes are not shown in production because gunicorn needs to reload the configuration.
A restart of the web server is not needed (I'm using Nginx).

Django settings.py not updating on production

I have a server that is live right now, there is some SMTP stuff I want to change the settings.py of my Django project. I have made the changes, however, I cannot get the server to detect the changes, and it throws a SMTPAuthentication error because the settings.py is still using the old settings.
The server is set up with nginx, and I have tried service nginx reload several times, and apachectl restart several times. As well as deleting any *.pyc files.
nginx cannot be actually running the site, as it is not a WSGI server. Presumably it is running as a proxy to something like gunicorn or uWSGI; it is those that you need to restart.
Autoreload in production is not good idea, but if you understand what you do, you can use additional python module for autoreloading or use additional param for uwsgi. Django devel autoreloading not works with uwsgi.

Nginx - Seems to be running old python scripts

I have a website (panicselect.com), and I have made some changes to the python code which i pushed onto Github and then pulled onto my server, which seems to be successful. I have tried restarting the server, but it still seems to be running my older version of the code even though I have successfully pulled the new version. I believe this as some 'champions' are still missing and the rating seems to be calculated the old way, which is in contrast to what is on my localhost. Do you have an idea of what this could be? I'm running Ubuntu Linux on Digital Ocean with sendfile off and nginx uses Uwsgi to run the Py code.
To fully determine how to deploy changes to your production server, you must understand 2 things:
1. Most WSGI servers (including uWSGI) will load code on start, not on each execution.
That means, changes in your code won't be reflected immediately, because old code is still loaded into your WSGI server. It differs from PHP execution, where code is reloaded on every request. That means, you must restart your WSGI server when you want your new code to be loaded.
2. WSGI and nginx are NOT related
Yes, nginx will connect your WSGI server to outside world, but that's it! It doesn't manage your WSGI server. That means, you must restart your WSGI server by hand. Restarting nginx won't cause that.
Also it is good to note here: restarting nginx is not required, unless you've changed nginx configuration.

Django + apache & mod_wsgi: having to restart apache after changes

I configured my development server this way:
Ubuntu, Apache, mod_wsgi, Python 2.6
I work on the server from another computer connected to it.
Most of the times the changes don't affect the application unless I restart Apache.
In some cases the changes take effect without restarting the webserver, but after let's say 3 or 4 page loads the application might behave like it used to behave previous to the changes.
Until now I just reloaded everytime apache as I have the development server here with me, but HELL after a while got so annoying. How can I avoid this?
I can't work with the development server as I need an environment that is as close as possible as the production one.
Thanks
My suggestion is that you run the application in daemon mode.
This way you won't be required to restart apache,
just touch my_handler.wsgi and the daemon will know to restart the app. The apache httpd will not be only yours (in production) so it is fair not to restart it on every update.
No changes require you to RESTART. You simply need to reload using "sudo /etc/init.d/apache2 reload". Which I have aliased in my bashrc to 'a2reload'.
function a2reload (){
sudo /etc/init.d/apache2 reload
}
Apache loads Django environment when starting and keep running it even when source is changed.
I suggest you to use Django 'runserver' (which automatically restarts on changes) in heavy development sessions, unless you need some Apache-specific features (such as multi-thread).
Note also that changes in templates do not require the restart of the web server.

Restarting a Django application running on Apache + mod_python

I'm running a Django app on Apache + mod_python. When I make some changes to the code, sometimes they have effect immediately, other times they don't, until I restart Apache. However I don't really want to do that since it's a production server running other stuff too. Is there some other way to force that?
Just to make it clear, since I see some people get it wrong, I'm talking about a production environment. For development I'm using Django's development server, of course.
If possible, you should switch to mod_wsgi. This is now the recommended way to serve Django anyway, and is much more efficient in terms of memory and server resources.
In mod_wsgi, each site has a .wsgi file associated with it. To restart a site, just touch the relevant file, and only that code will be reloaded.
As others have suggested, use mod_wsgi instead. To get the ability for automatic reloading, through touching the WSGI script file, or through a monitor that looks for code changes, you must be using daemon mode on UNIX. A slight of hand can be used to achieve same on Windows when using embedded mode. All the details can be found in:
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
You can reduce number of connections to 1 by setting "MaxRequestsPerChild 1" in your httpd.conf file. But do it only on test server, not production.
or
If you don't want to kill existing connections and still restart apache you can restart it "gracefully" by performing "apache2ctl gracefully" - all existing connections will be allowed to complete.
Use a test server included in Django. (like ./manage.py runserver 0.0.0.0:8080) It will do most things you would need during development. The only drawback is that it cannot handle simultaneous requests with multi-threading.
I've heard that there is a trick that setting Apache's max instances to 1 so that every code change is reflected immediately--but because you said you're running other services, so this may not be your case.

Categories

Resources