feat: Support pidfile in CLI & Server (defaults to puma.pid)

[Spaceghost]

Expose puma's pidfile feature to CLI & Server.

Notable: defaulting to puma's default pidfile name (puma.pid) might be awkward in the future if this repo migrates to a different application server. I defer to the google for the desired behavior at this level, but default to puma in this pull request.

I needed this for managing the build infrastructure of data ingestion pipelines.

~Spaceghost

[garethgeorge]

Thanks @Spaceghost for the contribution! Implementation looks good but I'm interested to better understand your use case and whether there is a general need here.

Can you elaborate a bit more on what you are looking to be able to do with the exposed pid file or possibly open an issue to discuss the feature request in detail?

[Spaceghost]

It's to add compatibility and support for systemd. I call your executable in non-production environments like ci and the such; I need accurate handles to the puma process to send signals to for restart and stop in the systemd units.

I hope this helps explain, and apologies for not including more context. More is available if that helps.

I think for general utility, it serves many audiences greater with it than without. The burden incurred is obviated by users of the library relying on #pidfile? or the truthiness of the accessor as well as at the operator/sysop levels. Happy either way though! Thank you for the expedient review, @garethgeorge

[garethgeorge]

Thanks for sharing a bit more about how you're using the FR. I'm curious if you have a need to specifically manage the puma process independently of functions-framework or if this is closer to a work around to ensure that you can signal the two processes?

I'm wondering if you would be able to fork functions-framework in a new process group such that you can signal it and any processes forked by it (i.e. puma) together by signaling the group?

We are evaluating some proposals internally that might move us away from puma for some function signature types (or possibly as a whole) in future releases of functions framework which makes me hesitant to recommend relying on the internals. I'm wondering if there's an approach that will meet your needs that does a better job of treating functions-framework as a blackbox?