Autosave: 2023-01-08 14:00:08
This commit is contained in:
parent
f7217e2df6
commit
42f010a570
1 changed files with 32 additions and 28 deletions
|
|
@ -4,14 +4,13 @@ categories:
|
||||||
tags: [systems-programming, systemd]
|
tags: [systems-programming, systemd]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
# `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.
|
`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`.
|
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` is directly accessible from user space and provides a straightforward way to enable/disable, start/stop system level processes
|
||||||
|
|
||||||
|
|
@ -40,7 +39,6 @@ Units are organised into **unit types**. The main types that run at boot time ar
|
||||||
- target units
|
- target units
|
||||||
- control other units by organising them into groups
|
- 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
|
## `systemd` configuration files
|
||||||
|
|
@ -54,7 +52,6 @@ System level `systemd` config files are located in the _system unit directory_ a
|
||||||

|

|
||||||
_`systemd` global unit files_
|
_`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`.
|
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,17 +88,17 @@ SystemCallFilter=@default @file-system @basic-io @system-service @signal @io-eve
|
||||||
Also=uuidd.socket
|
Also=uuidd.socket
|
||||||
```
|
```
|
||||||
|
|
||||||
* The `Unit` section provides metadata about the unit including which `systemd` dependencies it has
|
- The `Unit` section provides metadata about the unit including which `systemd` dependencies it has
|
||||||
* `Service` constitutes the main specification for the unit
|
- `Service` constitutes the main specification for the unit
|
||||||
* `Install` is the call to set the dependencies running before the `Service` functions are accessible.
|
- `Install` is the call to set the dependencies running before the `Service` functions are accessible.
|
||||||
|
|
||||||
## `systemd` operations: `systemctl`
|
## `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
|
### 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.
|
|
||||||
|
|
||||||
|
`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
|
||||||
|
|
||||||
|
|
@ -118,6 +115,7 @@ $ systemctl list-units | grep bluetooth
|
||||||
```
|
```
|
||||||
|
|
||||||
### Get status of a specific unit
|
### Get status of a specific unit
|
||||||
|
|
||||||
Here I have requested the status of the currently running `mongodb` unit:
|
Here I have requested the status of the currently running `mongodb` unit:
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
@ -133,6 +131,7 @@ mongodb.service - MongoDB Database Server
|
||||||
└─931 /usr/bin/mongod --config /etc/mongodb.conf
|
└─931 /usr/bin/mongod --config /etc/mongodb.conf
|
||||||
Aug 17 07:25:27 archbish systemd[1]: Started MongoDB Database Server.****
|
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:
|
We can also view the journal entry for the given unit. This provides you with its diagnostic log messages:
|
||||||
|
|
@ -171,6 +170,7 @@ Created symlink /etc/systemd/system/multi-user.target.wants/mongodb.service →
|
||||||
```
|
```
|
||||||
|
|
||||||
Then we can start:
|
Then we can start:
|
||||||
|
|
||||||
```
|
```
|
||||||
systemctl start mongodb.service
|
systemctl start mongodb.service
|
||||||
```
|
```
|
||||||
|
|
@ -187,3 +187,7 @@ After this we should disable it, in order to remove any symbolic links it has cr
|
||||||
systemctl disable mongodb.service
|
systemctl disable mongodb.service
|
||||||
Removed "/etc/systemd/system/multi-user.target.wants/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