(rough first draft) |
m (→Scope) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 62: | Line 62: | ||
<!-- 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. --> | ||
* systemd issue - [https://github.com/systemd/systemd/issues/17382 Reduce default journal disk space size limit] | * October 2020: systemd issue - [https://github.com/systemd/systemd/issues/17382 Reduce default journal disk space size limit] | ||
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4ATNDIJGIFGCP6FKVJD72KTFT7ZFRNDY/ thinking journal retention limits] mailing list thread | * January 2021: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4ATNDIJGIFGCP6FKVJD72KTFT7ZFRNDY/ thinking journal retention limits] mailing list thread | ||
* January 2021: [https://pagure.io/fedora-workstation/issue/213 Workstation Working Group issue] | |||
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NDO5S2KUUDO5G6JLKZGQNFBXOW5KHPR5/ Limiting the (systemd) journal size] mailing list thread | * September 2022: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NDO5S2KUUDO5G6JLKZGQNFBXOW5KHPR5/ Limiting the (systemd) journal size] mailing list thread | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Line 103: | Line 103: | ||
* 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?--> | ||
** | ** Create a PR to change the {{package|systemd}} journal limit defaults. | ||
** If the change isn't accepted in systemd, implement it as a downstream patch | ** If the change isn't accepted in systemd, implement it as a downstream patch. | ||
* 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?--> | ||
** Other developers aren't expected to be affected | ** Other developers aren't expected to be affected. | ||
* 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. | ||
Line 141: | Line 141: | ||
--> | --> | ||
Post-release it will be useful to validate that the change has had the intended effect of reducing disk usage. This can be checked with sudo journalctl --disk-usage. | Post-release it will be useful to validate that the change has had the intended effect of reducing disk usage. This can be checked with <code>sudo journalctl --disk-usage</code>. | ||
== User Experience == | == User Experience == | ||
Line 155: | Line 155: | ||
--> | --> | ||
The main user experience change will be increased disk space availability. | |||
== Dependencies == | == Dependencies == | ||
Line 165: | Line 165: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: | * Contingency mechanism: proposal owner to revert the code change if necessary. | ||
* Contingency deadline: beta freeze. | * Contingency deadline: beta freeze. | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> |
Latest revision as of 14:06, 21 December 2022
Reduce the Maximum Journal Size
Summary
Reduce the amount of disk space that the journal can use, by introducing a 3 month retention limit, on top of the existing 4 GB disk space limit.
Owner
- Name: chrismurphy
- Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
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, the journal can occupy up to 4 GB of disk space. 4 GB is a lot of space to use for logs, and this has been a source of user complaints.
Limiting the journal logs to 3 months retention is primarily intended to reduce the amount of disk space used. The time-based limit also intended to set the journal limit based on the need for the data, as opposed to the more arbitrary disk space criteria.
Feedback
- October 2020: systemd issue - Reduce default journal disk space size limit
- January 2021: thinking journal retention limits mailing list thread
- January 2021: Workstation Working Group issue
- September 2022: Limiting the (systemd) journal size mailing list thread
Benefit to Fedora
- Reduce the amount of disk space used for logs, thus increasing the amount of space available for other things
- Reduce user complaints
- A more privacy-conscious design
Scope
- Proposal owners:
- Create a PR to change the
systemd
journal limit defaults. - If the change isn't accepted in systemd, implement it as a downstream patch.
- Create a PR to change the
- Other developers:
- Other developers aren't expected to be affected.
- 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
Post-release it will be useful to validate that the change has had the intended effect of reducing disk usage. This can be checked with sudo journalctl --disk-usage
.
User Experience
The main user experience change will be increased disk space availability.
Dependencies
No dependencies.
Contingency Plan
- Contingency mechanism: proposal owner to revert the code change if necessary.
- Contingency deadline: beta freeze.
- Blocks release? No.