Streamline commandline tools with config

[anon987654321]

Problem

• Commandline tools puma and pumactl are seemingly unnecessary duplicates
• They share similar options but under different names
• Some options available to one are not available to the other
• Makes OS-level daemon management via pumactl difficult without also being dependent upon puma.rb

Solution

All available options in the config file should also be made available to puma and pumactl under the same naming scheme.

pumactl should also be replaced by a wrapper around puma that adds the daemon management options on top of the existing feature set.

Alternatives

Ditching pumactl altogether in favor of puma combined with a kill tool like zap for managing stops and restarts.

Additional context

#2242 #2243 #2244

[nateberkopec]

They share similar options but under different names

This I definitely would be happy to look at individual cases and fix. I agree that the options should be as similar as possible.

pumactl should also be replaced by a wrapper around puma that adds the daemon management options on top of the existing feature set.

This I am not so sure. Pumactl has always been the "remote control" of Puma, and bin/puma has always been the "binary". I don't think they are unnecessary duplicates.

[MSP-Greg]

Don't recall anyone asking for it, but given that MRI Puma requires compiling and also nio4r, Puma::ControlCLI could even be released as a gem...

[dentarg]

@nateberkopec should we close this issue? I think the individual cases you asked for can be new issues. It is not clear to me what needs to be done to close this issue (as stated, there is reasoning behind having two tools (puma and pumactl).

[nateberkopec]

what needs to be done to close this issue

Someone can take a look at puma vs pumactl options and decide if any of them need to be changed so as to align with the other tool.

I'll mark as contrib-wanted.