acytoo

Add systemd servic, and set start on boot

The most commonly used locations for loading systemd files are

  • units installed by softwares /usr/lib/systemd/system/ or /lib/systemd/system/

  • units installed by users /etc/systemd/system/

We can use man systemd.unit, man systemd.service commands to get some basic understanding about systemd.

A systemd unit could be one of the following type: .service, .socket, .device, .mount, .automount, .swap, .target, .path, .timer, .slice, .scope

Let's create a systemd service named ylstart.service

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

With following content

[Unit]
Description=A service
Requires=display-manager.service
After=display-manager.service

[Service]
ExecStart=/home/acytoo/.bin/boot-on-start.sh
Type=simple

[Install]
WantedBy=multi-user.target

Above service will execute script in /home/acytoo/.bin/boot-on-start.sh each time the system boots once enabled.

Let's skip the easy-understanding parameters and focus on the hard ones.

#Requires, Wants, Before, After

In systemd, dependencies between units can be defined in the unit files using the Requires, Wants, Before, and After options in the [Unit] section.

Requires= and After= specify that unit A requires unit B to be running before A is started. This creates a hard dependency between the two units, and if unit B fails, unit A will also be stopped.

Wants= and After= specify an optional dependency between unit A and unit B. This means that unit A will start regardless of whether unit B is running or not, but if unit B is available, it will be started before unit A.

It's important to note that if After= is not specified, the two units will be started in parallel, regardless of whether Requires= or Wants= is used.

Additionally you can use Before= to specify the order in which the unit should be stopped.

#Type

The Type parameter in the [Service] section of a systemd service file is used to specify the start-up type of the service.

There are several different start-up types that can be used, including:

  • simple: This is the default start-up type, and is used for most services. It assumes that the service can start immediately, and can be controlled with the standard start, stop, and reload commands.

  • forking: This start-up type is used for services that fork multiple processes. The service is considered to be started when the first process is forked, and stopped when the main process exits.

  • oneshot: This start-up type is used for services that perform a specific task and then exit. The service is considered to be started when the process is started, and stopped when the process exits. You cat set RemainAfterExit=yes so that systemd still considers the service as active after the process has exited.

  • notify: This start-up type is similar to simple, but includes an additional mechanism for notifying systemd when the service has fully started. This is useful for services that start quickly, but may take longer to initialize.

  • dbus: This start-up type is used for services that are activated over D-Bus.

  • idle: Similar to sinple, except this start-up type is started after all other normal services are up and running.

#WantedBy

The WantedBy option in the [Install] section of a systemd service file is used to specify the target units that the service should be automatically started with.

For example, if you want a service to be automatically started when the system enters the graphical target (i.e. when the GUI is loaded), you would add the line WantedBy=graphical.target in the [Install] section of the service file.

When a service is installed with systemctl enable command, its symlinks will be created in the multi-user.target.wants/, graphical.target.wants/, ... directory, depending on the WantedBy field in the service file.

You can also specify multiple targets by separating them with a space.

Now let's make our script start on boot.

sudo systemctl enable ylstart.service --now

#Reference

https://wiki.archlinux.org/index.php/systemd

https://wiki.archlinux.org/index.php/systemd#Writing_unit_files

See Also: