On Thu, Jan 02, 2020 at 10:45:07AM -0500, Neal Gompa wrote: > On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction > > > > == Summary == > > > > Scriptlets to restart each service that should be restarted in each > > rpm package will be replaced by a declaration in the unit file and an > > rpm transaction trigger that fires at the end and restarts all > > services. > > > > == Owner == > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > * Email: zbyszek at in waw pl > > > > > > == Detailed Description == > > > > Currently, when packages containing systemd services are upgraded, > > they are restarted through %post scriptlets in each package. In other > > words, the scriptlets specify which services should be restarted and > > actually run the command to restart the service. An alternative > > mechanism will be provided, whereby the unit file contains a setting > > which specifies that the service should be restarted on upgrade, and a > > %transfiletrigger in the systemd package will restart all services > > marked so in upgraded packages at the end of transaction. > > > > To mark a services as "restart on upgrade" the unit file should > > contain an option to mark it so. This can be either in the main > > .service file, or e.g. in a drop-in file in > > <code>/usr/lib/systemd/system/<service>.service.d/needs-restart.conf</code>. > > The exact name of the option should be something like > > <code>X-restart-on-upgrade=true|false</code>. I'll take the proposal > > for discussion in systemd upstream, since this is something that could > > be used across distributions, and then the "X-" prefix could be > > dropped and/or the name changed. > > > > == Benefit to Fedora == > > > > Which services should be restarted is specified declaratively and the > > number of scriptlets is reduced. > > > > Admins may easily override this by providing appropriate drop-ins of > > their own of higher priority. > > > > Services are restarted after the transaction is finished, all > > libraries have been upgraded, and systemd configuration reloaded. This > > solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a > > more general problem: a service may be restarted before any of its > > dependencies (files and static content and whatnot) have been > > upgraded, and while some contents from the old rpm are still on disk. > > Restarting after all packages have been upgraded avoids this issue. > > > > In the future, restarting of services shall also be extended to user > > managers (i.e. to restart all user services after the packages > > providing those services have been upgraded). This is not part of this > > proposal, but moving the information what to restart into systemd > > units makes this much easier. > > > > OpenMandriva actually implemented a variation of this two years ago, > as well as a way to do preset runs through file triggers (more or less > eliminating every single scriptlet for systemd units for ~90% of > packages). I considered bringing this over to Fedora, but the > mechanisms in systemd seem to still be a bit wobbly. We don't do presets through file triggers because we the scriptlet is conditionalized to only do the preset on initial package installation. But if it is possible to do something equivalent (or better?) through a file trigger, that'd be great. I'm all ears. > Even with this proposal, how do we deal with system upgrades? In the > system upgrade case, we don't really want these restarts to run, > because the system will be rebooted anyway... These kinds of questions > are why I didn't propose porting over what we did in OpenMandriva to > Fedora. It's rather wasteful in a rather common case... I'm not sure if skipping restarts on upgrade is worth the trouble. It should be quite simple to implement (e.g. by having the restart scriptlet check if the systemd target has been diverted to system-update.target), but restarting of services would most likely take only a small fraction of time required for the upgrade anyway. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
