|
|
| (14 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| {{header|docs}} | | {{header|docs}}{{Docs_beat_open}} |
| | |
| {{Docs_beat_open}} | |
| =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====
| |
| <!-- this should be tested! -->
| |
| 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"
| |
| | |
| | |
| | |
| [[Category:Docs Project]] | | [[Category:Docs Project]] |
| [[Category:Draft documentation]] | | [[Category:Draft documentation]] |
| [[Category:Documentation beats]] | | [[Category:Documentation beats]] |
|
| |
| <!-- There's a bit about journalctl cursor seeking, but I can't find a documented definition of 'cursor' or any usage examples. It appears to be for machine users of the journal only. -->
| |
