SystemD

**UNITS -**  The things or objects ,that systemd manages are called units, and they form the building blocks of systemd. These objects can include services or daemons, devices , file system entities such as mount point and so on. Units are named as their configuration files and the configuration files are normally stored under

**-/etc/systemd/system**

**-/lib/systemd/system or /usr/lib/systemd/system**

* **Service units** - These units types include system daemons or services. These daemons can be started, stopped, restarted, and reloaded. Example /etc/systemd/system/foobar.service
* **Sockets units**- These unitcs consists of local and network sockets that are used for IPC communication in a system. They play a very important role in the socket-based activation feature that helps reduce the interservices dependencies. Here's an example socket unit: /etc/systemd/system/foobar.socket
* **Device Units** - These allow systemd to see and use kernel devices. For example /etc/systemd/system/foobar.device
* **Mount units -** These are used for mounting and unmounting file systems. For example : /etc/systemd/system/ foobar.mount
* **Target units** - systemd uses targets instead of runlevels. Target units are used for logical grouping of units. They don't actually do anything by themselves, but instead reference other units, therby allowing the control of group of units together. Example : /etc/systemd/system/foobar.target
* **Timer units-** These units are used for triggering activation of other units based on timers. /etc/systemd/system/foobar.timer
* **Snapshot units** - These are used to save the state of the set of systemd units temporarily. /etc/systemd/system/foobar.snapshot.

systemctl list-units --type=name of unit

systemctl list-units --all --type=mount - to view all the active and inactive mount untis

systemctl list-units --all - to view all

systemctl enable/disable E.service - to enable/disable unit service to automatically start at system boot

systemd-analyze blame - analyze speed of services and system.

Some common very simple systemd startup script

```
[Unit]
Description=Clear out an old disk cache somewhere
[Service]
Type=oneshot
ExecStart=/usr/sbin/chrisbinnie-cleanup
[Install]
WantedBy=multi-user.target

```

The line showing Type=oneshot is present because you just want this unit to execute an action but without continuing to run processes afterward (remember the “daemonize” terminology from

Consider the scenario where you might only want to start a daemon once. That is the case even though it will be requested as a dependency by many different services. The “oneshot” option applies here, but you could achieve that functionality by using the RemainAfterExit=yes option

```
[Unit]
Description=Simple Oneshot And Remain Scenario
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/save-oldest-config
ExecStop=/usr/local/bin/save-ferris
[Install]
WantedBy=multi-user.target
[Unit]
Description=Notify next of kin
[Service]
Type=notify
ExecStart=/usr/sbin/notifying-next-of-kin-service
[Install]
WantedBy=multiuser.target

```

You should be aware that the service has to be able to inform systemd of its successful startup. Otherwise, it will treat it as having failed and therefore kill it off after a timeout period. There is more on this subject in the manual here (possibly distro-dependent): **sd\_notify**