Why is my script to start UWSGI not functioning at bootup?

Question

I wonder if you can help.

I am running the following versions:

OS: SMP Debian 3.2.81-1 x86_64
uWSGI: uWSGI 2.0.11.2

I installed uWSGI manually, as I want to use a specific version. Using the following commands: -

apt-get install build-essential psmisc python-dev libxml2 libxml2-dev python-setuptools
cd /opt/
wget http://projects.unbit.it/downloads/uwsgi-2.0.11.2.tar.gz
tar -zxvf uwsgi-2.0.11.2.tar.gz
mv uwsgi-2.0.11.2/ uwsgi/
cd uwsgi/
python setup.py install

I am trying to replicate the setup on another server that the project is already working on in a live environment (I am essentially setting up a test server environment).

The original server has uWSGI running on boot. To figure out how this is happening, I used

htops 

I've been able to identify that uWSGI is running on the existing server with a set of command line switches. I've managed to track down the script that initialises uWSGI with these switches in the init.d folder.

I copied this script to my test server, and ran it using

service script.sh start

After various troubleshooting, mainly involving permissions on socket folders etc, now when I run this script it starts, and if I run htop I can see uWSGI is running and it has the exact same command switches I need.

I thought simply putting the script in init.d and giving it execute permission

chmod +x script.sh

Would be enough so that it starts when the server is switched on... but this appears to not be the case. Because when I issue

reboot

At the terminal, the terminal reboots but when I go into htops, and check for the uWSGI process it is not running.

If however directly after reboot I issue the following command

service script.sh start

The service starts just fine, and I can once again see it in htops.

Research online lead me to the suggestion that I should try to set the script to run automatically using chkconfig. I installed chkconfig using

apt-get chkconfig

and then ran the following command

chkconfig --list

I noticed that all the runtime levels where set to off for the script I am trying to get to execute on boot.

I ran the following command

chkconfig /etc/init.d/script.sh on

And now when I check the script runtime switches with chkconfig, it shows me the following output for my script:

script.sh               0:off  1:off  2:on   3:on   4:on   5:on   6:off

However when I reboot the uWSGI process is still not starting.

Yet if I simply type

service script.sh start 

At the terminal the service runs ok, and uWSGI runs fine.

How can I set the script to run when the server restarts?

---

Edit:

Further research on the live server that is working fine, has determined that it does not appear to be using systemd to launch uWSGI on startup. I logged into the live server and while there is a

/etc/systemd 

folder, it has just one folder in it system and no files. The system folder has the following files in it:

multi-user.target.wants  sockets.target.wants  syslog.service

So there does not appear to be anything uWSGI related in here.

Also what is making me think this is likely something to do with the

/etc/init.d 

folder, is that when I run htop and examine the running services (or daemons) not quite sure of the correct terminology in linux. uWSGI is showing in here as running with a signature of command line switches, and the script I have found in /etc/init.d has this exact uWSGI command and same signature of switches, so I'm fairly convinced this is the part of the system that is starting the uWSGI daemon , I just can't figure out what I need to do , to get it to run apart from copying the same file to /etc/init.d on the new server and giving it execute permission.

The OS of the live server is :

SMP Debian 3.2.73-2+deb7u1 x86_64

and the OS I am running on the new server is

SMP Debian 3.2.81-1 x86_64

So they seem fairly similiar? Although I'm not sure how significant the 8 incremements in the least significant digits in the version number is.

On the new server there is no /etc/systemd folder , and on the live server there is a /etc/systemd as explained above. So it does appear to have been installed seperately to the main OS install (as I have a later version of Debian and it wasn't installed on my system by default) - so perhaps there is something related to systemd that is causing the script to start on the live server, but I'm not too sure.

Answer 1

Jessie

In the recent Debian (Jessie) the initv scripts do not work the way they did. And given your kernel version you are not running a Debian that uses initv scripts. The current Debian uses systemd and scripts in /etc/rc.d are run by compatibility features of systemd (the service command is now a systemd command that tries to behave like the old initv command).

You have two options:

• Add a line calling the script from /etc/rc.local:

  /etc/rc.d/script.sh
  

  This is a rather dirty fix, since it depends on another compatibility feature of systemd. Also, the location of the script does not matter anymore.

• Write a full systemd service for uwsgi (this is what I do, and what is recommended by the uwsgi documentation). You would need to create a file called /etc/systemd/system/uwsgi.service with a content similar to:

  [Unit]
  Description=uwsgi emperor
  After=rsyslog.service
  
  [Service]
  PIDFile=/run/uwsgi-emperor.pid
  ExecStart=/bin/uwsgi --ini /etc/uwsgi/emperor.ini
  ExecReload=/bin/uwsgi --reload /run/uwsgi-emperor.pid
  ExecStop=/bin/uwsgi --stop /run/uwsgi-emperor.pid
  Restart=always
  KillSignal=SIGQUIT
  Type=notify
  StandardError=syslog
  NotifyAccess=all
  
  [Install]
  WantedBy=multi-user.target
  

  I use the emperor mode (which is also the mode recommended by uwsgi for use with systemd), although it is possible to hack it to run a single process uwsgi (see further reading below).

  You will also need to enable the service to be used by the multi-user.target, which will run at boot. You need to perform this as root:

  systemctl enable uwsgi.service
  

  And uwsgi will start with the next boot (it will not start straight away, to make it start you need systemctl start uwsgi.service).

Further reading:

• The Arch linux wiki about systemd is very thorough
• The Debian wiki on systemd is good, but outdated in some places (notably, it tells you that you need to install it which is not the case in Jessie)

---

Weezy

You're mixing things up a little there: chkconfig is a script of the RedHat family of OSes. Making it work for Debian was not easy in the past, and I do not believe it is easy to do so now.

Weezy still uses the initv rc.d folders alright, for each runlevel one rc.d folder:

/etc/rc.d/rc0.d/
/etc/rc.d/rc1.d/
/etc/rc.d/rc2.d/
/etc/rc.d/rc3.d/
/etc/rc.d/rc4.d/
/etc/rc.d/rc5.d/
/etc/rc.d/rc6.d/

You can check the runlevel you are in with the (appropriately named) runlevel command. Then you need to check whether there is a softlink to the script in the correct /etc/rc.d/rc*.d folder. If there is no softlink to the script you need to add it with something of the lines:

ln -s /etc/rc.d/init.d/script.dh /etc/rc.d/rc$(runlevel | cut -d ' ' -f 2).d/script.sh

And that is almost all about how initv scripts work. If you are going into runlevel 2 when the machine boots (I believe that's the default on Debian), what init performs is simply service <script> start for every file in /etc/rc.d/rc2.d.