How to Create a systemd Unit File Part 2
In part 1 of this tutorial, we looked at what systemd unit files are and how they are used to control services on a Linux system. We ended while looking at the “[Service]” section of the file after describing the Type directive. We’ll jump straight into it next by looking at some of the other core directives for use with the “[Service]” section. Note that the directives are all optional and you only need to specify the ones you need.
ExecStart= This directive is used to provide the command that should be executed when starting the service.
ExecStartPre= This directive is used to specify commands that may need to be executed before starting the service.
ExecStartPost= This directive is much the same as the above, but for commands to be executed once the service has started.
ExecStop= This directive is used to provide a command to stop the service, if it isn’t specified then the process will just be killed.
ExecStopPost= This directive describes commands to be run once the service is stopped.
Restart= This directive is used if systemd is to automatically restart the service if it stops. This has options such as “always”, “on-success”, “on-failure” and more. Systemd will choose whether to restart the service based on how it stopped and the relation to these options.
RestartSec= This is used to specify the number of seconds after the service stops to restart it if systemd is to restart it.
ExecReload= This can be used to specify a command to use to reload the service’s configuration should it support it.
TimeoutSec= The number of seconds that systemd should wait after issuing the ExecStop command prior to assuming the service isn’t responding and killing it.
The end of a unit file will often be the “[Install]” section which is used to define information relating to how the unit should be enabled. If the unit isn’t going to be enabled then this section can be left out.
Let’s look over some of the directives:
WantedBy= This directive is used to specify services that this unit should be started before. This can be a specific unit, or a run level target such as “multi-user.target” which means that the service will need to be started at the last stage before users can log in.
RequiredBy= Much like the above but implies that the units specified here won’t run without this unit running.
Aliases= Other unit names by which this unit can be handled.
Also= Allows specifying other units that should be started/stopped when this unit is started or stopped.
By this point you should have all the information you need to put together a unit file for you to manage your own service. The great thing about the unit files is that it can be set up using an easy and clear to understand system, unlike the traditional sysvinit system that required the user to write scripts to manage services. There are a lot of directives that can be used in a unit file, and a full listing can be found in the systemd man pages. In fact, the list is large, so you can spend quite a long time looking through the various options.
A good way to get a feel for how these directives are used is to have a look through a number of the unit files for the services you already have installed on your system. These will be stored in the /etc/systemd/system/ or /lib/systemd/system/ directory and the files you are looking for are the ones with the “.service” file extension. You’ll probably recognize a number of the file names such as sshd, apache2 or httpd (depending on your Linux distribution), etc. So, checking out services similar to the one that you want to set up will give you a good idea of the layout of the file and the directives you’ll want to look at using.