Use systemd to start Puma #232
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
javierm
changed the base branch from
master
to
install_specific_nodejs_version
javierm
force-pushed
the
install_specific_nodejs_version
branch
from
05f8278 to
75f6f9e
Compare
Senen
force-pushed
the
install_specific_nodejs_version
branch
4 times, most recently
from
387de80 to
59b8bbb
Compare
Base automatically changed from
install_specific_nodejs_version
to
release_2.1.0
November 23, 2023 18:15
javierm
force-pushed
the
puma_systemd
branch
from
e45f72b to
d14f081
Compare
The `puma.service` file included here is an adaptation of the ERB template provided by the capistrano3-puma gem. In order to transition smoothly from the systemd configuration generated by this installer to the systemd configuration provided by capistrano3-puma, the `puma_service_unit_name` must be the same during both installation and deployment. Note that, now that Puma starts with systemd, we have to wait till it creates a socket before continuing; otherwise the socket file won't be there when we execute the next command, and that command will file. Also note we have to configure the XDG_RUNTIME_DIR variable. Quoting the ansible documentation [1]: > For systemd to work with ‘user’, the executing user must have its own > instance of dbus started and accessible (systemd requirement). > > The user dbus process is normally started during normal login, but not > during the run of Ansible tasks. Otherwise you will probably get a > 'Failed to connect to bus: no such file or directory' error. > > The user must have access, normally given via setting the > XDG_RUNTIME_DIR variable. We also need to check for systemd access because ansible doesn't do it automatically [2]. In order to allow unprivileged users to enable lingering to enable systemd user units, we need to install the policykit-1 package, which is installed by default in Ubuntu but not on Debian Bookworm. Without this package the action of lingering requires sudo priveleges. Finally, we're using Consul Democracy's `master` branch, since it contains support for Puma with Systemd. [1] https://docs.ansible.com/ansible/latest/collections/ansible/builtin/systemd_service_module.html#parameter-scope [2] See issue in 72674 https://github.com/ansible/ansible/issues/ Co-Authored-By: Senén Rodero <senenrodero@gmail.com>
While this isn't needed when starting the Puma service on the server or with Capistrano, we need the RVM script while using the installer. The file is now different from the one generated by capistrano3-puma, but that's alright because it will be overwritten when deploying with Capistrano (as long as the `:puma_service_unit_name` is the same).
The Docker images for Debian don't include systemd and, even when using an image that comes with support with systemd [1], we're getting a warning when starting Puma (the following error takes place when we skip the "Enable systemd access" step, since that step also raises an error in Debian): > Warning: : daemon-reload failed, but target is a chroot or systemd > is offline. > Continuing. Error was: 1 / Failed to connect to bus: No such file or > directory > Warning: : Target is a chroot or systemd is offline. This can > lead to false positives or prevent the init system tools from working. So Puma isn't started in this case. So now Debian support is uncertain, since we aren't able to test that Puma starts correctly and the web is accessible. We're at least testing that the rest of the installation process runs correctly. [1] https://github.com/trfore/docker-debian11-systemd/blob/main/Dockerfile
javierm
force-pushed
the
puma_systemd
branch
from
d14f081 to
5af53dd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
References
Notes
I haven't found a way to run systemd services when testing the installation on Debian with GitHub Actions (not even when using Docker images with systemd). So, for now, we're not testing whether Puma starts correctly on Debian, which means we won't notice it if Puma doesn't start correctly on Debian in the future.