Hello readers, in this blog we will be looking at what are daemons and how can we create a custom daemons in our systems. Daemon is called as a type of program which quietly runs in the background rather than under the direct control of a user. It means that a daemon does not interact with the user.
Systemd
Management of daemons is done using systemd. It is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic.
Units
Systemd introduced us with the concept of systemd units. These units are represented by unit configuration files located in one of the directories listed below:
| Directory | Description |
| /usr/lib/systemd/system/ | Systemd unit files distributed with installed RPM packages. |
| /run/systemd/system/ | Systemd unit files created at run time. This directory takes precedence over the directory with installed service unit files. |
| /etc/systemd/system/ | Systemd unit files created by systemctl enable as well as unit files added for extending a service. This directory takes precedence over the directory with runtime unit files. |
We have multiple unit types available to us. The below table gives a brief description for each of them.
| Unit Type | File Extension | Description |
| Service unit | .service | A system service. |
| Target unit | .target | A group of systemd units. |
| Automount unit | .automount | A file system automount point. |
| Device unit | .device | A device file recognized by the kernel. |
| Mount unit | .mount | A file system mount point. |
| Path unit | .path | A file or directory in a file system. |
| Scope unit | .scope | An externally created process. |
| Slice unit | .slice | A group of hierarchically organized units that manage system processes. |
| Snapshot unit | .snapshot | A saved state of the systemd manager. |
| Socket unit | .socket | An inter-process communication socket. |
| Swap unit | .swap | A swap device or a swap file. |
| Timer unit | .timer | A systemd timer. |
In this blog, we will be looking at Service unit and how to use them to create daemons.
Creating Our Own Daemon
At many times we will want to create our own services for different purposes. For this blog, we will be using a Java application, packaged as a jar file and then we will make it run as a service.
Step 1: JAR File
The first step is to acquire a jar file. We have used a jar file which has implemented a few routes in it.
Step 2: Script
Secondly, we will be creating a bash script that will be running our jar file. Note that there is no problem in using the jar file directly in the unit file, but it is considered a good practice to call it from a script. It is also recommended to store our jar files and bash script in /usr/bin directory even though we can use it from any location on our systems.
#!/bin/bash
/usr/bin/java -jar <name-of-jar-file>.jarMake sure that you make this script executable before running it: chmod +x <script-name>.sh
Step 3: Units File
Now that we have created an executable script, we will be using it into make our service.
We have here a very basic .service unit file.
[Unit]
Description=A Simple Java Service
[Service]
WorkingDirectory=/usr/bin
ExecStart= /bin/bash /usr/bin/java-app.sh
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.targetIn this file, the Description tag is used to give some detail about our service when someone will want to see the status of the service.
The WorkingDirectory is used to give path of our executables.
ExecStart tag is used to execute the command when we start the service.
The Restart tag configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached.multi-user.target normally defines a system state where all network services are started up and the system will accept logins, but a local GUI is not started. This is the typical default system state for server systems, which might be rack-mounted headless systems in a remote server room.
Step 4: Starting Our Daemon Service
Let us now look at the commands which we will use to run our custom daemon.
sudo systemctl daemon-reload
# Uncomment the below line to start your service at the time of system boot
# sudo systemctl enable <name-of-service>.service
sudo systemctl start <name-of-service>
# OR
# sudo service <name-of-service> start
sudo systemctl status <name-of-service>
# OR
# sudo service <name-of-service> statusConclusion
In this blog, we have looked how to make custom daemons and check their status as well. Also, we observed that it is fairly easy to make these daemons and use them. We hope that everyone is now comfortable enough to make daemons on their own.
References:
https://dzone.com/articles/run-your-java-application-as-a-service-on-ubuntu
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd