Puma fails when it restarts itself

Rails
1

I’m having an issue with Puma, it fails when it tries to restart itself.
When this happens it kills all the Puma processes, resulting in nginx
delivering a 502 Bad Gateway to our users. I’m able to start, stop &
restart it with my /etc/init.d/puma script (it runs
/usr/local/bin/run-puma), it just has issues when it restarts itself.
The
puma.log file doesn’t show anything just useful for troubleshooting,
just

Puma starting in single mode…

  • Version 2.5.1, codename: Astronaut Shoelaces
  • Min threads: 16, max threads: 32
  • Environment: production
  • Listening on unix:///home/deploy/app/shared/sockets/puma.sock

and my workers. Any help would be greatly appreciated.

Also - i have whats probably a pretty dumb question. Is there a way for
me
to allocate more resources to Puma so it doesn’t need to restart itself
so
frequently? I’m currently only using around 25% of the server’s memory.

Thanks for the help

2

On Thu, Aug 29, 2013 at 2:51 PM, Rob D. [email protected]
wrote:

I’m having an issue with Puma, it fails when it tries to restart itself.
When this happens it kills all the Puma processes, resulting in nginx
delivering a 502 Bad Gateway to our users. I’m able to start, stop & restart
it with my /etc/init.d/puma script (it runs /usr/local/bin/run-puma), it
just has issues when it restarts itself.

So, “restarts itself”? Do you have any idea why? I’ve never seen any
of my own Puma instances spontaneously restart.

Have you looked in the system logs for anything relevant? Is there
a mismatch between you-the-user-manually-starting-it and the user
that the process is normally running as/restarting as?

What Ruby are you running?

–
Hassan S. ------------------------ [email protected]

twitter: @hassan

3

FIXED
I had the restart_command in puma.rb trying to run ‘puma.sock restart’,
I
pointed it to my init.d file and it no longer has an issue when it boots
workers

restart_command ‘/etc/init.d/puma restart’

I still occasionally get a 504 timeout under very heavy load, but i have
the god gem monitoring too and it recovers from that quickly