0

I am having a problem to deploy my django application on a CentOS 7 test server. Initially install the miniconda, through the root profile on the server, then perform the copy of the application and add both the env, created by the conda command, as an application in the 1002: 1002 group.

After that, I release the bash script created to activate the gunicorn and the application's internal folder, for 755 and + x permission and add group 1002:1002.

But anyway, adding the miniconda3 folder and djangoapp application folder to the 100x: 100x group I can not deploy.

My script

#!/bin/bash

NAME="djangoapp"
DJANGODIR=/var/www/dangoapp
SOCKFILE=/var/www/djangoapp/run/gunicorn.sock
USER=nginx
GROUP=webdata
NUM_WORKERS=5
DJANGO_SETTINGS_MODULE=app.settings
DJANGO_WSGI_MODULE=app.wsgi
TIMEOUT=3600

echo "Starting $NAME as `whoami`"

cd $DJANGODIR
source activate djangoapp
export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
export PYTHONPATH=$DJANGODIR:$PYTHONPATH

RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR

#exec gunicorn ${DJANGO_WSGI_MODULE}:application \
exec /home/adm/miniconda3/envs/ws/bin/gunicorn ${DJANGO_WSGI_MODULE}:application \
 --name $NAME \
 --workers $NUM_WORKERS \
 --user $USER \
 --bind=unix:$SOCKFILE \
 --timeout $TIMEOUT

I get a gunicorn error message:

./gunicorn.sh 
Starting djangoapp as root
[2018-12-22 00:01:07 -0200] [17316] [INFO] Starting gunicorn 19.7.1
[2018-12-22 00:01:07 -0200] [17316] [INFO] Listening at: unix:/var/www/djangoapp/run/gunicorn.sock (17316)
[2018-12-22 00:01:07 -0200] [17316] [INFO] Using worker: sync
[2018-12-22 00:01:07 -0200] [17323] [INFO] Booting worker with pid: 17323
[2018-12-22 00:01:07 -0200] [17323] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/workers/base.py", line 126, in init_process
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/app/base.py", line 67, in wsgi
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
  File "/home/nlt-adm/miniconda3/envs/ws/lib/python3.4/site-packages/gunicorn/util.py", line 352, in import_app
  File "/var/www/djangoapp/app/wsgi.py", line 12, in <module>
    from django.core.wsgi import get_wsgi_application
ImportError: No module named 'django'
[2018-12-22 00:01:07 -0200] [17323] [INFO] Worker exiting (pid: 17323)
[2018-12-22 00:01:07 -0200] [17316] [INFO] Shutting down: Master
[2018-12-22 00:01:07 -0200] [17316] [INFO] Reason: Worker failed to boot.

EDIT: In tests using gunicorn without the script, it works!...

gunicorn --bind 0.0.0.0:8000 djangoapp.wsgi:application
[2018-12-22 01:47:50 -0200] [17869] [INFO] Starting gunicorn 19.7.1
[2018-12-22 01:47:50 -0200] [17869] [INFO] Listening at: http://0.0.0.0:8000 (17869)
[2018-12-22 01:47:50 -0200] [17869] [INFO] Using worker: sync
[2018-12-22 01:47:50 -0200] [17872] [INFO] Booting worker with pid: 17872
^C[2018-12-22 01:48:15 -0200] [17869] [INFO] Handling signal: int
[2018-12-21 21:48:15 -0600] [17872] [INFO] Worker exiting (pid: 17872)
[2018-12-22 01:48:15 -0200] [17869] [INFO] Shutting down: Master

How can I solve this problem?

  • This SO question may be helpful: stackoverflow.com/q/9462212/6216002 – Haxiel Dec 23 '18 at 5:17
  • Thanks Haxiel, but even adding the track through sys.path.append it still keeps bringing the same error. – vic.py Dec 23 '18 at 13:22
  • I am assuming that line 16 in your script activates a Python virtualenv. Does your virtualenv in $DJANGODIR have django installed? I cannot tell if you are using the same virtualenv for your gunicorn test without the script. – GracefulRestart Dec 23 '18 at 21:57
0

I figured out how to solve the problem, at first it was in the bash execution script of gunicorn. The solution found was the removal of the parameter $ USER, since it was not allowed to execute the env of the miniconda.

The code to be changed is the one in the gunicorn part:

exec gunicorn ${DJANGO_WSGI_MODULE}:application \
 --name $NAME \
 #--user $USER
 --workers $NUM_WORKERS \
 --bind $PORT \
 --bind=unix:$SOCKFILE \
 --timeout $TIMEOUT
 --access-logfile - $LOGDIR \
 --access-logformat '"%(r)s" %(s)s %(b)s'

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.