Immanetize (talk | contribs) |
Immanetize (talk | contribs) |
||
Line 9: | Line 9: | ||
====slice units==== | ====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 | |||
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=== | ===Other Systemd Changes=== | ||
====systemd-cryptsetup for TrueCrypt==== | ====systemd-cryptsetup for TrueCrypt==== |
Revision as of 01:42, 9 September 2013
systemd changes
systemd
New unit types
scope units
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
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"