Autosave: 2023-01-08 14:00:08
This commit is contained in:
thomasabishop
parent
f7217e2df6
commit
42f010a570
1 changed files with 32 additions and 28 deletions
|
|
@ -1,17 +1,16 @@
|
|||
---
|
||||
categories:
|
||||
- Linux
|
||||
- Linux
|
||||
tags: [systems-programming, systemd]
|
||||
---
|
||||
|
||||
|
||||
# `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.
|
||||
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: PID1. 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`.
|
||||
`init` is the parent of all processes: PID1. 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
|
||||
|
||||
|
|
@ -19,18 +18,18 @@ Once the [boot process](/Operating_Systems/Boot_process.md) has completed and t
|
|||
|
||||
## How `systemd` works
|
||||
|
||||
### Goal-directed units
|
||||
### 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.
|
||||
`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. This, its parallelized nature, is one of the main advantages over previous programs that managed the `init` sequence on Linux (such as for example System V);
|
||||
|
||||
### Unit types
|
||||
### Unit types
|
||||
|
||||
Units are organised into **unit types**. The main types that run at boot time are as follows:
|
||||
|
||||
- service units (`.service`)
|
||||
- control service daemons
|
||||
- control service daemons
|
||||
- socket units (`.socket`)
|
||||
- handle incoming network connection request locations
|
||||
- device units (`.device)
|
||||
|
|
@ -40,12 +39,11 @@ Units are organised into **unit types**. The main types that run at boot time ar
|
|||
- target units
|
||||
- control other units by organising them into groups
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
Units are managed via `systemd` configuration files.
|
||||
|
||||
### Configuration file locations
|
||||
|
||||
|
|
@ -54,7 +52,6 @@ System level `systemd` config files are located in the _system unit directory_ a
|
|||
|
||||
_`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`.
|
||||
|
||||
|
||||
|
|
@ -91,19 +88,19 @@ SystemCallFilter=@default @file-system @basic-io @system-service @signal @io-eve
|
|||
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.
|
||||
- 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.
|
||||
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.
|
||||
|
||||
### View the dependency graph
|
||||
|
||||
`systemctl status` by itself will print a long list of units grouped by their dependency relations. It will also provide some metadata about the current systemd boot context.
|
||||
|
||||
|
||||
### Viewing active units
|
||||
### Viewing active units
|
||||
|
||||
Below I have listed the running units pertaining to bluetooth:
|
||||
|
||||
|
|
@ -118,6 +115,7 @@ $ systemctl list-units | grep bluetooth
|
|||
```
|
||||
|
||||
### Get status of a specific unit
|
||||
|
||||
Here I have requested the status of the currently running `mongodb` unit:
|
||||
|
||||
```
|
||||
|
|
@ -133,7 +131,8 @@ mongodb.service - MongoDB Database Server
|
|||
└─931 /usr/bin/mongod --config /etc/mongodb.conf
|
||||
Aug 17 07:25:27 archbish systemd[1]: Started MongoDB Database Server.****
|
||||
```
|
||||
In addition to the core info it tells us the unit type. In this case it is a service.
|
||||
|
||||
In addition to the core info it tells us the unit type. In this case it is a service.
|
||||
|
||||
We can also view the journal entry for the given unit. This provides you with its diagnostic log messages:
|
||||
|
||||
|
|
@ -155,27 +154,28 @@ Aug 11 07:46:40 archbish systemd[1]: mongodb.service: Consumed 2min 16.629s CPU
|
|||
|
||||
Each entry is organised around specific boots.
|
||||
|
||||
### List jobs
|
||||
### 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`.
|
||||
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.
|
||||
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.
|
||||
If a unit has dependencies it is necessary to _enable_ it before starting it. This installs the dependencies.
|
||||
|
||||
```bash
|
||||
systemctl enable mongodb.service
|
||||
Created symlink /etc/systemd/system/multi-user.target.wants/mongodb.service → /usr/lib/systemd/system/mongodb.service.
|
||||
```
|
||||
|
||||
Then we can start:
|
||||
Then we can start:
|
||||
|
||||
```
|
||||
systemctl start mongodb.service
|
||||
```
|
||||
|
||||
To stop the service:
|
||||
To stop the service:
|
||||
|
||||
```
|
||||
systemctl stop mongodb.service
|
||||
|
|
@ -186,4 +186,8 @@ After this we should disable it, in order to remove any symbolic links it has cr
|
|||
```bash
|
||||
systemctl disable mongodb.service
|
||||
Removed "/etc/systemd/system/multi-user.target.wants/mongodb.service".
|
||||
```
|
||||
```
|
||||
|
||||
## Why use `systemd` over `cron` ?
|
||||
|
||||
https://mark.stosberg.com/2016-08-26-rsnapshot-and-systemd/
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue