Issues with config file and booting on 4.1.0

[sudara]

Steps to reproduce

Maybe related to #1905 / #1837. I'm reporting in case it helps. Feel free to close if it's a dupe.

I upgraded an app to 4.1.0 today and saw some strange behavior. On this app, puma.rb has a conditional where it does particular things in production.

#!/usr/bin/env puma
env = ENV.fetch("RAILS_ENV") { "production" }
environment env
if env == "production"
  workers 3
  daemonize true
  bind 'unix://tmp/puma.sock'
  state_path 'tmp/puma.state'
  stdout_redirect 'log/puma.log', 'log/puma.log', true
end

threads 1,4
prune_bundler
pidfile 'tmp/puma.pid'

# Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart

On 4.1.0 it almost appears as if the env == "production" isn't evaluating as true, as we only get one worker.

Expected behavior

On 4.0.x, 3 workers boot, cluster stays up.

web    9494  0.0  0.1 187996 20000 ?        Sl   13:59   0:00   puma 4.0.1 (unix://tmp/puma.sock) [alonetone]
web    9496  4.4  1.1 1366304 186412 ?      Sl   13:59   0:08     puma: cluster worker 0: 9494 [alonetone]
web    9498  4.1  1.0 1364080 177312 ?      Sl   13:59   0:07     puma: cluster worker 1: 9494 [alonetone]
web    9500  4.5  1.1 1430668 183676 ?      Sl   13:59   0:08     puma: cluster worker 2: 9494 [alonetone]

Actual behavior

On 4.1.0, only 1 worker boots, it seems to serve a couple requests and then die intermittently.

web   16376  0.5  1.2 1366248 212440 ?      Sl   12:49   0:18   puma: cluster worker 1: 16373 [alonetone]

System configuration

Ruby 2.6.2
Rails 6.0
Puma 4.1.0

[nateberkopec]

👋 hey @sudara. Does this repro with the hello-world rackup app here? https://github.com/puma/puma/blob/master/test/rackup/hello.ru

If not, does it repro with a blank rails new app?

[sudara]

Howdy!

This happened in production on ubuntu. I should mention I bumped Rails 6.0.beta2 to 6.0 final and Puma from 4.0.1 to 4.1.0 simultaneously.

I tried to reproduce locally with hello.ru and the same-ish config — everything is happy, could not reproduce.

With a fresh Rails 6.0.0 app locally on macos on both versions 4.0.1 and 4.1.0 I was getting strange things happening using multiple daemonized workers and the stdout_redirect line from my config.

How strange? My fans start pumping hard (ruby cpu % is nice and low, however) and when I try to open a terminal window, instead of my prompt I got this error:

[forkpty: Resource temporarily unavailable]
[Could not create a new process and open a pseudo-tty.]

It turns out there was a bundler issue that had the workers running in a very frenzied multi-core-eating restart loop:

/Users/sudara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/bundler-2.0.2/lib/bundler/lockfile_parser.rb:108:in warn_for_outdated_bundler_version': You must use Bundler 2 or greater with this lockfile. (Bundler::LockfileError)

ANYWAY....after resolving, the only difference I can see is 4.0.1 doesn't output anything after "Daemonizing..."

➜  rails600 git:(master) ✗ bundle exec puma -C config/puma.rb
* Pruning Bundler environment
[78225] Puma starting in cluster mode...
[78225] * Version 4.0.1 (ruby 2.6.1-p33), codename: 4 Fast 4 Furious
[78225] * Min threads: 1, max threads: 4
[78225] * Environment: development
[78225] * Process workers: 3
[78225] * Phased restart available
[78225] * Listening on tcp://0.0.0.0:3001
[78225] * Daemonizing...

Whereas 4.1.0 outputs some extra stuff into my prompt afterwards.

➜  rails600 git:(master) ✗ bundle exec puma -C config/puma.rb
[78755] * Pruning Bundler environment
[78755] Puma starting in cluster mode...
[78755] * Version 4.1.0 (ruby 2.6.1-p33), codename: Fourth and One
[78755] * Min threads: 1, max threads: 4
[78755] * Environment: development
[78755] * Process workers: 3
[78755] * Phased restart available
[78755] * Listening on tcp://0.0.0.0:3001
[78755] * Daemonizing...
➜  rails600 git:(master) ✗ [78793] + Gemfile in context: /Users/sudara/Sites/rails600/Gemfile
[78794] + Gemfile in context: /Users/sudara/Sites/rails600/Gemfile
[78795] + Gemfile in context: /Users/sudara/Sites/rails600/Gemfile
[78783] - Worker 1 (pid: 78794) booted, phase: 0
[78783] - Worker 0 (pid: 78793) booted, phase: 0
[78783] - Worker 2 (pid: 78795) booted, phase: 0

I'll let you know if I dig anything else up.

[nateberkopec]

@sudara The STDOUT change was reverted on master, you can give that a shot and see if anything happens.

[nateberkopec]

Closing, please LMK if 4.1.1 doesn't fix the issue.