You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
One of the things that made #2371 hard to debug was that Puma's behavior comes from a mix of defaults, config file defined settings, and config flags. It can be tricky to see what the user's settings "really" are for debugging purposes.
Describe the solution you'd like
I'm proposing we add a puma config command that would:
Boot puma, including loading the config/puma.rb file
Output config
Exit
Describe alternatives you've considered
Alternatively, we could add some env var like PUMA_DEBUG_CONFIG that could output puma configuration in the boot process.
Additional context
One area to be concerned with is that running puma via rails s provides more config as rails has their own default values that they pass in. To get a "true" representation of the actual config, it might be more accurate to go with the alternative method of outputting config in the web bootup process directly. Maybe both options would be helpful.
The text was updated successfully, but these errors were encountered:
I like the alternative idea more, as you might already have Puma running when you want to get the config (there would be port collision when running puma config if it tries to boot your app)
I think it would be useful to be able to see the config not only when booting. Could we do a pumactl command for this? Like thread-backtraces (#2054)? Might not be as convenient as running just puma config though. But it could coexist with the debug ENV I assume.
I was thinking that it would stop slightly short of actually booting the app. A pumactl option is interesting. I think we would need to hijack a signal to make it work like SIGUSR we could just tack it on to thread-backtraces.
On heroku it's harder to use pumactl (unless via ps:exec) and most debugging happens in a 1 off heroku run bash dyno. So, having thought about it: I like the idea of outputting config on boot optionally via env var
Is your feature request related to a problem? Please describe.
One of the things that made #2371 hard to debug was that Puma's behavior comes from a mix of defaults, config file defined settings, and config flags. It can be tricky to see what the user's settings "really" are for debugging purposes.
Describe the solution you'd like
I'm proposing we add a
puma config
command that would:Describe alternatives you've considered
Alternatively, we could add some env var like
PUMA_DEBUG_CONFIG
that could output puma configuration in the boot process.Additional context
One area to be concerned with is that running puma via
rails s
provides more config as rails has their own default values that they pass in. To get a "true" representation of the actual config, it might be more accurate to go with the alternative method of outputting config in the web bootup process directly. Maybe both options would be helpful.The text was updated successfully, but these errors were encountered: