thomasabishop/eolas
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Last Sync: 2022-08-18 08:30:04

Browse source
This commit is contained in:
tactonbishop 2022-08-18 08:30:04 +01:00
parent 7039703c05
commit 2469f8fc01
2 changed files with 173 additions and 59 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

59
Linux/Procedural/systemd.md
View file

@ -1,59 +0,0 @@
---
categories:
- Linux
- Operating_Systems
tags: [user_space, systems_programming]
---
# `systemd`
Once the [boot process](/Operating_Systems/Boot_process.md) has completed and the bootloader has located the kernel and injected it into memory the first user space program runs: `init` (for _initialisation_). `init` is a [daemon](/Operating_Systems/Daemons.md) process that continues running until shutdown and is responsible for starting all the processes that are prerequisites for user space. For example: network connections, disk access, user logins etc.
`init` is the parent of all processes. Whilst it does a lot of its work in quick succession at boot time it is not limited to the this stage of the lifescycle but runs continuously in reponse to new user events.
On Linux systems `systemd` is used to implement `init`.
`systemd` is directly accessible from user space and provides a straightforward way to enable/disable, start/stop system level processes
> `systemd` can track individual service daemons after they start, and group together multiple processes associated with a service, giving you more power and insight into exactly what is running on the system _How Linux Works: Third Edition_, Brian Ward 2021
## How `systemd` works
### Goal-directed units
`systemd` works on the basis of _goals_. Each goal is system task defined as a **unit**. A unit contains instructions and a specification of dependencies to other units.
When activating a unit, `systemd` first activates the dependencies and then moves onto the details of the unit itself. `init` as implemented by `systemd` does not follow a rigid sequence every time, initialising units in the same sequence and waiting for one to complete before starting another. Instead it activates units whenever they are ready.
### Unit types
Units are organised into **unit types**. The main types that run at boot time are as follows:
- service units
- control service daemons
- target units
- control other units by organising them into groups
- socket units
- handle incoming network connection request locations
- mount units
- handle the attachment of filesystems to the system
For example, at boot a target unit called `default.target` groups together a number of service and mount units as dependencies. These then run in a graph-like dependency structure where a unit that comes late in the boot process can depend on several previous units making earlier branches of a dependency tree join back together.
## `systemd` configuration files
Units are managed via `systemd` configuration files.
### Configuration file locations
System level `systemd` config files are located in the _system unit directory_ at `/usr/lib/systemd/system`. You shouldn't change or manipulate these files or attempt to add new config files here since they will be overwritten by the system.
![](/img/systemd-global-files.png)
_`systemd` global unit files_
Local definitions that relate to the specific user and where the user herself can define units are located in the _system configuration_ directory: `/etc/systemd/system`.
![](../../img/systemd-local-files.png)
_`systemd` local unit files, specific to the currently logged-in user_

173
Linux/systemd.md Normal file
View file

@ -0,0 +1,173 @@
---
categories:
- Linux
- Operating_Systems
tags: [user_space, systems_programming]
---
# `systemd`
Once the [boot process](/Operating_Systems/Boot_process.md) has completed and the bootloader has located the kernel and injected it into memory the first user space program runs: `init` (for _initialisation_). `init` is a [daemon](/Operating_Systems/Daemons.md) process that continues running until shutdown and is responsible for starting all the processes that are prerequisites for user space. For example: network connections, disk access, user logins etc.
`init` is the parent of all processes. Whilst it does a lot of its work in quick succession at boot time it is not limited to the this stage of the lifescycle but runs continuously in reponse to new user events.
On Linux systems `systemd` is used to implement `init`.
`systemd` is directly accessible from user space and provides a straightforward way to enable/disable, start/stop system level processes
> `systemd` can track individual service daemons after they start, and group together multiple processes associated with a service, giving you more power and insight into exactly what is running on the system _How Linux Works: Third Edition_, Brian Ward 2021
## How `systemd` works
### Goal-directed units
`systemd` works on the basis of _goals_. Each goal is system task defined as a **unit**. A unit contains instructions and a specification of dependencies to other units.
When activating a unit, `systemd` first activates the dependencies and then moves onto the details of the unit itself. `init` as implemented by `systemd` does not follow a rigid sequence every time, initialising units in the same sequence and waiting for one to complete before starting another. Instead it activates units whenever they are ready.
### Unit types
Units are organised into **unit types**. The main types that run at boot time are as follows:
- service units
- control service daemons
- target units
- control other units by organising them into groups
- socket units
- handle incoming network connection request locations
- mount units
- handle the attachment of filesystems to the system
For example, at boot, a target unit called `default.target` groups together a number of service and mount units as dependencies. These then run in a graph-like dependency structure where a unit that comes late in the boot process can depend on several previous units making earlier branches of a dependency tree join back together.
## `systemd` configuration files
Units are managed via `systemd` configuration files.
### Configuration file locations
System level `systemd` config files are located in the _system unit directory_ at `/usr/lib/systemd/system`. You shouldn't change or manipulate these files or attempt to add new config files here since they will be overwritten by the system.
![](/img/systemd-global-files.png)
_`systemd` global unit files_
Local definitions that relate to the specific user and where the user herself can define units are located in the _system configuration_ directory: `/etc/systemd/system`.
![](../../img/systemd-local-files.png)
_`systemd` local unit files, specific to the currently logged-in user_
### Example files
Below is the systemd service file for the creation of UUIDs:
```plain
[Unit]
Description=Daemon for generating UUIDs
Documentation=man:uuidd(8)
Requires=uuidd.socket
[Service]
ExecStart=/usr/sbin/uuidd --socket-activation
Restart=no
User=uuidd
Group=uuidd
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
PrivateUsers=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
ReadWritePaths=/var/lib/libuuid/
SystemCallFilter=@default @file-system @basic-io @system-service @signal @io-event @network-io
[Install]
Also=uuidd.socket
```
* The `Unit` section provides metadata about the unit including which `systemd` dependencies it has
* `Service` constitutes the main specification for the unit
* `Install` is the call to set the dependencies running before the `Service` functions are accessible.
## `systemd` operations: `systemctl`
The `systemctl` command is the chief way of interacting with `systemd`. You use it to activate and deactivate services, list their status, reload the configuration and so.
### Viewing active units
Below I have listed the running units pertaining to bluetooth:
```
$ systemctl list-units | grep bluetooth
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0-hci0:3585.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:3585
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0
sys-subsystem-bluetooth-devices-hci0.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0
sys-subsystem-bluetooth-devices-hci0:3585.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0:3585
bluetooth.service loaded active running Bluetooth service
bluetooth.target loaded active active Bluetooth Support
```
### Get status of a specific unit
Here I have requested the status of the currently running `mongodb` unit:
```
$ systemctl status mongod
mongodb.service - MongoDB Database Server
Loaded: loaded (/usr/lib/systemd/system/mongodb.service; enabled; preset: disabled)
Active: active (running) since Wed 2022-08-17 07:25:27 BST; 24h ago
Docs: https://docs.mongodb.org/manual
Main PID: 931 (mongod)
Memory: 304.1M
CPU: 2min 18.630s
CGroup: /system.slice/mongodb.service
└─931 /usr/bin/mongod --config /etc/mongodb.conf
Aug 17 07:25:27 archbish systemd[1]: Started MongoDB Database Server.****
```
We can also view the journal entry for the given unit. This provides you with its diagnostic log messages:
```
journalctl --unit=mongodb.service
- Boot b9565dfe8aca4d069143209b3aa84d8e --
Aug 05 18:31:30 archbish systemd[1]: Started MongoDB Database Server.
Aug 06 14:27:33 archbish systemd[1]: mongodb.service: Deactivated successfully.
Aug 06 14:27:33 archbish systemd[1]: mongodb.service: Consumed 3min 17.598s CPU time.
-- Boot 01922f84c3bd4b3a8f11824cf05f7320 --
Aug 07 11:58:09 archbish systemd[1]: Started MongoDB Database Server.
Aug 08 14:43:01 archbish systemd[1]: mongodb.service: Deactivated successfully.
Aug 08 14:43:01 archbish systemd[1]: mongodb.service: Consumed 5min 28.760s CPU time.
-- Boot e52b735e115c43bdad8c00462aaff395 --
Aug 10 13:13:22 archbish systemd[1]: Started MongoDB Database Server.
Aug 11 07:46:40 archbish systemd[1]: mongodb.service: Deactivated successfully.
Aug 11 07:46:40 archbish systemd[1]: mongodb.service: Consumed 2min 16.629s CPU time.
```
Each entry is organised around specific boots.
### List jobs
Requests to activate, reactivate and restart units are called **jobs** in `systemd`. They can be thought of as unit state changes. Current jobs can be listed with `systemctl list-jobs`.
This will most likely return `No jobs running` if the computer has been running for a while. Most jobs execute at boot.
### Enable/disable, start/stop units
If a unit has dependencies it is necessary to _enable_ it before starting it. This installs the dependencies.
```
systemctl enable mongodb.service
```
Then we can start:
```
systemctl start mongodb.service
```
To stop the service:
```
systemctl stop mongodb.service
```