-
Notifications
You must be signed in to change notification settings - Fork 35
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
Socket activation crashes Thruster #35
Comments
The last line of the stacktrace points here: thruster/internal/upstream_process.go Line 36 in ec8c5f6
Hmm, maybe this is caused by |
The other benefit is of socket activation is binding to a privileged port (which Caddy was taking care of previously). If Thruster isn't compatible with socket activation, how I can run it with systemd without socket activation? I tried to run it without socket activation (by commenting out |
Aha! Adding this to
OK, so I can run Thruster via systemd without socket activation. Yay! Will Thruster accept an active socket from systemd? No worries if not. (I don't know Go but as far as I can tell from the code, it won't.) |
Yesterday I was trying to use socket activation with port 443, which I couldn't get to work. Today I thought maybe it makes more sense to give Puma an activated socket. So I have been trying to use 3000 as an activated socket. This required getting Thruster to call puma.socket
puma.service
However I always get Puma's socket activation docs say:
Does this apply to Thruster? I think it does an exec but my Go's not good enough to be sure. |
Hello!
Usually I deploy Puma behind Caddy, communicating over a socket and using systemd's socket activation. This allows graceful, zero-downtime restarts when deploying a new version of the code.
I'm trying to replace Caddy with Thruster. Ideally I'd like to keep the socket activation so I can have graceful restarts. (I'm not using containers or Kamal; instead I git-push to my production server where a git hook reloads/restarts everything.)
However I can't quite get it to work. My question is: is it actually possible for Thruster to accept a socket from systemd? If not, I'll stop :)
This is what I've got so far:
/etc/systemd/system/puma.service
/etc/systemd/system/puma.socket
The puma.socket seems to start up fine but puma.service doesn't.
The stdout log looks normal but there's a big stacktrace in stderr:
stderr
This is all on Ubuntu 24.04 LTS with Thruster 0.1.4, Puma 6.4.2 and Ruby 3.3.3.
The text was updated successfully, but these errors were encountered: