diff options
| author | Valentin Rothberg <rothberg@redhat.com> | 2020-03-09 11:56:44 +0100 |
|---|---|---|
| committer | Valentin Rothberg <rothberg@redhat.com> | 2020-03-09 13:33:09 +0100 |
| commit | 220f9a71e47d1fff893114a025960c2d9c3c16fb (patch) | |
| tree | 1b71714061fbf9da6b0067dd5bedad4e0f898a51 /docs/source | |
| parent | f378e82e2d57ee60e5b0f973eb1ea2ee3a760428 (diff) | |
| download | podman-220f9a71e47d1fff893114a025960c2d9c3c16fb.tar.gz podman-220f9a71e47d1fff893114a025960c2d9c3c16fb.tar.bz2 podman-220f9a71e47d1fff893114a025960c2d9c3c16fb.zip | |
generate systemd: add `default.target` to INSTALL
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 <rothberg@redhat.com>
Diffstat (limited to 'docs/source')
| -rw-r--r-- | docs/source/markdown/podman-generate-systemd.1.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/docs/source/markdown/podman-generate-systemd.1.md b/docs/source/markdown/podman-generate-systemd.1.md index 4d3f9ba48..2bcfdb954 100644 --- a/docs/source/markdown/podman-generate-systemd.1.md +++ b/docs/source/markdown/podman-generate-systemd.1.md @@ -42,8 +42,8 @@ Create and print a systemd unit file for a container running nginx with an *alwa $ podman create --name nginx nginx:latest $ podman generate systemd --restart-policy=always -t 1 nginx # container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service -# autogenerated by Podman 1.5.2 -# Wed Aug 21 09:46:45 CEST 2019 +# autogenerated by Podman 1.8.0 +# Wed Mar 09 09:46:45 CEST 2020 [Unit] Description=Podman container-de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6.service @@ -58,7 +58,7 @@ Type=forking PIDFile=/run/user/1000/overlay-containers/de1e3223b1b888bc02d0962dd6cb5855eb00734061013ffdd3479d225abacdc6/userdata/conmon.pid [Install] -WantedBy=multi-user.target +WantedBy=multi-user.target default.target ``` Create systemd unit files for a pod with two simple alpine containers. Note that these container services cannot be started or stopped individually via `systemctl`; they are managed by the pod service. You can still use `systemctl status` or journalctl to examine them. @@ -72,8 +72,8 @@ $ podman generate systemd --files --name systemd-pod /home/user/container-jolly_shtern.service $ cat pod-systemd-pod.service # pod-systemd-pod.service -# autogenerated by Podman 1.5.2 -# Wed Aug 21 09:52:37 CEST 2019 +# autogenerated by Podman 1.8.0 +# Wed Mar 09 09:52:37 CEST 2020 [Unit] Description=Podman pod-systemd-pod.service @@ -90,7 +90,7 @@ Type=forking PIDFile=/run/user/1000/overlay-containers/ccfd5c71a088768774ca7bd05888d55cc287698dde06f475c8b02f696a25adcd/userdata/conmon.pid [Install] -WantedBy=multi-user.target +WantedBy=multi-user.target default.target ``` ## SEE ALSO |