Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature idea: puma config command #2414

Closed
schneems opened this issue Oct 6, 2020 · 3 comments · Fixed by #2472
Closed

Feature idea: puma config command #2414

schneems opened this issue Oct 6, 2020 · 3 comments · Fixed by #2472

Comments

@schneems
Copy link
Contributor

schneems commented Oct 6, 2020

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:

  1. Boot puma, including loading the config/puma.rb file
  2. Output config
  3. 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.

@dentarg
Copy link
Member

dentarg commented Oct 6, 2020

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.

@schneems
Copy link
Contributor Author

schneems commented Oct 6, 2020

if it tries to boot your app)

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

@nateberkopec
Copy link
Member

outputting config on boot optionally via env var

Me too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants