1

First things first, I would like to clarify that I am completely knew to debugging servers and deploying in general. I'm a student developer for my university and so far all of my work has been programming related, but I have been given the deployment responsibilities for my team.

I'm trying to deploy our Django applications using gunicorn and wsgi. My previous boss (who no longer works with us), wrote this init script which should start the wsgi server:

#! /bin/sh
# Do NOT "set -e"


# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
PIDFILE=/tmp/site.edu.pid
PROJECT_DIR=/opt/project_name
PROC_NAME="project_name"
NAME=$PROC_NAME
VENV=/opt/envs/project_name
SOCK=/tmp/site.edu.sock
CMD="gunicorn project_name.wsgi:application --pid $PIDFILE --bind unix:$SOCK --workers 9 --name $PROC_NAME --preload --daemon --timeout 300 --error-logfile '-' --log-file '-'"
USER="www-data"

. $VENV/bin/activate;

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    if [ -e $PIDFILE ]; then
      return 1
    fi
    cd $PROJECT_DIR
    . $VENV/bin/activate
    $CMD
    if [ $? = 0 ]; then
      return 0
    else
      return 2
    fi

    sleep 1;
    chown $USER:nogroup $SOCK;
    chmod 660 $SOCK;

}

From my understanding, this should run gunicorn and create a unix socket and pidfile in the /tmp directory, and start the server running, however this doesn't seem to be the case, as these files are not present in the /tmp directory (causing a 502 bad gateway in our nginx config).

I should also note that this works in a Python 2 virtual environment (as they all used to be deployed using python 2), but not a python 3 virtual environment (on the server), but it does work locally in a python3 virtual environment.

Furthermore, I do have one site running successfully using Python 3 and this config, but I can't seem to figure out why the other ones will not (as their virtual environments all have identical requirements and versions of gunicorn gunicorn==20.0.4)

As aforementioned, I have very limited server knowledge, and I am trying to learn the best I can. If anybody could provide any debugging tips.

Here is the output when I run systemctl status working-site.edu.service

working-site.edu.service - LSB: working_project initscript
   Loaded: loaded (/etc/init.d/working-site.edu.sh; generated)
   Active: active (running) since Tue 2020-07-14 17:04:44 EDT; 1 day 19h ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 10 (limit: 4638)
   CGroup: /system.slice/working-site.edu.service
           ├─27489 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27493 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27494 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27495 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27496 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27497 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27498 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27499 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           ├─27500 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid
           └─27501 /opt/envs/working_project/bin/python3.6 /opt/envs/working_project/bin/gunicorn working_project.wsgi:application --pid

Jul 14 17:04:44 staging-server systemd[1]: Starting LSB: working_project initscript...
Jul 14 17:04:44 staging-server systemd[1]: Started LSB: working_project initscript.

Vs when I run systemctl status broken-site.edu.service

broken-site.edu.service - LSB: broken_project initscript
   Loaded: loaded (/etc/init.d/broken-site.edu.sh; generated)
   Active: active (exited) since Thu 2020-07-16 12:51:26 EDT; 15min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 32425 ExecStart=/etc/init.d/broken-site.edu.sh start (code=exited, status=0/SUCCESS)

Jul 16 12:51:26 staging-server systemd[1]: Starting LSB: broken_project initscript...
Jul 16 12:51:26 staging-server systemd[1]: Started LSB: broken_project initscript.

I would appreciate any and all debugging tips on this one. I'm trying to learn server configurations the best I can, but I've been thrown into the deep end on this one, trying to piece things together as I go.

Thanks!

JohnnyLeek
  • 11
  • 2
  • Throw that ancient script away and use proper systemd units. A [sample](https://docs.gunicorn.org/en/stable/deploy.html#systemd) is available in the documentation. – Michael Hampton Jul 16 '20 at 18:14
  • @MichaelHampton I will get on that, but realistically, is that going to change my output? My main question is why running the same command (but with different names) is causing it to break? – JohnnyLeek Jul 16 '20 at 18:23
  • I wouldn't even bother. Starting services with that style of script is obsolete; it's just not the done thing anymore. – Michael Hampton Jul 16 '20 at 18:27

0 Answers0