contrib/systemd: use multi-user.target instead of default.target

[hnez]

The systemd documentation says the following about using default.target as WantedBy= in service files:

For typical unit files please set "WantedBy=" to a regular target (like multi-user.target or graphical.target), instead of default.target, since such a service will also be run on special boots like on system update, emergency boot ...

The mentioned "system update" special boots refer to systemd.offline-updates a mechanism that enables doing a special minimalistic boot to run e.g. migration scripts after installing an update (using a package manager or an image based updater like e.g. RAUC) and before the first boot of the updated system.

To prevent conflicts between normal services on the system and migration scripts, normal services should not be started for these special boots.

For this to work normal services may not use WantedBy=default.target, because according to the documentation the system-update.target becomes the default.target for system-update boots:

3. Very early in the new boot systemd-system-update-generator(8) checks whether /system-update or /etc/system-update exists. If so, it (temporarily and for this boot only) redirects (i.e. symlinks) default.target to system-update.target, a special target that pulls in the base system (i.e. sysinit.target, so that all file systems are mounted but little else) and the system update units.

Use WantedBy=multi-user.target target instead of default.target to enable the use of system-update.target.

Does this PR introduce a user-facing change?

The podman systemd units are now part of the `multi-user.target` instead of the `default.target`

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: hnez
Once this PR has been reviewed and has the lgtm label, please assign mheon for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Luap99]

LGTM however podman generate systemd still generates files with default.target, that command is deprecated but may still be worth to fix the generator?

For the replacement quadlet, user are responsible to set the WantedBy line so it is not a problem there. However the docs use default.target so they should be updated as well.https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#enabling-unit-files

[hnez]

Hi @Luap99, thanks for the quick feedback!

I am not too familiar with the podman codebase or even podman from a users point of view, so I am more or less sed -i "s/default.target/multi-user.target/"-ing blindly here and leaving the compile and runtime testing to the CI pipeline.

Feel free to point out any mistakes I made along the way or things that are still missing.

[Luap99]

Yeah I think some more investigation is needed, looking at the history I found 9a10e21

So it seems simple replace is incorrect and will break all rootless users

$ systemctl --user status multi-user.target
Unit multi-user.target could not be found.
$ sudo systemctl status multi-user.target
● multi-user.target - Multi-User System
...

[Luap99]

Neither multi-user.target or graphical.target exists for a user session it seems so I don't think this change can be correct.

$ ls -l /usr/lib/systemd/system/default.target
lrwxrwxrwx. 1 root root 16 Oct 11 02:00 /usr/lib/systemd/system/default.target -> graphical.target
$ ls -l /usr/lib/systemd/user/default.target
-rw-r--r--. 1 root root 471 Oct  9 17:18 /usr/lib/systemd/user/default.target

So there is a real default.target unit for the user session and not just a symlink to another unit as described in the docs.

As such I think the systemd docs are misleading as they only consider the root case.

We assume that we can use the same unit files for root and rootless, if have to do different things in both cases that will complicate things massively. We do not have a good way to do that as of today, I hacked up a work around for another similar problem recently 6b8e8cb