Hang on SIGTERM with ruby 2.6 in clustered mode

[vbalazs]

Steps to reproduce

1. Create a config.rb file with this content and run mkdir -p tmp/pids

# frozen_string_literal: true

app_dir = File.expand_path(__dir__)

workers 4
threads 1, 8

bind "tcp://0.0.0.0:#{ENV.fetch('PORT', 3000)}"

pidfile "#{app_dir}/tmp/pids/puma.pid"
state_path "#{app_dir}/tmp/pids/puma.state"

app do |env|
  puts env
  body = 'Hello, World!'

  [200, { 'Content-Type' => 'text/plain', 'Content-Length' => body.length.to_s }, [body]]
end

2. puma -C config.rb
3. Send a TERM signal to the cluster process

$ /bin/kill -TERM `cat tmp/pids/puma.pid`

Expected behavior

Gracefully shuts down workers

Actual behavior

Process hangs, requires KILL

System configuration

Ruby version: 2.6.2
Puma version: 3.12.1
Platform: Ubuntu 18.04 (4.15.0-1032-aws)

Additional info

It works with Ruby 2.5.5.

I discovered this using puma with systemd, it times out and kills the process after a certain time. I checked the signals docs, with INT is really working but from the documentation is not clear if I can just use this signal instead without any other side effect.

if in systemd service descriptor I set ExecStop=/bin/kill -INT $MAINPID , it seems to work but it throws this error like it tries to stop the server twice:

api-puma[28423]: [28423] - Gracefully shutting down workers...
api-puma[28423]: [28423] - Gracefully shutting down workers...
api-puma[28423]: /opt/myapp/shared/vendor/ruby/2.6.0/gems/puma-3.12.1/lib/puma/cluster.rb:40:in `waitpid': No child processes (Errno::ECHILD)

[calmyournerves]

This is probably the same issue described in #1674 and #1730.

[Aesthetikx]

As additional anecdotal evidence, with puma 3.12.0 and ruby 2.6.2 in clustered mode on heroku, a SignalException: SIGTERM will be raised a few minutes after every deploy, which does not happen on 2.5.3.

[dentarg]

Yep, I can confirm what @Aesthetikx says. #1674 (comment)

[Aesthetikx]

Another anecdote, b94c3e3 (not yet released) fixes the issues we experienced on heroku.

[dentarg]

@nateberkopec this one can be closed as the workaround (#1741) has been released with Puma 4.0.0