Note from the change owner: 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.

https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade


== Summary ==
User services (services running under systemd user instances) will be
restarted as part of the rpm upgrade. This mirrors what is done for
system services.

== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek AT in.waw.pl


== 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, and various packages
can mark their user services to be restarted. The restart of services,
similarly to the restart of system services, is done after all
packages have been installed, using a transfiletrigger.


== 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_postun` to
`%systemd_user_postun_with_restart` if appropriate.
** Make sure that their user services behave properly during restart.

* Release engineering: [https://pagure.io/releng/issues #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 ==
Upgrade packages with user services that should be restarted. Look at
logs or otherwise verify that the new version is running.

== User Experience ==
Updates of user services take effect immediately (if so configured in
the providing packages).

== Dependencies ==
None.

== 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.

* Contingency deadline: any time
* Blocks release? No.


== Documentation ==
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets
(TBD)



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to