From Fedora Project Wiki
m (Add trackers)
(→‎Current status: bump to F33)
Line 41: Line 41:
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/32 | Fedora 32 ]]  
+
* Targeted release: [[Releases/33 | Fedora 33 ]]  
 
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  

Revision as of 09:39, 25 February 2020


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

Current status

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 /usr/lib/systemd/system/<service>.service.d/needs-restart.conf. The exact name of the option should be something like X-restart-on-upgrade=true|false. 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.

Scope

  • Proposal owners:
    • implement the relevant bits in the systemd package
    • submit a proposal to FPC
    • convert a subset of packages
  • Other developers:
    • FPC: review (and accept ;)) the guidelines changes
    • other maintainers: convert other packages
  • Release engineering: n/a
  • Policies and guidelines: a pull request will be submitted
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change should be backwards compatible, i.e. unconverted packages can be still installed on new systems, and services will be restarted on upgrade like before. Converted packages may be installed on older systems but will not get restarted on upgrades.

How To Test

This change should be mostly invisible to users. Check that during upgrades services are restarted and that no warnings are emitted.

User Experience

N/A

Dependencies

N/A

Contingency Plan

  • Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package.
  • Contingency deadline: beta freeze
  • Blocks release? No
  • Blocks product? No

Documentation

TBD.

Release Notes

Not needed.