m (→Scope) |
m (→Scope) |
||
| Line 96: | Line 96: | ||
* Proposal owners: | * Proposal owners: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85 the downstream systemd PR] to reduce the unit timout | ** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85 the downstream systemd PR] to reduce the unit timout. | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
** Test their packages with the new behavior and report issues as necessary. | |||
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
Revision as of 10:09, 21 December 2022
Shorter Shutdown Timer
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
A downstream configuration change to reduce the systemd unit timeout from 2 minutes to 15 seconds.
Owner
- Name: catanzaro
- Email: mcatanzaro at redhat dot com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2022-12-21
- 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>
Detailed Description
Currently, services which have stalled or are misbehaving can prevent shutdown for up to 2 minutes. This causes extreme frustrating for our users - someone goes to shutdown or reboot and then unexpectedly has to wait a long time before they can do anything else.
The most common service to cause this issue is PackageKit, but there are others.
The Workstation Working Group has been attempting to eliminate this bug for a number of years. Investigations have revealed that it's not possible to find and fix every misbehaving service: in some cases the misbehaviour comes from design flaws that cannot be reasonably fixed.
An attempt has also been made to have the unit timeout changed in upstream systemd. That attempt did not go anywhere, despite various efforts to move it along.
Feedback
The Workstation Working Group has a ticket where they have been tracking and discussing this issue. This change was also previously proposed to FESCo, where there was some discussion.
Benefit to Fedora
The primary benefit of the change will be to eliminate a very annoying and - frankly - embarrassing bug. Our users shouldn't have to randomly sit waiting for their machine to shutdown.
It will also encourage the correct use of shutdown inhibit APIs by services.
Scope
- Proposal owners:
- Merge the downstream systemd PR to reduce the unit timout.
- Other developers:
- Test their packages with the new behavior and report issues as necessary.
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A (not needed for this Change)
Upgrade/compatibility impact
How To Test
Given the intermittent and unpredictable nature of the bug that is being targeted, the best way to test is by using the upcoming Fedora release. Are shutdown delays eliminated as intended? Do system services experience issues as a result of the change?
User Experience
This change will make the Fedora user experience less annoying.
Dependencies
No specific changes are required in other packages. However, service developers may want to take this opportunity to examine the shutdown behavior of their components.
Contingency Plan
- Contingency mechanism: the change owners will revert the change in systemd.
- Contingency deadline: if we back out the change it would be best to do it before beta freeze.
- Blocks release? No.
Documentation
Documentation isn't required for this minor configuration change. Services that legitimately need to prevent system shutdown should use systemd inhibit. Desktop applications can use the XDG inhibit portal.