From Fedora Project Wiki

Line 14: Line 14:
+ system.slice, for system services
+ system.slice, for system services
+ user.slice, for user sessions   
+ 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.
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.


user.slice - User and Session Slice
user.slice - User and Session Slice

Revision as of 03:41, 9 September 2013

DocsProject Header docTeam1.png


Note.png
Beat is open
This beat is now ready to have Fedora 25 content added by the beat writer

systemd changes

systemd

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.

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>

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"