generate systemd: add default.target to INSTALL
#5427
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vrothberg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
approved
|
@giuseppe @rhatdan @edsantiago PTAL |
|
Could you update |
When enabling a systemd service we can specify which target will start it by specifying it in the `[INSTALL]` section. In case of root, this is commonly set to `multi-user.target` which is used to start other essential system services such as the network manager, D-BUS and more. However, the `multi-user.target` is not enough on all systems, especially when running rootless and enabling user services. Multiple users have reported issues that there isn't even an attempt to start the service. Setting the INSTALL target to `default.target` will fix the rootless case. However, `default.target` may vary among systems. Fedora Workstation, for instance, sets the `default.target` to the graphical target (i.e., runlevel 5) while Fedora Server sets it to `multi-user.target` which is on runlevel 2 and hence way earlier in the startup sequence. As INSTALL allows for specifying multiple INSTALL targets, we can set it to `multi-user.target` to continue supporting existing workloads AND to `default.target` which MAY redundantly attempt to start it at a later point; effectively a NOP for the root case and essential for rootless. Fixes: #5423 Signed-off-by: Valentin Rothberg <[email protected]>
Done. Note that I removed the section from the rootless tutorial. The example there was incorrect. As users should use |
The example was not entirely correct. Users should use `podman generate systemd` and use the output either directly or as a template for further adjustments to their needs. Keeping an example in the rootless tutorial is a maintenance burdon and can easily suggest incorrect usage patterns to users. Signed-off-by: Valentin Rothberg <[email protected]>
|
Not sure why GitHub is not seeing the new commit ... |
vrothberg
force-pushed
the
systemd-default
branch
from
5b7247f to
3c47368
Compare
Accidentally created an upstream branch for it.... |
|
LGTM. Good luck with the flakes. |
|
/lgtm |
openshift-ci-robot
added
the
do-not-merge/hold
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
Shall we force merge? |
|
At this point, yeah, not worth waiting for the bot. |
PR collision with containers#5427 Solution: add 'default.target' to WantedBy Signed-off-by: Ed Santiago <[email protected]>
github-actions
bot
added
the
locked - please file new issue/PR
When enabling a systemd service we can specify which target will start
it by specifying it in the
[INSTALL]section. In case of root, thisis commonly set to
multi-user.targetwhich is used to start otheressential system services such as the network manager, D-BUS and more.
However, the
multi-user.targetis not enough on all systems,especially when running rootless and enabling user services. Multiple
users have reported issues that there isn't even an attempt to start the
service.
Setting the INSTALL target to
default.targetwill fix the rootlesscase. However,
default.targetmay vary among systems. FedoraWorkstation, for instance, sets the
default.targetto the graphicaltarget (i.e., runlevel 5) while Fedora Server sets it to
multi-user.targetwhich is on runlevel 2 and hence way earlier in thestartup sequence.
As INSTALL allows for specifying multiple INSTALL targets, we can set it
to
multi-user.targetto continue supporting existing workloads AND todefault.targetwhich MAY redundantly attempt to start it at a later point;effectively a NOP for the root case and essential for rootless.
Fixes: #5423
Signed-off-by: Valentin Rothberg [email protected]