How to create a new systemd service on Linux

systemd is a service manager for many well-known Linux distributions. Service is a unit of a program that normally runs in the background. In essence, the services will automatically run as soon as the system boots and can operate without supervision.

If you need to create a task or program that automatically starts executing every time you boot or reboot your system, you might consider creating a new service. Learn how to create a new, custom systemd service on Linux.

Step 1: Create the service file

There are several steps required to create a new systemd service file. The first thing is to create a unit file for the service. Before creating a service file, you must understand its structure.

Let's study the service file by getting a real, working service file from your Linux system. Below you can see the service file for the vmtools service daemon.

 

This particular service may not be available on your system unless you are also running Linux on VMware with VMware tools installed. The service in question is not important because all services, or rather unit service files, have the same basic structure with some customizations required.

All systemd service files must have 3 sections: [Service], [Unit] and [Install] and a few parameters in each section. Here's what each section contains and why they're important:

1. Unit

The Unit section includes important metadata such as the service's description and dependencies. It has 3 parameters: Description, Before and After. Likewise, the Description parameter provides some context of the service and its functionality.

The Before and After parameters define what conditions must be met for the service to execute. For example, if you are starting a web server service, you will want it to start only after the network service comes online. So you will set the value of the After parameter for the network service.

2. Service

The Service section contains two required parameters: ExecStart, Type and a few other optional parameters like ExecReload, etc.

ExecStart defines the command to be executed when the service starts, while the Type parameter defines the type of process that will appear.

3. Install

This section and its data are called whenever you enable or disable the service using the systemctl command.

It has a few parameters. One of the popular and necessary ones is WantedBy. The WantedBy parameter defines the target units to start whenever the service is enabled. The default value is multi-user.target.

Note : The parameters mentioned here are not the only ones you can set in the unit. You can get the full list of parameters from the official systemd.exec documentation or by typing man systemd.exec in a terminal.

The systemd unit service file always ends with the ".service" extension and must be stored in the /etc/systemd/system/ directory. Create the service file with touch command with elevated privileges by prefixing it with the sudo command:

 

sudo touch /etc/systemd/system/.service 

Now that you have created the service file, let's start filling in the syntax needed to make the service valid and working.

Step 2: Configure the service file

You will create a sample service that executes Nmap that scans the ports on the machine and saves the output in a file every 30 seconds. To achieve this task, here is how the unit service file should be structured:

[Unit] Description=Demonstration of custom nmap service. After=network.target [Service] Type=simple User=root ExecStart=/usr/bin/nmap -sS -O -oN /home//results.txt localhost Restart=always RestartSec=30 [Install] WantedBy=multi-user.target

Although the mentioned parameters have been explained before, find out how they affect the newly created service and also explore the new parameters introduced in this section: Restart, RestartSec and User .

Here is the meaning of the parameters in each section:

1. Description : Human-readable text that describes the functionality of the service.
2. After=network.target : Tells systemd that this service depends on network.target and should only start after the network.target service has been started. Note that After is not used to establish any direct dependencies, it only acts as a trigger.
3. Type=simple : There are many types of services. However, the service in this demo is a regular process. You can find all the different values ​​for this on the official documentation page linked earlier.
4. Restart=always : This means that whenever the service exits, it will always restart.
5. RestartSec=30 : This sets the interval between each service start to 30 seconds.
6. User=root : This specifies that the service will run as user. In this case, this is the right step because Nmap will not be able to run without root privileges.
7. ExecStart : This command holds the absolute path to the program to be executed along with all required flags or arguments required for the program to function properly.
8. WantedBy=multi-user.target : This parameter in the service file specifies which target to include or "want" the service. When a service is included in a target, it means that the service will start when the system reaches that target during boot. In this case, the service will start when the system enters multi-user mode. Multi-user mode is a state in which the system is fully booted, allowing multiple users to log in and use the system.

 

Step 3: Activate and start the service

Now that you have created the unit file, the only steps left are to enable and run the service. You can enable and start your service with the systemctl command.

Here's how to use systemctl to enable, start, and check the status of your service:

sudo systemctl enable .service sudo systemctl start .service sudo systemctl status .service

Now your custom service will be up and running! In this case, you will see that the Nmap scan runs every 30 seconds and the output is stored in the results.txt file in the home directory.