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
There is already a server bound to: /var/run/puma/puma.sock (after OS + ruby upgrade) #2638
Comments
Just to clarify, both OS/Ruby combinations are using Puma 5.3.2? |
@MSP-Greg hey 👋 yes that’s correct. Both are using 5.3.2 |
Thanks. It may be hard to do, but knowing if the problem happens with Ubuntu 20.04 and Ruby 2.6.x would be helpful. I'll try to have a look soon... |
That's a good idea. Not hard as such, but time consuming. I have some build scripts for the server, so I can bootstrap a new one with ruby 2.7.3 or 2.6.x and see if it happens there. It's not exactly the same environment, but might give us a hint or two? If you have other ideas of things I could test/check, I'm happy to try (mind you, going to be on holiday soon, so my availability is more limited, but will do my best. Just thought better to report this first in case someone bumped into something similar) |
I'm seeing this issue also with ruby 2.6.5 so I guess we can eliminate ruby 3 as the culprit here? maybe it's related to Ubuntu 20.04 / systemd ? any tips/suggestions for (other) things to try would be most welcome :) |
Thanks for testing that. I'll try to see if I can repo. The conf option |
I bootstrapped another box with ruby 3 and Ubuntu 18.04, otherwise, same systemd scripts, same code, etc. And it seems to work just fine. So I think there's something between 18.04 and 20.04 that's causing this issue... @nateberkopec since this isn't something easy to repro inside docker, do you have any suggestions on how to reproduce this simply? is there a sample puma app repo I could potentially use? although it means bootstrapping a VM or something ... |
Can you test locally? If so, add the following line as the first line of @events.debug "ENV['LISTEN_FDS'] #{ENV['LISTEN_FDS']} env_hash['LISTEN_PID'] #{env_hash['LISTEN_PID']}" and add |
@MSP-Greg not sure what you mean locally ... it's a remote VM. If there's a puma branch that I can point my Gemfile to, this might be the easiest. Also happy to manually tweak the puma config and retry, sure. |
Ok, I added the line with
|
Thanks. That helps. The debug shows |
Yes, I think I spotted it before when digging through the error. The folders are symlinked on both Ubuntu 18.04 and 20.04 as far as I can tell
|
Ok. Let me see if I can repo. There are a few ways to return the unix path, not sure how symlinks are handled with the various ways... |
Possible reason for this would be that systemd is now creating the socket on the real path, and not the symlink path? Note that if I create a socket from a symlink (in Ruby), the address is shown as the symlink, not the realpath. Puma is trying to match the paths, it's using the symlink, but systemd provided the real path... Wondering how to fix, as abstract sockets may affect the code... |
I made a change in a branch in my fork, I left the debug line in it, but the change was: elsif sock = @activated_sockets.delete([ :unix, path ]) to elsif sock = @activated_sockets.delete([ :unix, path ]) ||
@activated_sockets.delete([ :unix, File.realdirpath(path) ]) |
To clarify, the UNIXSocket path is a symlink, and systemd appears to be using the real path for it. The code in |
Makes sense @MSP-Greg ... I wonder what changes between Ubuntu 18.04 and 20.04 that changes systemd's behaviour. I'll try your branch and see if it works with Ubuntu 20.04 and report back. |
Yep, seems to do the trick 💯 |
@gingerlime Thanks for testing, created a PR... |
Great, thanks so much for your help, @MSP-Greg ! |
Describe the bug
I'm using the exact same systemd scripts, codebase and puma config, but after an OS upgrade from Ubuntu 18.04 to 20.04 and ruby upgrade from 2.6.5 to 3.0.1 ... Somehow though I get a problem starting the puma.socket process
Puma config:
systemd scripts
puma.service
puma.socket
To Reproduce
Using the above systemd script and puma config, I see the error I attached when starting puma. I tried clearing the sock file from
/var/run/puma
but to no avail.Expected behavior
The exact same files and puma config, on a different host (Ubuntu 18.04, ruby 2.6.5) work just fine...
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: