refactor
This commit is contained in:
parent
ba7e1304a4
commit
08ad3d672d
3 changed files with 16 additions and 12 deletions
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
obj: concept
|
||||
arch-wiki: https://wiki.archlinux.org/title/Systemd/Timers
|
||||
---
|
||||
|
||||
# Systemd Timers
|
||||
|
|
|
@ -1,9 +1,11 @@
|
|||
---
|
||||
website: https://systemd.io/
|
||||
website: https://systemd.io
|
||||
arch-wiki: https://wiki.archlinux.org/title/systemd
|
||||
wiki: https://en.wikipedia.org/wiki/Systemd
|
||||
repo: https://github.com/systemd/systemd
|
||||
obj: application
|
||||
---
|
||||
|
||||
#refactor
|
||||
# Systemd
|
||||
systemd is a suite of basic building blocks for a [Linux](Linux.md) system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using [Linux](Linux.md) control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
|
||||
|
||||
|
@ -119,19 +121,19 @@ WantedBy=multi-user.target
|
|||
The Unit sectoin contains details and description about the unit itself. In our case, it contains details about the service. Details like 'what is it's description', 'what are it's dependencies' and more.
|
||||
|
||||
Below are the fields the Unit section has:
|
||||
- `Description`:- Human-readable title of the systemd service.
|
||||
- `After`:- Set dependency on a service. For example, if you are configuring Apache web server, you want the server to start after the network is online. This typically includes targets or other services.
|
||||
- `Before`:- Start current service before specified service. This too, like `After`, includes targets or other services.
|
||||
- `Description`: Human-readable title of the systemd service.
|
||||
- `After`: Set dependency on a service. For example, if you are configuring Apache web server, you want the server to start after the network is online. This typically includes targets or other services.
|
||||
- `Before`: Start current service before specified service. This too, like `After`, includes targets or other services.
|
||||
|
||||
### The `[Service]` section
|
||||
The Service section contains details about the execution and termination of service.
|
||||
|
||||
Below are the fields the Service section can have:
|
||||
- `ExecStart`:- The command that needs to be executed when the service starts.
|
||||
- `ExecReload`:- This is an optional field. It specifies how a service is restarted. For services that perform disk I/O (especially writing to disk, like a database), it is best to gracefully kill them and start again. Use this field in case you wish to have a specific restart mechanism.
|
||||
- `Type`:- The process start-up type for this systemd service. Options are `simple`, `exec`, `forking`, `oneshot`, `dbus`, `notify` and `idle`.
|
||||
- `Restart`:- This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are `no`, `on-success`, `on-failure`, `on-abnormal`, `on-watchdog`, `on-abort` and `always`.
|
||||
- `Environment`: Environment Variables
|
||||
- `ExecStart`: The command that needs to be executed when the service starts.
|
||||
- `ExecReload`: This is an optional field. It specifies how a service is restarted. For services that perform disk I/O (especially writing to disk, like a database), it is best to gracefully kill them and start again. Use this field in case you wish to have a specific restart mechanism.
|
||||
- `Type`: The process start-up type for this systemd service. Options are `simple`, `exec`, `forking`, `oneshot`, `dbus`, `notify` and `idle`.
|
||||
- `Restart`: This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are `no`, `on-success`, `on-failure`, `on-abnormal`, `on-watchdog`, `on-abort` and `always`.
|
||||
- `Environment`: [Environment Variables](Environment%20Variables.md)
|
||||
- `User`: The user that should run the process
|
||||
- `WorkingDirectory`: Working directory of the process
|
||||
|
||||
|
@ -139,8 +141,8 @@ Below are the fields the Service section can have:
|
|||
The Install section, as the name says, handles the installation of a systemd service/unit file. This is used when you run either `systemctl enable` and `systemctl disable` command for enable/disable a service.
|
||||
|
||||
Below are the fields the Install section has:
|
||||
- `WantedBy`:- This is similar to the `After` and `Before` fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The `default.target` is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
|
||||
- `RequiredBy`:- This field might feel very similar to `WantedBy`, but the main difference is that this field specifies _hard dependencies_. Meaning, if a dependency, this service will fail.
|
||||
- `WantedBy`: This is similar to the `After` and `Before` fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The `default.target` is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
|
||||
- `RequiredBy`: This field might feel very similar to `WantedBy`, but the main difference is that this field specifies _hard dependencies_. Meaning, if a dependency, this service will fail.
|
||||
|
||||
### Other Unit Types
|
||||
Systemd supports other unit types than `.service`.
|
||||
|
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
obj: application
|
||||
arch-wiki: https://wiki.archlinux.org/title/Systemd-boot
|
||||
---
|
||||
|
||||
# Systemd Boot
|
||||
|
|
Loading…
Reference in a new issue