(Announcing the Change proposal) |
(more explanations based on feedback) |
||
| Line 5: | Line 5: | ||
== Summary == | == Summary == | ||
User services ( | User services (units running under systemd user instances) can be restarted as part of the rpm upgrade, if configured so in package scriptlets. This mirrors what is done for system services running under the the main systemd instance. | ||
== Owner == | == Owner == | ||
| Line 31: | Line 31: | ||
== Detailed Description == | == Detailed Description == | ||
We have rpm packaging scriptlets to reexecute systemd and restart system services as part of the rpm update transaction. But we didn't have equivalent services for the user manager. With this change, individual system managers will be reexecuted | Background: a running Fedora system has a main systemd instance (PID 1) and some set of system services running. There are also user instances of systemd that themselves are services running under the main systemd instance (`user@<uid>.service` running `systemd --user`). Those instances in turn execute user services. Those services are unprivileged, executing as the user `<uid>`. Use `systemctl -t service --state running` and `systemctl -t service --state running --user` to list continually-running services. Those are potential candidates for restarting. | ||
We have rpm packaging scriptlets to reexecute systemd and restart system services as part of the rpm update transaction (`%systemd_postun_with_restart` is the main macro to restart a service). But we didn't have equivalent services for the user manager. With this change, when systemd.rpm is upgraded, individual system managers will be reexecuted (`user@<uid>.service`). Various packages can mark their user services to be restarted (`%systemd_user_postun_with_restart`). The restart of user services, similarly to the restart of system services, is done after all packages have been installed, using a transfiletrigger. See the pull requests linked in Scope below for implementation details. | |||
== Feedback == | == Feedback == | ||
"User service" was unclear: para about "Background" was added above. | |||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
| Line 64: | Line 68: | ||
== How To Test == | == How To Test == | ||
Find a package that uses the `%systemd_user_postun_with_restart` macro. (There may be 0 such packages right now. TODO: add specific examples here when known). Upgrade the package using `dnf update …` or reinstall it using `dnf reinstall …`. Look at logs or otherwise verify that the script was restarted, and for an update, that the new version is running. | |||
== User Experience == | == User Experience == | ||
Updates of user services take effect immediately (if so configured in the providing packages). | Updates of user services take effect immediately (if so configured in the providing packages by using `%systemd_user_postun_with_restart`). | ||
== Dependencies == | == Dependencies == | ||
| Line 74: | Line 78: | ||
== Contingency Plan == | == Contingency Plan == | ||
Status quo is that various services are not restarted. Actually I don't expect this to be fully implemented at any point in time. If some service need to not be restarted, e.g. because the restart does not work, change `%systemd_user_postun_with_restart` to `%systemd_user_postun` and rebuild the package. If the whole system is broken, the command that actually does the restart in the systemd transfiletrigger can be disabled. | Status quo is that various services are not restarted. Actually I don't expect this change to be fully implemented at any point in time. If some service need to not be restarted, e.g. because the restart does not work, change `%systemd_user_postun_with_restart` to `%systemd_user_postun` and rebuild the package. If the whole system is broken, the command that actually does the restart in the systemd transfiletrigger can be disabled. | ||
* Contingency deadline: any time | * Contingency deadline: any time | ||
Revision as of 08:16, 29 July 2021
Restart User Services after Upgrade
Summary
User services (units running under systemd user instances) can be restarted as part of the rpm upgrade, if configured so in package scriptlets. This mirrors what is done for system services running under the the main systemd instance.
Owner
- Name: Zbigniew Jędrzejewski-Szmek
- Email: zbyszek AT in.waw.pl
Current status
- Targeted release: Fedora Linux 35
- Last updated: 2021-07-29
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Note: I'm submitting this as very-very-late change for F35. The implementation in systemd is mostly done, so it'll become available in rawhide pretty soon. To actually make use of the new functionality, individual packages should be changed to use _with_restart in their scriptlets and rebuilt. This will happen over time, and it's fine if each package does that on its own schedule. We still do not have that many user services, and restarting from packaging scriptlets will be possible and appropriate only for some of them. I think it's important to make the functionality available, without trying to use it everywhere immediately.
Detailed Description
Background: a running Fedora system has a main systemd instance (PID 1) and some set of system services running. There are also user instances of systemd that themselves are services running under the main systemd instance (user@<uid>.service running systemd --user). Those instances in turn execute user services. Those services are unprivileged, executing as the user <uid>. Use systemctl -t service --state running and systemctl -t service --state running --user to list continually-running services. Those are potential candidates for restarting.
We have rpm packaging scriptlets to reexecute systemd and restart system services as part of the rpm update transaction (%systemd_postun_with_restart is the main macro to restart a service). But we didn't have equivalent services for the user manager. With this change, when systemd.rpm is upgraded, individual system managers will be reexecuted (user@<uid>.service). Various packages can mark their user services to be restarted (%systemd_user_postun_with_restart). The restart of user services, similarly to the restart of system services, is done after all packages have been installed, using a transfiletrigger. See the pull requests linked in Scope below for implementation details.
Feedback
"User service" was unclear: para about "Background" was added above.
Benefit to Fedora
This fixes a long-standing missing feature. We certainly wanted to have this, but the technical implementation is not trivial, because we need to (safely and robustly) reach from the a privileged context into unprivileged user manager instances. Such functionality has been added in systemd, so finally we are able to do this in a fairly clean manner.
User services are becoming more and more important. In particular, we want to be able to restart services such as pipewire.service during upgrades, without requiring a restart of the machine for the upgrade to take effect. Systemd only provides the general functionality. Package maintainers will need to mark their services for restart using %systemd_postun_with_restart if appropriate.
Scope
- Proposal owners:
- implement appropriate functionality (https://github.com/systemd/systemd/pull/17967, https://github.com/systemd/systemd/pull/20157, https://github.com/systemd/systemd/pull/20276, https://github.com/systemd/systemd/pull/20334)
- make a pull request to adjust the packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets)
- Other developers:
- Switch from
%systemd_user_postunto%systemd_user_postun_with_restartif appropriate. - Make sure that their user services behave properly during restart.
- Switch from
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change, all the relevant policies were already in place, but the implementation was missing)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: no
Upgrade/compatibility impact
This makes upgrades better in general. Various updates can take effect immediately without requiring a restart. There should be no noticeable effect on upgrades, barring bugs.
How To Test
Find a package that uses the %systemd_user_postun_with_restart macro. (There may be 0 such packages right now. TODO: add specific examples here when known). Upgrade the package using dnf update … or reinstall it using dnf reinstall …. Look at logs or otherwise verify that the script was restarted, and for an update, that the new version is running.
User Experience
Updates of user services take effect immediately (if so configured in the providing packages by using %systemd_user_postun_with_restart).
Dependencies
None.
Contingency Plan
Status quo is that various services are not restarted. Actually I don't expect this change to be fully implemented at any point in time. If some service need to not be restarted, e.g. because the restart does not work, change %systemd_user_postun_with_restart to %systemd_user_postun and rebuild the package. If the whole system is broken, the command that actually does the restart in the systemd transfiletrigger can be disabled.
- Contingency deadline: any time
- Blocks release? No.
Documentation
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets (TBD)