A Quick Guide to Managing Systemd Services
Last updated: August 13th 2024
In my last article, I explored what a Systemd unit is in rather extreme detail, uncovering its structure and purpose. Today, I’ll shift gears and examine a practical example of how this directive comes to life in a real-world scenario. I’ll also cover the essentials of enabling, disabling, and masking service. Ready to get started? Let’s jump right in without further ado.
A Quick Recap
Systemd manages services through unit files, which define service behavior and configuration. These files are typically stored in /etc/systemd/system/ for user-defined services or /lib/systemd/system/ for system services. Each unit file contains directives specifying how the service should start, stop, and be managed.
Effective service management is essential for system administrators and users aiming to maintain a stable and efficient system. If you want to learn all the basics, I suggest you check out my earlier article, in which I delve deeply into these topics.
Constructing Basic Systemd Files
Let's start by constructing some basic Systemd files for common services and tools.
Systemd file for NGINX
This systemd file controls the Nginx web server, allowing it to be started, stopped, and reloaded as needed. It defines the command to execute and its dependencies.
First, open the file:
$ sudo nano /etc/systemd/system/nginx.service
The following would be the content:
[Unit] Description=A high performance web server and a reverse proxy server After=network.target [Service] Type=forking ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target
Systemd file for Apache
This systemd service file manages the Apache HTTP server, ensuring it starts, stops, and reloads properly with the system. It defines the commands to control the server and its dependencies.
Open or create the file:
$ sudo nano /etc/systemd/system/apache2.service
And add the following content:
[Unit] Description=The Apache HTTP Server After=network.target [Service] Type=notify ExecStart=/usr/sbin/apachectl -k start ExecReload=/usr/sbin/apachectl -k graceful ExecStop=/usr/sbin/apachectl -k stop PrivateTmp=true [Install] WantedBy=multi-user.target
Systemd file for MySQL
This service file is responsible for managing the MySQL database server. It specifies how to start and stop the MySQL service and ensures it restarts on failure.
Open or create the file:
$ sudo nano /etc/systemd/system/mysql.service
Add the following content:
[Unit] Description=MySQL Community Server After=network.target [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/bin/mysqld_safe Restart=on-failure [Install] WantedBy=multi-user.target
Systemd file for Redis
This service file manages the Redis in-memory data store, specifying how to start and stop the service while ensuring it runs under the correct user and group.
Open or create the file:
$ sudo nano /etc/systemd/system/redis.service
Add the following content:
[Unit] Description=Redis In-Memory Data Store After=network.target [Service] User=redis Group=redis ExecStart=/usr/bin/redis-server /etc/redis/redis.conf ExecStop=/usr/bin/redis-cli shutdown [Install] WantedBy=multi-user.target
Systemd file for SSH
This file is usually present by default in most Linux configs by default. But for information's sake, I’ll still go over it. This file manages the OpenSSH server, allowing secure remote access to the system. It defines how to start the SSH daemon and ensures it restarts if there are failures.
Open the file:
$ sudo nano /etc/systemd/system/ssh.service
It should have the following content:
[Unit] Description=OpenSSH Server After=network.target [Service] ExecStart=/usr/bin/sshd -D Restart=on-failure [Install] WantedBy=multi-user.target
Systemd file for Cron
This file is also typically included by default in most Linux configurations. However, for the sake of completeness, I'll still discuss it. This systemd service file controls the cron daemon, which is responsible for executing scheduled tasks on the system. It defines how the cron service should run.
Open the file:
$ sudo nano /etc/systemd/system/crond.service
The following should be the content:
[Unit] Description=Regular background program processing daemon [Service] ExecStart=/usr/sbin/crond -n [Install] WantedBy=multi-user.target
Systemd file for a Node.js Application
This file manages a Node.js application, specifying how to start it and ensuring it restarts on failure while running under a specified user.
Open or create the file:
$ sudo nano /etc/systemd/system/my-node-app.service
Add the following content. Ensure to make changes to it accordingly:
[Unit] Description=My Node.js Application After=network.target [Service] ExecStart=/usr/bin/node /path/to/my/app.js Restart=always User=nodeuser Environment=NODE_ENV=production [Install] WantedBy=multi-user.target
Enabling Systemd Services
When you want a service to launch automatically every time your system boots up, you need to enable it. This process tells the system to include the service in its startup routine. To make this happen, enter the following command:
$ sudo systemctl enable <service_name>
So, to enable the NGINX service from the examples above, simply run:
$ sudo systemctl enable nginx
Creating this symbolic link connects the NGINX service file to the system's startup sequence. By doing so, you're essentially telling your server to fire up NGINX whenever it boots. It's a nifty trick for making sure your web server is always ready to go without you having to manually start it each time.
Disabling Systemd Services
Disabling a service prevents it from starting automatically at boot. To disable a service, use:
$ sudo systemctl disable <service_name>
To disable the NGINX service as mentioned in the examples above, just execute:
$ sudo systemctl disable nginx
This command removes the startup link for NGINX. As a result, the web server will no longer launch automatically when the system boots. You'll need to start nginx manually when you want to use it.
Starting and Stopping Systemd Services
When you start a service, you run it immediately on your system. Stopping it halts its operation. These actions affect the current session only. When you enable a service, you set it to launch automatically at every system startup.
Disabling prevents this automatic start. Start and stop controlling the service now while enabling and disabling determine its behavior on future reboots. You can manually start or stop services using the following commands -
To start a service:
$ sudo systemctl start <service_name>
To stop a service:
$ sudo systemctl stop <service_name>
So, for the above example, these should be the right commands for the same actions:
$ sudo systemctl start nginx $ sudo systemctl stop nginx
Checking the Status of Systemd Services
To verify if a service is operating properly, you can check its status. Use this command to view the current state of a service:
$ sudo systemctl status <service_name>
For the above example, it should be:
$ sudo systemctl status nginx
When you run this command, you'll see a quick report on the service. It tells you if the service is currently active and running, stopped and inactive, or if it has encountered any failures.
Masking Systemd Services
And finally, systemd masking offers a robust method to prevent unit activation, surpassing the standard disable function. By linking a unit to /dev/null, masking renders it inert, blocking both manual and automatic starts.
This proves invaluable when managing conflicting services or permanently deactivating unnecessary units. Unlike disabling, which merely prevents automatic startup, masking ensures complete inactivation.
System administrators often employ this technique to maintain system stability and security. The process is reversible through unmasking, restoring the unit's potential for activation when needed.
To mask a service, use:
$ sudo systemctl mask <service_name>
To completely prevent the NGINX service from running, you would execute:
$ sudo systemctl mask nginx
To unmask the service, simply use:
$ sudo systemctl unmask nginx
To Wrap Up
Understanding Systemd unit files is key for managing Linux services effectively. By creating and configuring these files, you ensure services run smoothly and meet your system's needs. Learning to enable, disable, start, stop, and mask services helps maintain a stable system.
As you explore Systemd further, you'll improve your admin skills and boost server reliability. Using these practices will help you streamline your work and improve performance in your Linux setup.
Meet Aayush, a WordPress website designer with almost a decade of experience who crafts visually appealing websites and has a knack for writing engaging technology blogs. In his spare time, he enjoys illuminating the minds around him.
Related articles
-
Optimizing Network Speed on Your Webdock KVM Server
A mini article with some kernel tweaks to improve network performance on your server
Last updated: September 6th 2024
-
How to configure Crontab on Linux
In this article we detail how Crontab works and all the available options for configuration along with correct syntax and examples.
Last updated: January 4th 2024
-
How to free up disk space on an Ubuntu Nginx or Apache Web Server
This article outlines useful commands you can run on your server in order to free up disk space.
Last updated: October 16th 2023
-
How to monitor webdock server resources using Prometheus, Grafana, Node Exporter and Prometheus Alert Manager
This guide includes the step by step procedure of installing different packages like Prometheus, Grafana, Node exporter and Alert Manager.
Last updated: December 7th 2022
-
How to Disable IPv6 on Your Webdock Server
The article explain how to disable IPv6 on your Webdock server, both temporarily and permanently.
Last updated: August 13th 2024
-
Automating Initial Server Configuration with Ansible
Read our new article: Learn how to automate your cloud server configuration using Ansible.
Last updated: July 19th 2023
-
Top Tools to Install on Your Ubuntu Web Server
A list of important tools that you can install on your production Ubuntu web server
Last updated: July 19th 2023
-
How To Benchmark Your Server with YABS
A guide to do benchmarking of your server's CPU, network performance, and such using YABS.
Last updated: April 1st 2024
-
How to Benchmark PHP Performance on Your Webdock Server
Instructions for bechmarking PHP performance on your Webdock server
Last updated: August 29th 2024
-
Why don't I have the memory or disk allowance that I expect?
In this article we show why inside your instance you may see lower than expected RAM or DISK allowance available. It has all to do with units!
Last updated: November 29th 2024