How to Create a systemd Unit File Part 1
If you have made an application that needs to be controlled or managed by the init process on your system, or alternately have installed a third party application from outside of your repositories, then you are probably familiar with the creation of init scripts. For those that aren’t, these init scripts deal with the process of starting an application, recording it’s process id and then communicating with it to stop, reload or restart it among other functions. Systemd has replaced the old init processes on most modern Linux distributions now and has done away with the need for these init scripts by replacing them with unit files.
In systemd terminology, a unit is a service or resource of the computer that systemd knows how to manage. It knows how to manage these services and resources thanks to unit files that tell systemd about the unit and how to manage it. These files are stored in /lib/systemd/system and /etc/systemd/system directories. User added and edited ones usually live within /etc/systemd/system.
The unit files themselves are just plain text lists of directives in the “key=value” format, split into sections labelled using square brackets “[…]”. Section names and directives themselves are all case sensitive so you need to make sure that spelling is correct. Directives are also specific to certain sections, so units need to be declared in the right places for all to work correctly. There are a number of different things that units can define, though in this article we’ll concentrate on services.
The first section you’d declare will be your “[Unit]” section. This contains directives that help systemd understand what the unit file is for. We’ll cover some of the common ones here, but there are more available.
Description= This directive is used to provide a description for the unit.
Requires= This directive is used to provide a list of other units that this one needs to work.
Wants= This directive is similar to the above but while unit will work without the specified units it would be nice to have them.
Before= This directive is used to provide a list of units that should be started after this one.
After= This is similar to the above, but lists units that should be started before this one.
Conflicts= This directive is used to specify units that will cause problems with this one being run.
The “[Service]” section comes next, and this is used to declare information about your service.
One of the first directives in the Service section is the Type directive. This is used to inform systemd about how the service runs.
Here are the options:
dbus – this is used to notify systemd that the process will take a name on the Dbus bus.
forking – this tells systemd that the process will fork and run while the parent may stop.
idle – this informs systemd that the service won’t run until the system is idle.
notify – this is used to inform systemd that the process will notify systemd when it is running so systemd will wait for this notification.
oneshot – the program runs through once and will exit. This makes systemd wait for the process to finish before continuing. This is the default option if both a Type and ExecStart aren’t given.
simple – this service runs continuously and in a single process, this is the default option if a Type directive isn’t given but an ExecStart is given.
That’s a lot of information for one directive, but for the most part you will likely be using oneshot or simple types. We are out of time to get through the other directives, so we’ll get to those next time in part 2.