---
website: https://systemd.io/
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.

See also:
- [Systemd-Timers](Systemd-Timers.md)
- [systemd-boot](systemd-boot.md)

## Using Units
Units commonly include, but are not limited to, services (_.service_), mount points (_.mount_), devices (_.device_) and sockets (_.socket_).

Show Status:
```shell
systemctl status
systemctl status unit
```

List running units:
```shell
systemctl list-units
```

List failed units:
```shell
systemctl --failed
```

Start unit:
```shell
systemctl start unit
```

Stop unit:
```shell
systemctl stop unit
```

Restart unit:
```shell
systemctl restart unit
```

Reload units:
```shell
systemctl daemon-reload
```

Enable/Disable (Start at boot) unit:
```shell
systemctl enable unit
systemctl disable unit
```

Mask (forbid running) unit:
```shell
systemctl mask unit
systemctl unmask unit
```

## Power Management
Shut down and reboot the system
`systemctl reboot`

Shut down and power-off the system
`systemctl poweroff`

Suspend the system
`systemctl suspend`

Put the system into hibernation
`systemctl hibernate`

Put the system into hybrid-sleep state (or suspend-to-both)
`systemctl hybrid-sleep`

## Unit Files
Stored in:
-   `/usr/lib/systemd/system/`: units provided by installed packages
-   `/etc/systemd/system/`: units installed by the system administrator
-   `~/.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:

-   `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
```
[Unit]
Description=Description
After=network.target

[Service]
User=user
Environment="ONE=one" 'TWO=two two'
ExecStart=/bin
WorkingDirectory=/
ExecReload=/bin/sh -c "kill -HUP $MAINPID"
KillSignal=SIGTERM
TimeoutStopSec=30s
SendSIGKILL=yes
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
```

### 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.

### 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
- `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.

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.

### Other Unit Types
Systemd supports other unit types than `.service`. 
Some include:
- [Systemd-Timers](Systemd-Timers.md)
- [Systemd-Mounts](Systemd-Mounts.md)