From Fedora Project Wiki
(Announcing the Change proposal)
(Add trackers)
 
(2 intermediate revisions by the same user not shown)
Line 9: Line 9:


== Current status ==
== Current status ==
[[Category:ChangeAnnounced]]
[[Category:ChangeAcceptedF36]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 28: Line 28:
-->
-->
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DLQYXRM4PNJKZZCHMP5QRIADIJ7WMSL4/ devel thread]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DLQYXRM4PNJKZZCHMP5QRIADIJ7WMSL4/ devel thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2701 #2701]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2028169 #2028169]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/775 #775]


== Detailed Description ==
== Detailed Description ==

Latest revision as of 16:14, 1 December 2021

Unit Names in Systemd Messages

Summary

The default format of messages printed by systemd to the console and the journal is changed from "Starting Frobnicating Daemon..." / "Started Frobnicating Daemon" to "Starting frobnicator.service — Frobnicating Daemon..." / "Started frobnicator.service — Frobnicating Daemon".

Owner

Current status

Detailed Description

Systemd has three message formatting modes: description, name, and combined. The first uses the Description, the second uses the unit name, and the third uses "<name> — <Description>". We currently default to description, and the proposal is to change the compile-time default to combined. Users can override the default by creating a configuration file and/or specifying an override on the kernel command line.

systemd historically used the unit Description in console and journal status messages, just like SysV init scripts. The Description is intended to be easy to understand, but has the downside that to interact with the service in any way, one has to figure out what the unit name is. Thus, for an unfamiliar service, the user would have to grep the unit list for the description first. And for more experienced users, the unit name is more informative than the description. People interact with unit names when operating on units, and don't look at the descriptions during normal system administration. Thus, for both new and experienced users, seeing the unit name is useful. To make the change easier to accept, we added the combined mode, that also prints the description on the right.

journalctl -o cat (old and new):

Started Journal Service.
Finished Load Kernel Modules.
Starting Apply Kernel Variables...
Starting Create Volatile Files and Directories...
Finished Apply Kernel Variables.
Finished Create Volatile Files and Directories.
Finished Setup Virtual Console.
Starting dracut ask for additional cmdline parameters...
Finished dracut ask for additional cmdline parameters.
Starting dracut cmdline hook...
Started systemd-journald.service - Journal Service.
Finished systemd-modules-load.service - Load Kernel Modules.
Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev.
Starting systemd-sysctl.service - Apply Kernel Variables...
Starting systemd-tmpfiles-setup.service - Create Volatile Files and Directories...
Finished systemd-sysctl.service - Apply Kernel Variables.
Finished systemd-tmpfiles-setup.service - Create Volatile Files and Directories.
Finished systemd-vconsole-setup.service - Setup Virtual Console.
Starting dracut-cmdline-ask.service - dracut ask for additional cmdline parameters...
Finished dracut-cmdline-ask.service - dracut ask for additional cmdline parameters.
Starting dracut-cmdline.service - dracut cmdline hook...

If users don't like the new default, they can use systemd.status-unit-format=name|description to override the default. It is also possible to use bootctl systemd-efi-options systemd.status-unit-format=name|description on EFI systems, and create a config file with [Manager] StatusUnitFormat=name|description to pick a different setting.

Feedback

Benefit to Fedora

The default format of messages is more directly useful. A user can select&paste the unit name directly from a message into a command like systemctl status or journalctl -u.

Scope

  • Proposal owners:
    • Implement the new mode (already done, available in systemd-249).
    • Flip the compile-time default in systemd.
  • Other developers:
    • Adjust Descriptions of their units if appropriate. For example, firewalld.service repeats the unit name in the Description. This was already discouraged in the systemd.unit(5) man page, but now becomes even more visible: rawhide systemd[1]: Starting firewalld.service - firewalld - dynamic firewall daemon.... The Description should be changed to "Description=Dynamic Firewall Daemon".
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:

Upgrade/compatibility impact

There shouldn't be any. I'm making this a Change because people don't like surprises in the default look of things. There might be some poorly written scripts which grep for unit Descriptions.


How To Test

Boot, look at journalctl -b _PID=1.

Optionally, disable the plymouth screen (with Esc or by removing rhgb quiet on the kernel command line), and look at console messages. Output should contain unit names and be generally readable. Unfortunately, the console output is ellipsized to fit in 80 columns, so the full text is not always visible.

User Experience

See example output above.

Dependencies

None.

Contingency Plan

  • Contingency mechanism: Revert the change.
  • Contingency deadline: Final release, or maybe even later.
  • Blocks release? No.

Documentation

Release Notes