11

I upgraded to Puma 5.0.2 and started my rails app as usual with:

bundle exec puma -d -e production -b unix:///home/user/app/tmp/puma.sock

Now I get the error:

OptionParser::AmbiguousOption: ambiguous option: -d

What is the proper way to run puma as a daemon?

Jun Dalisay
  • 1,165
  • 2
  • 12
  • 26

2 Answers2

7

Context: Quick links:

Daemonize option has been removed without replacement as of Puma 5.0.0 (Source: https://github.com/puma/puma/blob/master/History.md)

You may refer this section for daemonization in their documentation: https://github.com/puma/puma/blob/master/docs/deployment.md#should-i-daemonize

Solution: Create a systemd service for puma depending on your OS distro.

Configure your environment in config/puma in your app directory.

Add a service file named puma.service in /etc/systemd/system (the path works for me on SLES15).

Here is a sample that works for me (replace text within <> as per your needs):

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

[Service]
Type=simple
User=<UserForPuma>
WorkingDirectory=<YourAppDir>
Environment=RAILS_MASTER_KEY=<EncryptionKeyIfUsedByRailsApp>
ExecStart=/usr/bin/rails s puma -b 'ssl://127.0.0.1:3000?key=<path_to_privatekey.key>&cert=<path_to_certificate.crt>' -e production
Restart=always
RestartSec=2
KillMode=process

[Install]
WantedBy=multi-user.target

Save the above content as a file named puma.service in the directory path mentioned above. After this just enable and start the service:

# systemctl daemon-reload
# systemctl --now enable puma.service

Created symlink /etc/systemd/system/multi-user.target.wants/puma.service → /etc/systemd/system/puma.service.

# systemctl status puma

● puma.service - Puma HTTP Server
   Loaded: loaded (/etc/systemd/system/puma.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-10-09 12:59:28 CEST; 7s ago
 Main PID: 2854 (ruby.ruby2.5)
    Tasks: 21
   CGroup: /system.slice/puma.service
           ├─2854 puma 5.0.2 (ssl://127.0.0.1:3000?key=<your_key_path.key>&cert=<your_cert_path.crt>) [rails-app-dir]
           ├─2865 puma: cluster worker 0: 2854 [rails-app-dir]
           └─2871 puma: cluster worker 1: 2854 [rails-app-dir]

Check puma status: ps -ef | grep puma

This should now show running puma processes (main process and worker processes).

Here is a link for beginners on how to create a systemd service: https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6

Systemd docs:

Sorry but I am not a Windows person, but I believe that the idea is same. Anyone working in Windows may try creating a bat file and running it in the background as a Windows service. Hope that helps.

Zeeshan
  • 493
  • 2
  • 11
  • 25
  • 2
    On POSIX systems (Unix / Linux / macOS), it might be easier to demonize Puma using the OS's `&` option. i.e., `bundle exec puma -e production &`... I believe this is why the `-d` was deprecated, it's simply redundant. – Myst Oct 09 '20 at 21:35
  • I couldn't get it to work. Probably something wrong with my ExecStart. Anyway, I downgraded one puma in one instance to keep old daemon, and kept an upgraded one in another instance where I just open a new terminal and close the running one (I use Rails on Rbenv on Ubuntu on Google Cloud Platform) – Jun Dalisay Oct 09 '20 at 22:01
  • @JunDalisay Do you see any specific errors in `journalctl -xe`? Please check if you are using absolute path to the puma binary. If the service somehow got running (`ps -ef| grep puma` shows running process but the application doesn't actually work), you will see specific Puma related errors in your puma.stderr.log as well (in app_dir/log path). Not sure at which level are you getting the issue. – Zeeshan Oct 11 '20 at 04:47
0

This gem on Github looks like a good source to start from:

https://github.com/kigster/puma-daemon
valk
  • 9,363
  • 12
  • 59
  • 79