I updated one environment variable inside settings.py and restarted gunicorn, but it is seeing the old settings. Here is the command I use to start it:
nohup /opt/my_proj/.virtualenvs/my_proj/bin/python2 /opt/my_proj/.virtualenvs/my_proj/bin/gunicorn --bind=0.0.0.0:8008 --timeout=1800 --log-level=debug --error-logfile=/opt/my_proj/gunicorn_nik.log --enable-stdio-inheritance --capture-output --user=me --pythonpath=/opt/me/code/my_proj,/opt/me/code/my_proj/seqr_settings wsgi &
I printed out paths to make sure that the scripts are running under my 'my_proj' directory and also looked up in 'gunicorn_nik.log' verifying that there I see it pointing to 'my_proj' folder. Then I removed settings.py to make sure still that it is the file gunicorn is picking up. The startup failed. I tried modifying settings.py printing out something from it but it is not working, logger.info is not printing from there.
I have several Django projects on one cluster node running (not sure that it is important).
Its as if Django is storing some cached file and using it, but how come gunicorn restart does not fix it? Seems weird to me. Any suggestions would be greatly appreciated.
The issue was that in .bashrc an environment variable was set that was somehow overwriting the value in settings.py that was having the same name.
Related
We are facing a very weird issue. We ship a django application in a docker container through Github Actions on each push. Everything is working fine except collectstatic.
We have the following lines at the end of our CD github action:
docker exec container_name python manage.py migrate --noinput
docker exec container_name python manage.py collectstatic --noinput
migrate works perfectly fine, but collectstatic just keeps on waiting if ran through the github action. If I run the command directly on the server then it works just fine and completes with in few minutes.
Can someone please help me figuring out what could be the issue?
Thanks in advance.
Now I am far from the most experienced but I did this recently and I have some suggestions of where to look. I'm definitely not the greatest authority though.
I wasn't using docker so I can't say anything about that. From the issues, I had here are some suggestions I can recommend to try.
Take note that all of this was for a self-hosted runner. Things would be very different otherwise.
Check to make sure STATIC_ROOT and MEDIA_ROOT variables are set correctly in the settings file.
If the STATIC and MEDIA root variables are environment variables make sure you are serving the correct environment variables file like a .env file which I used.
I used django-environ to serve my environment variables. From the docs, it says to have the .env file in the same directory as the settings file. Well if you are putting the project on a production server with github actions, you won't be able to put the .env file anywhere in the project because it will get overwritten every time new code is pushed.
So to fix that you need to specify the correct .env file from somewhere else on the server. Do that by specifying ENV_PATH.
https://django-environ.readthedocs.io/en/latest/
Under the section Multiple env files
Another resource that was helpful:
https://github.com/joke2k/django-environ/issues/143
I set up my settings file like how they did there.
I put my .env file in a proj directory I made in the virtualenvironment folder for the project.
I don't know if it's a good place to put it but that's how I did it. I didn't find much great info online for this stuff. Had to figure out a lot on my own.
Make sure the user which is running the github action has permissions to read the .env file.
Also like .env file, if you have the static files being collected into the base directory of your project you might have an issue with github actions overwriting those files every time new code is pushed. If you have a media directory where the user uploads files to then that will really be an issue because those files won't get overwritten. They'll just disappear.
Now if this was an issue it shouldn't cause github actions to just get stuck on the collect static command. It would just cause files to get overwritten every time the workflow runs and the media files will disappear.
If you do change the directory of where the static and media files are located as stated before, make sure all the variables for the paths are correct in the settings file and the .env file.
You will also need to update the nginx config file for the static and media root directories if you used nginx. Not sure about how apache does this.
You can do that with this command:
sudo nano /etc/nginx/sites-available/myproject
Don't forget to restart the nginx server after doing that.
If you are writing static and media files at a different location from the base project directory on the server, also check permissions on those directories. Make sure the user running the github action has permissions to write to those directories. I suspect that might cause it to hang but it very well might just cause an error.
Check all the syntax in the github actions yml file. Make sure everything is correct and it's not hanging cause it had an incomplete command or something like that.
But yeah, that's some things I had to take a look at. Honestly, none of this might be relevant for you. All of these issues should cause an error somewhere for the most part.
I couldn't really offer many external resources for you to look deeper into this because I'm just speaking from personal experience.
Hope I could help.
Heres my github repo for the project I did: https://github.com/pkudlanov/personal-portfolio-django
I hosted it on digitalocean on a linux server using nginx and gunicorn.
I know my .env file is loading but for some reason it seems to be jumping back to 'config.settings.local'?
I am using the latest Cookiecutter code.
this is my .env settings.
DJANGO_ALLOWED_HOSTS=178.128.108.20,178.128.108.20:8000,*
DJANGO_ADMIN_URL=admin
DJANGO_DEBUG=True
DJANGO_SETTINGS_MODULE='config.settings.production'
DJANGO_SECRET_KEY=2l#$#-#2z...=6n7-ejd%+51
below are the settings I get back from Ubuntu after it can not find the allowed host setting.
The DJANGO_ALLOWED_HOSTS is set for the correct address but I get back an error about not being set.
Than I noticed some setting like the DJANGO_SETTINGS_MODULE have changed back to the local host.
Any ideas why?
Here is what I get back from my development server. Note the change in the config.setting to local.
And here is my disallowed host message back from Ubuntu.
As you can see the local host is set for this address.
here is the beginning Cookiecutter code:
env = environ.Env()
READ_DOT_ENV_FILE = env.bool('DJANGO_READ_DOT_ENV_FILE', default=True)
if READ_DOT_ENV_FILE:
# OS environment variables take precedence over variables from .env
env.read_env(str(ROOT_DIR.path('.env')))
All this admin stuff is not my thing. Sorry if it is foolish question.
Thanks.
I spent days chasing this issue and it turns out that if you do not set up Cookiecutter for either Heroku or Docker it does not set up the .envs folders that are needed.
Once I rebuilt the site with the Heroku option, I was able to solve my .envs issues.
use_heroku [n]: y
I can now set it up on Ubuntu (using Digital Ocean) and get the 'config.settings.production' to work.
Cheers.
I am trying to get a django app to work on ubuntu with apache.
I am getting the error message "You may need to add 'x.x.x.x' to ALLOWED_HOSTS."
I have made the changes to settings.py, but still get the error message. I can see in the debug output that it looks like the changes I made to settings.py are not taking effect. I have tried restarting apache ( /etc/init.d/apache2 restart) but still no help.
Any input would be greatly appreciated.
thanks!
Bob
Do you have ALLOWED_HOSTS defined 2 times in settings.py ? It should be defined only 1 time.
Are you managing your project files on the Ubuntu server directly or via FTP?
Just add sudo before when running server script using python and it works like a charm. ex
sudo python3 manage.py runserver 0.0.0.0:8000
I am having some trouble setting environment variables in my production environment, I have some logic in django settings that depends on it. I have tried exportng it through variouse places '/etc/profile, ~.bashrc, etc'
The problem is that those only set them when there is a login (I believe?) But if I navigate a browser to the server I can see that the variable was not set correctly through the debug. I am running django1.7/gunicorn/nginx. I suspected to put it in the gunicorn /etc/init/gunicorn.conf but that did not work.
How can I set this?
You could set them in the WSGI file. – Simeon Visser
Thanks, this solved my problem for my purposes. I don't believe that the wsgi file runs on the dev server so it worked perfectly and only set the variable on the production. Thanks
I'm setting up a Django project with different files for local and production settings. I can confirm that my Django secret key is successfully in an environment variable in virtualenv and when I do runserver I get no error. However when I try manage.py syncdb I get
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.
I don't understand why I can successfully browse to the site after runserver but I can't sync the database. When I run env I can see that the secret key is there and in my base settings file (imported into local settings) I am doing this:
SECRET_KEY = os.environ.get('MY_SECRET_KEY')
Any help debugging this would be greatly appreciated.
Euan
I'm not sure why the runserver command is working while syncdb isn't, but you can sort it out by adding a environment variable for DJANGO_SETTINGS_MODULE in the same way you did for the SECRET_KEY. The only difference is that you don't need to reference DJANGO_SETTINGS_MODULE within the django code anywhere. I'm running my own setup in exactly that way and the only problem I run into is forgetting to change the settings module when I switch between projects :-)
EDIT: I didn't realise that you were adding --settings=myapp.settings.local to runserver as well as syncdb. The reason you need to do this is that you are using settings on a different path from the default so python can't find them. Also, although you set the DJANGO_SETTINGS_MODULE in the wsgi file, this is only fired when the site is accessed via your webserver. When running a manage command the wsgi file is ignored (AFAIK) so adding DJANGO_SETTINGS_MODULE to your environment variables in the same way as SECRET_KEY makes your settings file available to the manage command.
Hope that helps
Somewhat similar situation here, using virtualenv running an outer script which involves django models.
To make this work please make sure:
Your sys.path list has a path to your virtualenv site-packages. For me it's: sys.path.append('/home/user/.virtualenvs/Project/local/lib/python2.7/site-packages')
Your django settings variable is added to os.environ. Eg: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "Project.settings")