In this guide, we detail how to manage services with SYSTEMD by building a service unit from scratch. We will utilize essential SYSTEMD utilities—specifically, systemctl and journalctl—and conclude with a hands-on lab exercise. Bob’s requirements for the service are as follows:Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
- A shell script named project-mercury.sh located in /usr/bin must execute as a background service.
- The service should be enabled to start automatically during boot.
- The script launches a Python Django application that depends on a PostgreSQL database; therefore, PostgreSQL must be running prior to the application’s start.
- The service must run under a pre-created account called project_mercury rather than the default root user.
- In case of application failure, the service should restart automatically, waiting 10 seconds between attempts.
- The service must not restart automatically if it is manually stopped by an administrator.
- All service events—including start, stop, and errors—must be logged for later analysis.
- The service should adhere to the graphical.target since Bob’s system defaults to a graphical environment.
Step 1. Creating the Basic Service Unit
Begin by defining a basic service unit file named project-mercury.service under the /etc/systemd/system directory. Initially, the unit file only needs to execute the command in the background using /bin/bash because project-mercury.sh is a Bash script. Below is the minimal service unit definition:Step 2. Enabling the Service on Boot
To automate the start of the service during boot, add an [Install] section to the service unit file. The WantedBy directive ties the service to the graphical target, which corresponds to the current runlevel. Update your service unit file as follows:Step 3. Running the Service Under a Specific User
By default, services run as root. To have the service operate under the project_mercury account, include the User directive within the [Service] section:Using a dedicated service account improves security by limiting the permissions available to the service.
Step 4. Configuring Automatic Restarts
Configure the service to restart automatically if it fails. Use the Restart directive set to on-failure and specify a 10-second delay between restart attempts using RestartSec:Step 5. Defining a Dependency on the PostgreSQL Service
Since the Python Django application depends on a PostgreSQL database, ensure that project-mercury.service starts only after PostgreSQL is active. To achieve this, add a [Unit] section that includes a description, a documentation URL, and the After directive to express the dependency:Final Service Unit File
Below is the complete service unit file that fulfills all the specified requirements:Bob intends to replicate these steps on the development server, ensuring the Python Django application and PostgreSQL database are configured reliably and efficiently with SYSTEMD.