This guide explains how to create and manage a SYSTEMD service for a Python Django application using a shell script.
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:
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.
Bob’s colleague, Dave, recommends constructing the service unit file in gradual steps. Follow along with the steps below.
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:
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:
By default, services run as root. To have the service operate under the project_mercury account, include the User directive within the [Service] section:
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:
Copy
Ask AI
[Unit]Description=Python Django for Project MercuryDocumentation=http://wiki.caleston-dev.ca/reportedAfter=postgresql.service[Service]ExecStart=/bin/bash /usr/bin/project-mercury.shUser=project_mercuryRestart=on-failureRestartSec=10[Install]WantedBy=graphical.target
After updating the service unit file, reload the systemd daemon to apply the changes:
Below is the complete service unit file that fulfills all the specified requirements:
Copy
Ask AI
[Unit]Description=Python Django for Project MercuryDocumentation=http://wiki.caleston-dev.ca/reportedAfter=postgresql.service[Service]ExecStart=/bin/bash /usr/bin/project-mercury.shUser=project_mercuryRestart=on-failureRestartSec=10[Install]WantedBy=graphical.target
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.
