Chris LaRose

Hey @wwboynton sorry it took so long to get back to you! I ended up having a busy week. Anyway, I love the enthusiasm and I like the overall idea....

I agree that what @deepakmahakale posted should work. @deepakmahakale if you're able to reproduce the issue on a new rails app, we can take a deeper look into what's going...

I'll take a look. It's an old issue, so this might already be fixed, but we can at least improve our docs with recommendations.

Oh I like the `phased_restart_timeout` config option idea. Then users don't have to do anything special to get the timeout behavior when requesting a phased restart. It'd work for `pumactl...

Thinking about this a little more, a single `phased_restart_timeout` doesn't scale automatically with the number of workers. It'd be nice if users didn't have to adjust `phased_restart_timeout` based on the...

@h0jeZvgoxFepBQ2C That's good feedback to have. It's true that if a worker is failing to boot as part of a phased restart, that a hot restart won't necessarily fix it,...

One option is to use [`puma_worker_killer`](https://github.com/schneems/puma_worker_killer). That periodically kill workers based on time, not on the number of requests, though. `puma_worker_killer` works by starting a new thread in `before_fork`, so...

I'm also open to a new configuration option for Puma that would enable this functionality. Clearly, the hooks are already in place to be able to kill workers after a...

I actually disagree here. `puma_worker_killer` AFAIK pretty blindly just sends `kill` signals to the individual worker processes, without taking into account how many workers are still up and able to...

> I also notice that it takes much longer to quit / exit the server. Like 15 seconds instead of 0.5. That issue is separately documented in #2398 and is...