Documentation System Daemons Beat

Beat Closed on Wiki
Work on beats has now moved to git at https://pagure.io/fedora-docs/release-notes. If you have changes or additions, please contact the docs team via #fedora-docs, docs@lists.fedoraproject.org, or with the release-notes BZ component.

Syslog removed from default installation

syslog is no longer included in default installations. journald logging serves most use cases as well or better than syslogd.

For browsing log messages please type "journalctl" rather than "less /var/log/messages". Please type "journalctl -f" instead of "tail -f /var/log/messages". Please use "journalctl | grep foobar" instead of "grep foobar /var/log/messages". If the administrator needs /var/log/messages or support for the BSD syslog network protocol we recommend installing a syslog daemon such as rsyslog or syslog-ng with a command like like the following: yum install rsyslogd

systemd changes

New unit types

scope units

Scope units are automatically created by systemd out of existing processes. By grouping a process and its children together, a scope unit can be used to organize processes, apply resource units, or kill a group of processes. User sessions are one example of processes contained in a scope unit.

slice units

Slice units are used to group units that manage processes into a hierarchy to allow control of resources allocated for the slice. The default slices, listed below, are automatically populated. + machine.slice, for virtual machines and containers + system.slice, for system services + user.slice, for user sessions

Instance units, such as getty@.service, are spawned on demand using the template defined in their configuration file. Each type of template is given a subslice of the system slice, and instances are contained within that slice.

Scope and service units assigned to a slice are descendants of that slice's node in the control group tree. A slice's name describes its position relative to the root slice. The output below demonstrates how "user-1000.slice" is a child of "user.slice" which is in turn a child of the root slice. Each session is further confined in a scope unit within the user's slice.

user.slice - User and Session Slice

  Loaded: loaded (/usr/lib/systemd/system/user.slice; static)
  Active: active since Sun 2013-09-08 01:23:40 MDT; 18h ago
    Docs: man:systemd.special(7)
  CGroup: /user.slice
          ├─user-1000.slice
          │ ├─session-21.scope
          │ │ ├─9226 sshd: pete [priv]
          │ │ ├─9229 sshd: pete@pts/4
          │ │ ├─9230 -bash
          │ │ ├─9262 sudo su -
          │ │ ├─9270 su -
          │ │ ├─9271 -bash
          │ │ └─9509 screen -R
          │ ├─session-18.scope
          │ │ ├─ 7939 sshd: pete [priv]
          │ │ ├─ 7942 sshd: pete@pts/0
          │ │ ├─ 7943 -bash
          │ │ ├─ 7982 sudo su -
          │ │ ├─ 7988 su -
          │ │ ├─ 7989 -bash
          │ │ ├─ 8206 SCREEN
          │ │ ├─ 8207 /bin/bash
          │ │ ├─ 8237 /bin/bash
          │ │ ├─ 8486 less NEWS
          │ │ ├─ 8489 /bin/bash
          │ │ └─10637 systemctl status user.slice
          <truncated>

Services can be added to a slice with the "Slice=slicename" directive in their unit configuration file. Arguments allowing resource limitations within a slice or service unit are described in man systemd.directives. See also man systemd.slice and man systed.cgroup .

Other Systemd Changes

systemd-cryptsetup for TrueCrypt

Support for TrueCrypt volumes in Fedora is expanded by systemd-cryptsetup's support for the technology, allowing easy authentication to TrueCrypt volumes during boot.

systemctl

Filtering by unit state

systemctl now supports filtering the unit list output by load state. The --state option will accept any value or a comma-separated list values of LOAD, SUB, or ACTIVE states. For example:

systemctl --state failed

journalctl

Viewing the logs of a specific boot

journalctl -b can be used to look for boot output of a specific boot. For example:

journalctl -b # output from current boot
journalctl -b -1 #output from previous boot

In addition to relative boot sequence, journalctl assigns a 128bit boot ID that can be referenced. For example,

journalctl -b  38fd9c3303574ed38e822233457f6b77 # output from a specific designated boot

Referencing the journal with 'cursors'

journalctl can reference the contents of the journal by a record identifier known as a 'cursor'. Similar to a git hash, the cursor uniquely identifies a point in the journal.

If you add --show-cursor to a journalctl query, the last line of output will contain the cursor value:

journalctl -b -u network --show-cursor --since 15:00
Sep 08 15:37:59 localhost.localdomain network[4074]: [FAILED]
Sep 08 15:37:59 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
Sep 08 15:37:59 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
Sep 08 15:37:59 localhost.localdomain systemd[1]: Unit network.service entered failed state.
-- cursor: s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831

The cursor can be used to identify that point in the journal in a broader query to provide context:

journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"

Scripts parsing journalctl's output can store the cursor value and use it on their next run to pick up where they left off:

journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"