jmarya/knowledge
jmarya/knowledge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

remove non ascii whitespaces

Browse source
This commit is contained in:
JMARyA 2024-01-17 09:44:04 +01:00
parent 598a10bc28
commit 5a6d6c4d13
Signed by: jmarya
GPG key ID: 901B2ADDF27C2263
117 changed files with 1928 additions and 1928 deletions
Download patch file Download diff file Expand all files Collapse all files

44
technology/linux/systemd/Systemd.md
View file

@ -34,12 +34,12 @@ systemctl --failed
Start unit:
```shell
systemctl start unit
systemctl start unit
```
Stop unit:
```shell
systemctl stop unit
systemctl stop unit
```
Restart unit:
@ -54,14 +54,14 @@ systemctl daemon-reload
Enable/Disable (Start at boot) unit:
```shell
systemctl enable unit
systemctl disable unit
systemctl enable unit
systemctl disable unit
```
Mask (forbid running) unit:
```shell
systemctl mask unit
systemctl unmask unit
systemctl mask unit
systemctl unmask unit
```
## Power Management
@ -87,14 +87,14 @@ Stored in:
- `~/.config/systemd/user/`: units used by local users
### Service types
There are several different start-up types to consider when writing a custom service file. This is set with the `Type=` parameter in the `[Service]` section:
There are several different start-up types to consider when writing a custom service file. This is set with the `Type=` parameter in the `[Service]` section:
- `Type=simple` (default): _systemd_ considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
- `Type=forking`: _systemd_ considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify `PIDFile=` as well so _systemd_ can keep track of the main process.
- `Type=oneshot`: this is useful for scripts that do a single job and then exit. You may want to set `RemainAfterExit=yes` as well so that _systemd_ still considers the service as active after the process has exited.
- `Type=notify`: identical to `Type=simple`, but with the stipulation that the daemon will send a signal to _systemd_ when it is ready. The reference implementation for this notification is provided by _libsystemd-daemon.so_.
- `Type=dbus`: the service is considered ready when the specified `BusName` appears on DBus's system bus.
- `Type=idle`: _systemd_ will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to `Type=simple`.
- `Type=simple` (default): _systemd_ considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
- `Type=forking`: _systemd_ considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify `PIDFile=` as well so _systemd_ can keep track of the main process.
- `Type=oneshot`: this is useful for scripts that do a single job and then exit. You may want to set `RemainAfterExit=yes` as well so that _systemd_ still considers the service as active after the process has exited.
- `Type=notify`: identical to `Type=simple`, but with the stipulation that the daemon will send a signal to _systemd_ when it is ready. The reference implementation for this notification is provided by _libsystemd-daemon.so_.
- `Type=dbus`: the service is considered ready when the specified `BusName` appears on DBus's system bus.
- `Type=idle`: _systemd_ will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to `Type=simple`.
#### Example
```
@ -117,32 +117,32 @@ LimitNOFILE=4096
WantedBy=multi-user.target
```
### The `[Unit]` section
### The `[Unit]` section
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.
- `Before`: Start current service before specified service. This too, like `After`, includes targets or other services.
### The `[Service]` section
### 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`.
- `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
### The `[Install]` section
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.
### The `[Install]` section
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`.