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
 | 
				
			||||||
 | 
					
 | 
				
			||||||
| 
						 | 
					@ -30,7 +29,7 @@ When activating a unit, `systemd` first activates the dependencies and then move
 | 
				
			||||||
Units are organised into **unit types**. The main types that run at boot time are as follows:
 | 
					Units are organised into **unit types**. The main types that run at boot time are as follows:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
- service units (`.service`)
 | 
					- service units (`.service`)
 | 
				
			||||||
  -  control service daemons
 | 
					  - control service daemons
 | 
				
			||||||
- socket units (`.socket`)
 | 
					- socket units (`.socket`)
 | 
				
			||||||
  - handle incoming network connection request locations
 | 
					  - handle incoming network connection request locations
 | 
				
			||||||
- device units (`.device)
 | 
					- device units (`.device)
 | 
				
			||||||
| 
						 | 
					@ -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