Creating Custom Units and Managing User-specific Units

Creating custom systemd service units and managing user-specific systemd units. Both of these skills will give you greater flexibility and control over your system’s services and processes.

Creating Custom systemd Service Units

A systemd service unit is a unit file that defines a process or group of processes managed by systemd. Creating a custom service unit allows you to take any script or program and turn it into a systemd service that can be started, stopped, and automatically restarted, just like any other service on your system.

Here’s a simple example of a service unit file:

[Unit]
Description=My Custom Service

[Service]
ExecStart=/usr/bin/mycustomservice

[Install]
WantedBy=multi-user.target

This file defines a service named “My Custom Service”, which runs the /usr/bin/mycustomservice command. The [Install] section tells systemd to start this service as part of the multi-user.target, which is the standard operating mode for most Linux systems.

You can create a new service unit file by creating a new file ending in .service in the /etc/systemd/system/ directory, then adding your service definition to that file:

sudo nano /etc/systemd/system/mycustomservice.service

Once your service unit file is created and saved, you can enable your new service so it will start on boot:

sudo systemctl enable mycustomservice.service

Managing User-specific systemd Units

By default, systemd units are system-wide, meaning they operate independently of individual user sessions. However, systemd also supports user-specific units, which are tied to a particular user’s session and can be managed by that user.

User-specific units are stored in the ~/.config/systemd/user/ directory and can be managed using the systemctl --user command:

systemctl --user status myuserservice.service

You can create and manage user-specific units in the same way as system-wide units, with the only differences being the storage location and the --user option when using systemctl.

Understanding and Using Systemd Targets

Think of a systemd target as a more flexible version of the old SysV runlevels. They provide a way to boot into different modes, like “graphical”, “multi-user”, “rescue”, and more. It’s a neat and granular way of controlling what services are loaded at boot.

You can view the default target with:

systemctl get-default

And you can change the default target using:

sudo systemctl set-default graphical.target

Logging with journalctl

The journalctl tool allows you to query and display messages from the systemd journal. It’s a powerful tool for analyzing system events. You can, for instance, display all messages since the last boot with:

journalctl -b

Or display all messages for a particular unit:

journalctl -u myservice

3. Use systemd-analyze for Boot Performance

systemd-analyze can show you detailed information about your boot process, down to the millisecond. Use it to find out which units are slowing down your boot process:

systemd-analyze blame