seuros / capistrano-puma

Puma integration for Capistrano
https://github.com/seuros/capistrano-puma
MIT License
615 stars 299 forks source link

restart fails on deploying to ubuntu #321

Closed salex closed 3 years ago

salex commented 3 years ago

I've upgraded three applications to Rails 6.1.3 from 6.0.3 last week. That was a pain (missing things like you have to upgrade webpacker, etc) but I got it working and deployed all three to my staging server, using the systemd commands

Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

I then tried to upgrade to my production server (digital oceans)

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:    18.04
Codename:   bionic

Everything went fine until it tried to restart puma and end with:

 DEBUG [1345b32c] Running [ -d $HOME/.rbenv/versions/2.7.2 ] as rails@1xx.2xx.4.2xx
 DEBUG [1345b32c] Command: [ -d $HOME/.rbenv/versions/2.7.2 ]
 DEBUG [1345b32c] Finished in 1.376 seconds with exit status 0 (successful).
  INFO [c943d2cd] Running /usr/bin/env sudo /bin/systemctl stop puma_rbooks_production as rails@1xx.2xx.4.2xx
 DEBUG [c943d2cd] Command: ( export RBENV_ROOT="$HOME/.rbenv" RBENV_VERSION="2.7.2" ; /usr/bin/env sudo /bin/systemctl stop puma_rbooks_production )
 DEBUG [c943d2cd]   [sudo] password for rails: 

At this time the cap terminal is just sitting on the Ctrl C message. Only way to get out it Ctrl C which response with saying deploy failed. It actually deployed it's just puma was not restarted, I could ssh and use systemctrl to restart it, but not with cap deploy.

If I do sudo systemctl restart puma_rbooks_production I get a response on ubuntu:

sudo systemctl status puma_rbooks_production.service
● puma_rbooks_production.service - Puma for rbooks
   Loaded: loaded (/etc/systemd/system/puma_rbooks_production.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-03-11 21:51:10 CST; 5s ago
 Main PID: 3873 (bundle)
    Tasks: 6 (limit: 2361)
   CGroup: /system.slice/puma_rbooks_production.service
           └─3873 puma 5.2.2 (unix:///home/rails/apps/rbooks/shared/tmp/sockets/puma.sock)

Mar 11 21:51:10 rails systemd[1]: Started Puma for rbooks.
Mar 11 21:51:11 rails puma[3873]: Puma starting in single mode...
Mar 11 21:51:11 rails puma[3873]: * Puma version: 5.2.2 (ruby 2.7.2-p137) ("Fettisdagsbulle")
Mar 11 21:51:11 rails puma[3873]: *  Min threads: 0
Mar 11 21:51:11 rails puma[3873]: *  Max threads: 16
Mar 11 21:51:11 rails puma[3873]: *  Environment: production
Mar 11 21:51:11 rails puma[3873]: *          PID: 3873
Mar 11 21:51:12 rails puma[3873]: * Listening on unix:///home/rails/apps/rbooks/shared/tmp/sockets/puma.sock
Mar 11 21:51:12 rails puma[3873]: Use Ctrl-C to stop

Don't get the extra stuff on debian.

I don't know if the extra stuff is interpreted that the command was not complete or what. Don't remember if I was getting the extra stuff before, but I've been using systemd for a few years and it worked fine on deploy.

UPDATE: I guess Ubundu adds log messages to all systemd commands and Debian does not

I'll add that all three application are set up about the same.

The only difference in the systemd service files is the username

One app RBooks is on GitHub if you want to see the deploy setup.

salex commented 3 years ago

Well it took a few days for it to sink in.

Normal cap deploy does not require sudo. Triggering a restart/reload with systemd does. The staging server had the deploy user in the sudoers , production did not..

Think that needs to be pointing out somewhere in the documentation.