Puma: Reloading Master process - Vendored Ruby

[DanielRedOak]

Steps to reproduce

We bundle+vendor Ruby, gems, assets etc into an artifact when deploying our Rails applications by use of a tool called Pkgr. Since this includes Ruby itself, we have noticed some less than desirable behavior with the master process. Essentially the workers reload and use the new code without issue, the master does not load the new ruby from the new release and instead holds open the Ruby from the previous release.

1) Launch Puma from a vendored (or simulated) Ruby. Ex. /opt/app_v1/ruby

2) Deploy new application version, Ex. /opt/app_v2

3) Restart Puma using any of the downtime free methods

Expected behavior

What I am looking to have happen is for the master and workers to both use the new vendored Ruby that is included in the new release, letting go of the old.

Actual behavior

The workers load the new code and serve requests successfully. The master process holds on to Ruby from the last release since it was not reloaded/restarted. This can be observed with lsof

System configuration

Ruby version: 2.4.1
Rails version: 5.1.2
Puma version: 3.10.0

[DanielRedOak]

This isn't a bug per-say but I'm hoping there is a way to accomplish this type of behavior without going back to Unicorn :)

[DanielRedOak]

Is there a puma specific IRC channel or other avenue for support/discussion that would have a better turn around time?

[nateberkopec]

Unfortunately, I don't think Puma will ever be able to fix this for you, given the way we do all of the downtime-free deploys.

This works in Unicorn, though? How did you accomplish this with Unicorn?

[DanielRedOak]

Thanks for the reply. Unicorn essentially spawns a new master from the old, then workers, finally allowing the original master to be killed. They outline the process here: https://bogomips.org/unicorn/SIGNALS.html

Would the best approach with Puma just be separating out the Ruby install from the rest of the package then? It's quite convenient to be able to rely on the package to include its own supported version of Ruby but things will be changing when we complete our move to Docker. Any other pointers are appreciated.