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 /usr/bin/mycustomservice. WantedBy=multi-user.target tells systemctl enable where to create its dependency symlink; it does not start the service merely because the line exists.

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 systemd-analyze verify /etc/systemd/system/mycustomservice.service
sudo systemctl daemon-reload
sudo systemctl enable --now mycustomservice.service

--now starts it as well as enabling it for future boots. systemctl enable

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

If the user service must start at boot and continue without an interactive login, I enable lingering deliberately:

sudo loginctl enable-linger my-user
systemctl --user enable --now myuserservice.service

Lingering starts that user’s manager at boot and keeps it after logout. loginctl lingering

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

blame lists activation durations, but parallel work may not delay boot. I compare it with the dependency path:

systemd-analyze critical-chain