I have seen too many servers running production applications, where if the server has to be rebooted, someone has to log into it and restart the app. Everyone knows of these magical arcane things called 'init scripts' which start various services when a server boots up, but for some reason they are often not used by developers - perhaps due to fear of complexity. While they were fairly complex a while back, things have gotten much easier with the advent of newer technologies on the scene.
Although it could get very complex in the past to write these, it is not actually that complex these days, as we have modern 'init daemons' to help us. An 'init daemon' is what controls how the system starts up and shuts down, and init scripts are the scripts we write to tell it how to start up or shut down our apps.
Systemd (Almost Every Current Linux Distribution)
Update: Amazon Linux 2 now supports Systemd as well
'Systemd' is an init daemon that has slowly replaced other init systems. It is more than an init daemon actually - but let's ignore that for now, as we do not want to get into a flame war (https://en.wikipedia.org/wiki/Systemd).
Here is a sample script that starts a Rails app called 'app' from the directory '/srv/app'. It starts it as the 'appuser' user, sets some environment variables, tells it to handle up to 4 requests concurrently, and does some cool restart-if-abnormally-terminated magic. Note: the puma web server is NOT told to start in the background with the '--daemon' flag - Systemd will take care of that.
# /etc/systemd/system/app.service [Unit] Description=App # Run after these After=syslog.target After=network.target [Service] Type=simple User=appuser Group=appuser WorkingDirectory=/srv/app Environment="RAILS_ENV=production" "SECRET_KEY_BASE=foobar" # Always restart on abnormal termination Restart=always # Note that first argument must be an absolute path, rest are arguments to it ExecStart=/srv/app/bin/bundle exec puma -w4 -e production --preload -b tcp://localhost:3000/ # Startup/shutdown grace period TimeoutSec=60 [Install] # Run before this WantedBy=multi-user.target
The app can be controlled with:
sudo systemctl start/stop/restart/status app
The status sub-command is particularly cool, showing the app's status, standard output and process tree. Passing it the '-l' flag adds even more information to the output.
However, to actually make it start on boot, you need to 'enable' the service with:
sudo systemctl enable app
Upstart (Older Ubuntus, Amazon Linux, Old Red Hat Enterprise Linux)
'Upstart' is an init daemon written and popularized by Ubuntu. Newer Ubuntu versions have replaced it with Systemd, but for compatibility's sake, let you use Upstart scripts anyway.
Like above, here is a sample script that starts a Rails app called 'app' from the directory '/srv/app'. It starts it as the 'appuser' user, sets some environment variables, tells it to handle up to 4 requests concurrently, and does cool restart-if-abnormally-terminated magic. Note: the puma web server is NOT told to start in the background with the '--daemon' flag - Upstart will take care of that.
# /etc/init/app.conf description "My App Server" start on runlevel  stop on runlevel  setuid appuser chdir /srv/app # restarts service if it abnormally terminates... respawn # ...but quit trying if it fails 5 times in 60 seconds respawn limit 5 60 env RAILS_ENV=production env SECRET_KEY_BASE=foobar exec bin/bundle exec puma -w4 -e production --preload -b tcp://localhost:3000/
The app can be controlled with:
sudo service app start/stop/restart/status
Annoyingly, Amazon Linux, as used on AWS, wishes to stay compatible with the ancient Red Hat Linux 6, and has an ancient version of Upstart that does not support the 'setuid' stanza. Thus we are forced to use 'su' to do the user changing for us, like so:
#/etc/init/app.conf description "My App Server" start on runlevel  stop on runlevel  respawn respawn limit 5 60 env RAILS_ENV=production env SECRET_KEY_BASE=foobar exec su -s /bin/bash -c 'cd /srv/app && bin/bundle exec puma -w4 -e production --preload -b tcp://localhost:3000/' appuser
In this case, the app is controlled with:
sudo initctl start/stop/restart/status app
Find out more about Upstart at http://upstart.ubuntu.com/cookbook/
A Note on Restarting Apps on Deployment
Since these are system services, and you are not doing a deploy as root (I hope!), issuing a restart during a deploy will require you to use 'sudo'. You could always just give the user complete sudo access (as is the default if you are using EC2 instances, and using the default user), or you could limit the user to only being able to run certain commands as root using sudo - this is the topic for another blog post.
There you have it. It really is simple, once you know how, to create an init script for whatever flavour of Linux you are running on. No more having to log into the server to restart the application just because writing init scripts is too much hassle.