22

Puma times out my request when I'm using binding.pry. In my controller

def new
  require 'pry'
  binding.pry
end

I then make a request that hits the controller and enter the pry session. After 60 seconds Puma? times out my request, restarts a worker and subsequently blows up by debugging session.

[1] pry(#<Agent::ClientsController>)> [3522] ! Terminating timed out worker: 3566
[3522] - Worker 0 (pid: 4171) booted, phase: 0

I generated this app with suspenders if that matters. How do I extend my debugging session in rails 5?

thedanotto
  • 6,895
  • 5
  • 45
  • 43

2 Answers2

32

How about this?

# config/puma.rb    
...

environment ENV['RACK_ENV'] || 'development'

...

if ENV['RACK_ENV'] == 'development'
  worker_timeout 3600
end

Edit (Rails 5.1.5):

Because ENV['RACK_ENV'] was empty, I did the following:

# config/puma.rb 

...

if ENV.fetch('RAILS_ENV') == 'development'
   puts "LOGGER: development => worker_timeout 3600"
   worker_timeout 3600
end
Pascal
  • 1,158
  • 17
  • 20
8

You can create a configuration file and set the timeout value in there (for all requests, not just ones involved in debugging). I'd recommend making a dev-specific one, and referencing that when running the server locally (and not setting some big timeout value for production).

In your rails application, create a file like /config/dev_puma_config.rb and in it put:

#!/usr/bin/env puma

worker_timeout 3600

Then when you start your server, reference that file with a -C like this:

bundle exec puma -t 1:1 -w 1 -p 3000 -e development -C config/dev_puma_config.rb

As a bit of background info on that worker_timeout setting, here's what the puma config says about it:

Verifies that all workers have checked in to the master process within the given timeout. If not the worker process will be restarted. This is not a request timeout, it is to protect against a hung or dead process. Setting this value will not protect against slow requests. Default value is 60 seconds.

user605331
  • 3,718
  • 4
  • 33
  • 60