1.7. Creating custom unit files

Procedure

1. To create a custom service, prepare the executable file with the service. The file can contain a custom-created script, or an executable delivered by a software provider. If required, prepare a PID file to hold a constant PID for the main process of the custom service. You can also include environment files to store shell variables for the service. Make sure the source script is executable (by executing the chmod a+x) and is not interactive.

2. Create a unit file in the /etc/systemd/system/ directory and make sure it has correct file permissions. Execute as root:

   # touch /etc/systemd/system/<name>.service
   
   # chmod 664 /etc/systemd/system/<name>.service

   Replace <name> with a name of the service you want to create. Note that the file does not need to be executable.

3. Open the created <name>.service file and add the service configuration options. You can use various options depending on the type of service you wish to create, see Unit file structure.

   The following is an example unit configuration for a network-related service:

   [Unit]
   Description=<service_description>
   After=network.target
   
   [Service]
   ExecStart=<path_to_executable>
   Type=forking
   PIDFile=<path_to_pidfile>
   
   [Install]
   WantedBy=default.target

   • <service_description> is an informative description that is displayed in journal log files and in the output of the systemctl status command.
   • The After setting ensures that the service is started only after the network is running. Add a space-separated list of other relevant services or targets.
   • path_to_executable stands for the path to the actual service executable.
   • Type=forking is used for daemons that make the fork system call. The main process of the service is created with the PID specified in path_to_pidfile. Find other startup types in Important [Service] section options.
   • WantedBy states the target or targets that the service should be started under. Think of these targets as a replacement of the older concept of runlevels.

4. Notify systemd that a new <name>.service file exists:

   # systemctl daemon-reload
   
   # systemctl start <name>.service

   警告

   Always execute the systemctl daemon-reload command after creating new unit files or modifying existing unit files. Otherwise, the systemctl start or systemctl enable commands could fail due to a mismatch between states of systemd and actual service unit files on disk. Note, that on systems with a large number of units this can take a long time, as the state of each unit has to be serialized and subsequently deserialized during the reload.