Configuration of systemd Units in RHEL9 Complete Guide for Beginners and Professionals
Systemd provides centralized management of various system entities. These entities handled by systemd are known as units in the parlance of systemd. The units are grouped into multiple unit types and each unit type has a specific role. There is a system of dependency among various unit types. The role of each unit type and its dependencies among them is defined in the multiple configuration files, known as unit configuration files or unit files. This post lets you understand what are unit files and how systemd units are configured. What is systemd unit file A systemd unit file is a configuration file that describes the unit and defines its role. Each unit has a unit configuration file where its role and behaviour are clearly defined. The excerpt from the book titled “RedHat Enterprise Linux for Beginners“ published by BpB clearly defines the purpose of systemd unit file: “Systemd manages the units with several unit files. A unit is defined in unit configuration file, which includes information about itself and about its role. Unit configuration file also describes how a unit is dependent on other units.” Structure of unit files Each unit file name ends with an extension, which is the same as the unit type. Let’s say, the unit name is sshd and it is of of service type. Thus, its unit file name will be sshd.service. Default unit files reside under /usr/lib/systemd/system. A unit file can have below sections:
[Unit] : This is the mandatory section in each unit file. This section contains generic information about the unit, its behaviour, and its dependencies.
[Install] : Some unit files have an [Install] section that is read during the installation or when enabling and disabling the unit on running system. Enabling the unit means that it can be started during boot time. Disabling the unit means the unit can not be started during boot time. Enabling and disabling of the unit are performed by using systemctl enable or systemctl disable commands either during installation or at run-time. Absence of [Install] section means that unit will be started by other means and not by using any systemctl commands.
[unit type] : This section is unit type-specific. The name of the section is same as the unit type. If unit file belongs to service unit type , then the section name would be [Service]. This section contains a unit type specific settings. Now, it’s time to look inside a unit file, say sshd.service.
[Unit] Description= OpenSSH server daemon Documentation=man:sshd(8) man:sshd_config(5) After=network.target sshd-keygen.target Wants=sshd-keygen.target [Service] Type=notify EnvironmentFile=-/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target Above snippet is the content of /usr/lib/systemd/system/ssshd.service. This unit file contains all the three sections. It is of service type , so it contains unit type- specific section,
[Service]. Lets understand some of the important directives that goes under each of these sections one by one : [Unit] Section: Below are some of the important directives that goes under [Unit] section: Description : .This describes the unit’s purpose and its type. Documentation : It contains the list of man pages where documentation of this unit exists. After : It lists the units that are fully started before the start of this unit. Each of these listed units, in turn, has a respective unit file which are read for the startup of respective unit. From the above snippet, it is clear that network.target and sshdkeygen.target units will fully be started before the start of sshd.service unit. Before : It lists the units that are started after this unit has started . Thus, After and Before setting determine ordering dependency among the units. This is the ordering dependency that restricts the units to start parallel. Two units having no ordering dependency can be started parallelly. Requires : It lists the units that must be activated beforehand to activate the current unit. The current unit can not function and will stop if any units listed in this directive don’t start. Wants : It lists the units that are activated before the start of the current unit. However, the current unit can still function even if any of the units listed in this directive won’t start. Thus, Requires and Wants determine requirement dependency. Requires directive imposes stronger requirement dependency while Wants directive imposes weaker requirement dependency. Unit type-specific section [Service]: Lets reprint the contents of our example unit file again: contents of sshd.service unit file Below is the list of some important directives that is specific to service unit type: Type: It specifies the type of the service. In the given snippet, Type setting is set to notify which means that the service will send the notification after it has started up. ExecStart: It lists the command that is executed when the service is started. ExecStartPre: It lists commands that are executed before the command in ExecStart is executed. ExecStartPost: It lists the commands that are executed after the command in ExecStart is executed. Restart :It determines whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. EnvironmentFile : It specifies the environment file from where the environment variables are read. RestartSec : It configures the time to sleep before restarting a service. [Install] section: The [Install] section in the given snippet contains an important directive : WantedBy : multi-user.target This directive determines that the current unit is started when the listed unit , here multi-user.target , is started. This also lets the current unit file‘s symbolic link be created under .wants directory of the unit listed under WantedBy directive. Any unit’s .wants directory resides under /etc/systemd/system. For the given example, the .wants directory of multi-user.target unit will be /etc/systemd/system/multi-user.target.wants. The symbolic link of the current unit’s file , /usr/lib/systemd/system/sshd.service will be created under this directory when the systemctl enable command is exceuted on our example unit. RequiredBy : This directive determines that the current unit must be started when the listed unit is started. This also lets the current unit file‘s symbolic link be created under .requires directory of the unit listed under the RequiredBy directive. Any unit’s .requires directory resides under /etc/systemd/system. For the given example, .requires directory of multi-user.target unit will be /etc/systemd/system/multi-user.target.requires. The symbolic link of our example unit, sshd.service will be created under this directory when systemctl enable command is executed on our example unit. WantedBy and RequiredBy have the impact of providing the dependency of type Wants= and Requires= directive. Main unit configuration files are located under /usr/lib/systemd/system. This is the default unit file. If you want to make any changes in any of the unit files, you can create drop-in directory .d inside /etc/systemd/system. It is recommended not to edit the default unit files. Say, if you want to edit sshd.service unit file, you can create a drop-in file with .conf extension under /etc/systemd/system/sshd.service.d directory and make your changes there.
This was the brief introduction of configuring systemd units. For more knowledge on systemd units and their configuration you can refer to the book titled “RedHat Enterprise Linux for Beginners” published by BpB which is available on below link: RedHat Enterprise Linux 9 for Beginners: A comprehensive guide for learning, administration, and… Today, Linux is used everywhere, which means the demand for Linux administrators is high. This book is organized to… amzn.in This book is also available on Thriftbooks.com : RedHat Enterprise Linux 9 for Beginners:… book by Geetanjali Mehra Buy a cheap copy of RedHat Enterprise Linux 9 for Beginners:… book by Geetanjali Mehra. Today, Linux is used… www.thriftbooks.com Learn Linux with Geetanjali Mehra , an experienced IT professional and co-author of a Linux-based book.
Red Hat Enterprise Linux 9 (RHEL 9) represents a modern, enterprise-grade Linux distribution designed for scalability, automation, and cloud-native environments. One of the most critical components of RHEL 9 is systemd, which acts as the system and service manager.
If you are working in DevOps, Linux administration, cloud engineering, or cybersecurity, understanding systemd unit configuration is no longer optional. It is a core skill.
This blog provides a deep dive into systemd unit configuration in RHEL 9, covering everything from fundamentals to advanced use cases, industry practices, and real-world case studies.
What is systemd in RHEL9
systemd is the init system used in RHEL 9. It replaces older systems like SysVinit and Upstart.
It is responsible for:
- Bootstrapping the system
- Managing services
- Handling dependencies
- Controlling system states
- Logging via journald
In simple terms, systemd ensures that your system boots fast, services run reliably, and dependencies are handled intelligently.
Understanding systemd Units
A unit in systemd is a resource that systemd manages.
Common Types of Units
- service units: Manage background services
- socket units: Handle IPC sockets
- target units: Represent system states
- mount units: Control mount points
- timer units: Replace cron jobs
- path units: Monitor file changes
Each unit is defined using a configuration file.
Location of Unit Files in RHEL9
Unit files are stored in different directories:
- /usr/lib/systemd/system → Default system units
- /etc/systemd/system → Custom and overridden units
- /run/systemd/system → Runtime units
Best practice is to create or modify units in /etc/systemd/system.
Structure of a systemd Unit File
A unit file has three main sections:
1. Unit Section
Defines metadata and dependencies
Example:
Description=My Custom Service
After=network.target
2. Service Section
Defines how the service behaves
Example:
ExecStart=/usr/bin/python3 app.py
Restart=always
3. Install Section
Defines how the service is enabled
Example:
WantedBy=multi-user.target
Creating a Custom systemd Service in RHEL 9
Let us walk through a real example.
Step 1: Create Service File
Create a file:
/etc/systemd/system/myapp.service
Step 2: Add Configuration
[Unit]
Description=My Python Application
After=network.target
[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=always
User=root
[Install]
WantedBy=multi-user.target
Step 3: Reload systemd
systemctl daemon-reexec
systemctl daemon-reload
Step 4: Start Service
systemctl start myapp
Step 5: Enable Service
systemctl enable myapp
Important systemctl Commands
- systemctl start service
- systemctl stop service
- systemctl restart service
- systemctl status service
- systemctl enable service
- systemctl disable service
These commands are essential for daily operations.
Dependency Management in systemd
systemd handles dependencies intelligently.
Types of Dependencies
- Requires
- Wants
- Before
- After
Example:
After=network.target
Requires=network.target
This ensures your service starts only after the network is ready.
Advanced Configuration Options
Restart Policies
Restart=always
Restart=on-failure
Restart=no
Resource Control
MemoryLimit=500M
CPUQuota=50%
Environment Variables
Environment=APP_ENV=production
Logging with systemd (journald)
Logs are managed by journald.
View Logs
journalctl -u myapp
Real-Time Logs
journalctl -u myapp -f
Logs are structured and searchable.
Timer Units in RHEL 9
Timer units replace cron jobs.
Example Timer
Create:
mybackup.timer
[Unit]
Description=Run backup daily
[Timer]
OnCalendar=daily
[Install]
WantedBy=timers.target
This allows automated scheduling.
Security Best Practices for systemd
- Use non-root users for services
- Limit permissions
- Use PrivateTmp=true
- Use ProtectSystem=full
Example:
[Service]
User=appuser
PrivateTmp=true
ProtectSystem=full
Why systemd Skills Are in High Demand
Organizations using RHEL, AWS Linux, or CentOS rely heavily on systemd.
Industries include:
- Banking and finance
- E-commerce platforms
- SaaS companies
- Government IT systems
Companies expect engineers to:
- Automate service deployment
- Handle service failures
- Optimize system performance
Case Study 1: E-Commerce Platform Downtime Reduction
A large e-commerce company in India faced frequent service crashes during peak sales.
Problem
- Services failed silently
- Manual restarts caused delays
Solution
- Implemented systemd restart policies
- Configured dependency management
- Added logging via journald
Result
- Downtime reduced by 70%
- Automated recovery improved reliability
Case Study 2: DevOps Automation in a Startup
A startup in Bengaluru used Docker but struggled with background services.
Solution
- Used systemd to manage containers
- Created custom service units
- Automated deployments
Result
- Faster deployment cycles
- Improved monitoring
Case Study 3: Training Implementation in Greater Noida
At TuxAcademy, students learning Linux administration worked on real-world systemd configurations.
Outcome
- Students deployed services on RHEL 9
- Learned debugging using journalctl
- Built production-ready skills
This hands-on approach significantly improved placement success rates.
Common Errors and Troubleshooting
Error 1: Service Fails to Start
Check:
systemctl status myapp
Error 2: Syntax Issues
Check:
systemd-analyze verify myapp.service
Error 3: Dependency Failure
Ensure:
network.target is properly defined
systemd vs Traditional Init Systems
| Feature | systemd | SysVinit |
|---|---|---|
| Boot Speed | Fast | Slow |
| Dependency Handling | Advanced | Limited |
| Logging | Integrated | External |
| Parallel Execution | Yes | No |
systemd clearly dominates in modern environments.
If you are looking to learn Linux and DevOps with practical systemd training, Tuxacademy in India offering various specialized programs.
Popular locations include:
- Greater Noida West
- Noida Sector 62
- Delhi NCR
- Gurugram
- Bengaluru
- Hyderabad
Training centers like TuxAcademy in Greater Noida provide hands-on labs, real-world case studies, and placement-focused training.
Additionally We will Provide
- systemd RHEL 9 tutorial
- Linux service management
- systemctl commands explained
- DevOps Linux training India
- RHEL 9 system administration
- systemd unit file examples
- journald logging tutorial
- Linux automation tools
Future of systemd in Cloud and DevOps
systemd is evolving rapidly.
- Integration with containers
- Cloud-native service management
- Improved security controls
- Automation and orchestration
Cloud platforms like AWS, Azure, and GCP rely on systemd in their Linux instances.
Best Practices
- Always use custom unit files in /etc/systemd/system
- Use Restart policies for reliability
- Monitor logs using journalctl
- Secure services with user restrictions
- Test configurations before deployment
Understanding systemd unit configuration in RHEL 9 is essential for anyone working in modern IT environments.
Whether you are a beginner or an experienced professional, mastering systemd will help you:
- Automate services
- Improve system reliability
- Troubleshoot faster
- Advance your DevOps career
With real-world applications, strong industry demand, and integration with cloud technologies, systemd remains one of the most valuable skills in Linux administration.
For details, click on https://alltechmantra.wordpress.com/linux-basicconcepts-and-administration/
Ready to go deeper? Explore our course catalog at TuxAcademy.org and start building skills that actually matter.
Nearby Landmarks & Localities for TuxAcademy (Greater Noida West) Offline Courses:
TuxAcademy is strategically located in the heart of Greater Noida West, making it easily accessible from several prominent residential hubs and landmarks. We are close to Gaur City, one of the largest residential townships in the region, and well-connected to Noida Extension. Our center is also conveniently accessible from Bisrakh and Techzone 4, making it ideal for students from nearby sectors. We are located near the popular Ek Murti Chowk, a key junction that connects multiple sectors and ensures smooth commuting. Additionally, students from Sector 1 Greater Noida West, Sector 16B Greater Noida West, and Crossings Republik can easily reach us. This prime location makes TuxAcademy a convenient choice for learners across Greater Noida West and nearby areas.
Resources:
To deepen your understanding and explore more career-focused programs, you can visit the following pages:
These resources will help you move from learning concepts to building a successful career.