Cannot run Puma upstart script on Ubuntu 16.04

Question

I'm trying to start my Ruby on Rails applications manually, but am running into an issue.

When running 'sudo start puma-manager' or 'sudo start puma app=/home//' I'm getting the following error: 'Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused'.

I'm going through this tutorial: https://www.digitalocean.com/community/tutorials/how-to-deploy-a-rails-app-with-puma-and-nginx-on-ubuntu-14-04, on Ubuntu 16.04 (no other surprises, other than using 16.04 I've followed this tutorial to the last detail). Is there a good way to get upstart to work?

I just read that upstart isn't available on 16.04. Is that true? I find it hard to believe that puma doesn't have a good workaround for this. It seems too common.

Thanks for your help!

Answer 1

I had the same problem and for a while this was a reason for me to not upgrade to Ubuntu 16, but we have to keep moving on with this changes. Systemd can be scary, but once you start having experience setting up service scripts it can be easier than Upstart.

1. Create a file named puma.service in /etc/systemd/system/ similar to this one:

   [Unit]
   Description=Puma HTTP Server
   After=network.target
   [Service]
   Type=simple
   # Preferably configure a non-privileged user
   User=appuser
   
   # Specify the path to your puma application root
   WorkingDirectory=/home/deploy/appname
   
   # Helpful for debugging socket activation, etc.
   Environment=PUMA_DEBUG=1
   # Setting secret_key_base for rails production environment. We can set other Environment variables the same way, for example PRODUCTION_DATABASE_PASSWORD
   Environment=SECRET_KEY_BASE=b7fbccc14d4018631dd739e8777a3bef95ee8b3c9d8d51f14f1e63e613b17b92d2f4e726ccbd0d388555991c9e90d3924b8aa0f89e43eff800774ba29
   
   # The command to start Puma, use 'which puma' to get puma's bin path, specify your config/puma.rb file
   ExecStart=/usr/local/bin/puma -C /home/deploy/appname/config/puma.rb
   Restart=always
   [Install]
   WantedBy=multi-user.target
   

2. Run these commands to bring the systemd service up.

   systemctl daemon-reload
   systemctl enable puma.service
   systemctl start puma.service
   

Your service will be up if you have done right the other steps of this guide: https://www.digitalocean.com/community/tutorials/how-to-deploy-a-rails-app-with-puma-and-nginx-on-ubuntu-14-04

Remember you can check the status of the services with these commands:

systemctl status puma.service
systemctl status nginx

And you can debug using 'tail -f' with these log files:

/home/deploy/appname/shared/log/puma.stderr.log
/home/deploy/appname/log/production.log
/var/log/nginx/error.log

Answer 2

That is correct. You should use SystemD in Ubuntu 16.04 LTS. Here is the relevant Puma documentation and the provided sample service unit file:

[Unit]
Description=Puma HTTP Server
After=network.target

# Uncomment for socket activation (see below)
# Requires=puma.socket

[Service]
# Foreground process (do not use --daemon in ExecStart or config.rb)
Type=simple

# Preferably configure a non-privileged user
# User=

# Specify the path to your puma application root
# WorkingDirectory=

# Helpful for debugging socket activation, etc.
# Environment=PUMA_DEBUG=1

# The command to start Puma
# Here we are using a binstub generated via:
# `bundle binstubs puma --path ./sbin`
# in the WorkingDirectory (replace <WD> below)
# You can alternatively use `bundle exec --keep-file-descriptors puma`
# ExecStart=<WD>/sbin/puma -b tcp://0.0.0.0:9292 -b ssl://0.0.0.0:9293?key=key.pem&cert=cert.pem

# Alternatively with a config file (in WorkingDirectory) and
# comparable `bind` directives
# ExecStart=<WD>/sbin/puma -C config.rb

Restart=always

[Install]
WantedBy=multi-user.target

Answer 3

This Problem occurs if you are running your production server on Ubuntu 15.04 or higher (eg. 16.04) as mentioned here.

The following commands worked for me-

$ sudo apt-get install upstart-sysv
$ sudo update-initramfs -u
$ reboot

Don't forget to reboot, otherwise, commands won't take affect.