The EX200 exam expects you to prove you can control and manage system services using systemd. This is the core skill for keeping a Linux server running reliably. Without understanding systemd, you cannot start, stop, or troubleshoot the services that make a server useful.
Jump to a section
A simple way to picture Managing Services with systemd
Have you ever watched a busy restaurant kitchen during dinner service and wondered how all those moving parts work together without chaos?
In a professional kitchen, the head chef is like the system administrator, and each cooking station is a service. The grill station, the salad station, the pastry station — each one is a specialised unit that performs a specific job. When the kitchen opens, the head chef doesn't wander over to the grill and manually light each burner. Instead, the chef uses a central command panel or a system of call-and-response to start the grill station, check its temperature, and ensure it's ready to cook.
Now, imagine a sous chef whose only job is to manage these stations. That sous chef is 'systemd' — the background manager that starts, stops, restarts, and monitors every station. When a station crashes (like a grill burner going out), the sous chef immediately notices, logs the failure, and might automatically relight it. If the pastry station needs to be fully reloaded with fresh dough, the sous chef runs a script to reload it. The sous chef never cooks; the sous chef just makes sure the cooking stations are doing their jobs correctly.
In a Linux system, 'services' are like these kitchen stations — programs that run in the background such as a web server or a database. 'systemd' is that dedicated sous chef: it knows how to start each service in the right order, restart it if it fails, and report its status. The head chef (you, as the sysadmin) tells systemd what to do using commands like 'systemctl', and systemd handles the actual cooking.
Every time you use a computer, you rely on programs that run in the background without you even noticing. On a Linux server, these background programs are called 'services' or 'daemons'. A web server like Apache, a database like PostgreSQL, or a logging system like rsyslog — they all run continuously in the background. In the old days of Linux, managing these services was a messy business. Different distributions used different systems: some used System V init (a collection of startup scripts), others used Upstart. There was no standard way to start, stop, or check the status of a service. This made life difficult for system administrators.
Then came systemd. 'systemd' (pronounced 'system-dee') is a software suite that provides a standardised way to manage services and other system resources. The 'd' stands for daemon, which is the technical term for a background program. systemd is now the default init system for almost all major Linux distributions, including Red Hat Enterprise Linux (RHEL) 7 and later, which is what the EX200 exam uses.
At its heart, systemd is responsible for three main tasks: starting up the system, managing services during operation, and shutting down the system cleanly. But for the EX200, you mostly need to focus on the middle part — managing services.
The primary tool you use to interact with systemd is a command called 'systemctl'. The name 'systemctl' stands for 'system control'. It is your remote control for services. With 'systemctl', you can tell a service to start, stop, restart, reload its configuration, or check if it is running.
Here are the most common 'systemctl' commands you will use:
'systemctl start servicename' — This tells systemd to start a service. But it does not make the service start automatically after a reboot.
'systemctl stop servicename' — This tells systemd to stop a service immediately.
'systemctl restart servicename' — This stops and then starts the service again. Useful after making changes to a service's configuration file.
'systemctl reload servicename' — This tells the service to reload its configuration files without fully stopping and restarting. Some services support this, some do not.
'systemctl status servicename' — This shows you the current state of a service: whether it is active (running), inactive (stopped), or failed. It also shows recent log entries.
'systemctl enable servicename' — This tells systemd to automatically start this service at boot time.
'systemctl disable servicename' — This tells systemd not to start this service at boot time.
'systemctl is-active servicename' — This returns just 'active' or 'inactive', useful for scripting.
'systemctl is-enabled servicename' — This returns 'enabled' or 'disabled', showing whether the service starts at boot.
Notice the difference between 'start' and 'enable'. 'Start' operates right now. 'Enable' operates on future boots. This distinction is crucial for the exam. A service that is 'started' but not 'enabled' will run until you reboot the server, and then it will be gone. A service that is 'enabled' but not 'started' will start automatically on the next boot, but it is not running right now. Most of the time, you do both: you start it now and enable it for the future.
systemd organises services using 'unit files'. A 'unit' is a configuration file that tells systemd how to manage a service. These unit files are stored in directories like '/etc/systemd/system/' and '/usr/lib/systemd/system/'. A typical unit file has three sections: '[Unit]' (description and dependencies), '[Service]' (how to start/stop the service), and '[Install]' (when to start at boot). You rarely need to edit these files by hand for the EX200, but knowing they exist is important.
Another essential skill is checking the 'logs' for a service. systemd collects log messages from services and stores them in a 'journal'. You can view this journal with the 'journalctl' command. For example, 'journalctl -u servicename' shows all log entries for a specific service. This is how you diagnose why a service failed to start.
Finally, systemd uses 'targets' to define system states, much like the old 'runlevels'. For example, 'multi-user.target' is the standard multi-user, non-graphical mode. 'graphical.target' adds a graphical interface. You can change the default target with 'systemctl set-default multi-user.target'. For the EX200, you will most often work with 'multi-user.target' and 'rescue.target' (a minimal recovery mode).
Identify the service name
Before you can manage a service, you must know its exact name. For example, the Apache web server is 'httpd', the SSH server is 'sshd', and the MariaDB database is 'mariadb'. Use 'systemctl list-units --type=service' to see all installed services. Getting the name wrong leads to 'Unit not found' errors.
Check current status
Run 'systemctl status servicename' to see if the service is active (running), inactive (stopped), or failed. The output includes recent log lines, the process ID (PID), and whether it is enabled. This step prevents you from restarting a service that is already running.
Start or stop the service
If the service needs to run now, type 'systemctl start servicename'. If it needs to stop, type 'systemctl stop servicename'. These commands take effect immediately but do not affect boot behaviour. Use 'systemctl restart servicename' to stop and start it in one command.
Enable or disable at boot
Run 'systemctl enable servicename' to create a symlink that starts the service at boot. Use 'systemctl disable servicename' to remove that symlink. This step is independent of the current running state. Many beginners forget this step and wonder why a service is gone after a reboot.
Reload configuration (if applicable)
If you change a service's configuration file (e.g., '/etc/httpd/conf/httpd.conf'), use 'systemctl reload servicename' to apply changes without stopping the service. Not all services support reload; if it fails, you must use 'restart'. This step avoids downtime during configuration changes.
Diagnose failures with logs
If a service fails to start or crashes, run 'journalctl -u servicename' to see the error messages. Focus on lines containing 'Failed', 'Error', or 'Cannot'. This is where you find the real cause, such as a missing file, wrong permissions, or a port conflict.
Verify the change
After any operation, run 'systemctl status servicename' again to confirm the desired state. Also check 'systemctl is-enabled servicename' to verify boot-time settings. This final step ensures you have not made a mistake and that the service is working correctly.
Imagine you are a junior system administrator for a small e-commerce company called 'ShopFast'. Your company sells widgets online. The website runs on a RHEL 9 server. One morning, your manager calls and says the website is down. Customers cannot add items to their cart. You need to fix it.
First, you connect to the server via SSH. You suspect the web server service, which is called 'httpd' (short for HTTP daemon — the Apache web server), is not running. You run the command:
'systemctl status httpd'
The output shows that 'httpd' is 'inactive (dead)'. So you try to start it:
'systemctl start httpd'
But it immediately fails. The status now says 'failed'. So you need to find out why. You check the logs:
'journalctl -u httpd -n 50'
This shows the last 50 lines of the httpd service log. You see a line that says 'Failed to listen on port 80: Address already in use'. This is a classic problem: another service is already using port 80. You need to identify that service. You can use 'ss -tulpn | grep :80' to see which process is using port 80. It turns out another instance of httpd was left running.
You kill the old process and then start httpd again. This time it works. Now you need to ensure httpd starts automatically after the next server reboot, so you run:
'systemctl enable httpd'
But wait — you also need to configure the firewall to allow web traffic. That is a separate task (using 'firewall-cmd'), but it is part of making a service functional.
Now imagine a different scenario: the database server 'mariadb' is slow. The developers ask you to reload its configuration without interrupting ongoing transactions. You run:
'systemctl reload mariadb'
This only works if the service's unit file supports 'reload'. You can check this by looking at the unit file or just trying the command. If 'reload' is not supported, you would have to use 'restart', which causes a brief interruption. Knowing which command to use shows your understanding of systemd's capabilities.
Later, you need to set up a custom service — a Python script that processes orders every minute. You create a unit file for it, place it in '/etc/systemd/system/', run 'systemctl daemon-reload' (to tell systemd to scan for new unit files), then enable and start it. This is a higher-level skill that appears on the exam.
As a sysadmin, you also monitor which services are currently running across the entire server. You use:
'systemctl list-units --type=service --state=running'
This gives you a quick overview of all active services. If a service is supposed to be running but is not, you investigate further.
In short, managing services with systemd is not just about memorising commands. It is about diagnosing real problems: preventing services from starting at boot, restarting failed services, reloading configurations safely, and understanding log output.
The EX200 exam is very practical. You do not need to write essays about systemd, but you must be able to type commands and interpret output fast. The exam is timed, so efficiency matters.
Here are the exact things the exam tests regarding systemd:
Starting, stopping, restarting, and reloading services using 'systemctl'. This is the most basic and most tested skill. Expect at least 3-4 questions where you must type the correct systemctl command for a given scenario.
Enabling and disabling services at boot. The exam loves to test the difference between 'start' and 'enable'. A common trap question: "Which command ensures the 'httpd' service starts automatically after the next reboot?" The answer is 'systemctl enable httpd', NOT 'systemctl start httpd'.
Checking service status with 'systemctl status'. You will be asked to determine if a service is active, inactive, or failed. The output of 'systemctl status' includes a coloured dot (green for active, red for failed) — be able to read it.
Viewing logs with 'journalctl'. Specifically, 'journalctl -u servicename' to filter by service. You may also need to use 'journalctl -n' to show the last N lines, or 'journalctl -f' to follow log output in real time.
Identifying services that are listening on network ports. This overlaps with the networking objectives. You may need to use 'ss' or 'netstat' to find which service is using a port, then use systemctl to manage that service.
Understanding unit files. You might be asked to find the location of a unit file or to modify a unit file to change how a service starts. Know the directories: '/usr/lib/systemd/system/' (vendor-supplied unit files) and '/etc/systemd/system/' (custom or overridden unit files).
Changing the default systemd target. The exam may ask: "Set the system to boot into multi-user.target by default." The command is 'systemctl set-default multi-user.target'.
Masking a service. 'systemctl mask servicename' links the unit file to '/dev/null', making it impossible to start the service (even manually). This is a permanent disable. Unmasking reverses it. This is a less common but possible exam topic.
Traps to watch out for:
Mistaking 'restart' for 'reload'. Reload applies configuration changes without interrupting service. Restart stops and starts, causing a brief outage. The exam will specify "without interrupting current connections" or "without downtime" — that is your clue to use 'reload'.
Using 'systemctl start' when the question asks about boot-time behaviour. Always check keywords like "after reboot" or "on startup" — that means 'enable', not 'start'.
Forgetting to run 'systemctl daemon-reload' after creating or modifying a unit file. If you edit a unit file and the exam asks why your change is not taking effect, this is the reason.
Confusing 'systemctl' with 'service' (the old command). The exam uses 'systemctl' commands. The old 'service' command might still work, but it is not the official method.
Key definitions to memorise:
'systemd': The init system and service manager.
'systemctl': The command-line tool for interacting with systemd.
'unit': A systemd resource (service, socket, target, etc.).
'journalctl': The tool for viewing the system journal (logs).
'daemon-reload': Tells systemd to reload unit files from disk.
'mask': Prevents a service from being started in any way.
'systemctl start' runs a service now; 'systemctl enable' makes it run on future boots — they are two separate commands with different purposes.
Always check 'systemctl status servicename' to see if a service is active, inactive, or failed before you try to fix it.
Use 'journalctl -u servicename' to read logs for a specific service; this is the key debugging step when a service fails.
The 'reload' command applies configuration changes without downtime; 'restart' stops and starts the service, causing a brief outage.
After creating or modifying a unit file, you must run 'systemctl daemon-reload' before systemd will recognise your changes.
A 'masked' service cannot be started at all, even with 'systemctl start', until you run 'systemctl unmask'.
The default boot target is controlled with 'systemctl set-default multi-user.target' or 'graphical.target'.
systemd is the standard init system for RHEL 7 and later; the old 'service' command is deprecated for exam purposes.
These come up on the exam all the time. Here's how to tell them apart.
'systemctl start'
Starts the service immediately, right now.
Does not affect boot-time behaviour.
The service will not start again after a reboot.
'systemctl enable'
Does not start the service right now (unless it is also started).
Creates a symlink to start the service at boot.
The service will start automatically after the next reboot.
'systemctl restart'
Stops the service completely, then starts it again.
Causes a brief interruption (downtime) for the service.
Replaces the entire process — good for major config changes.
'systemctl reload'
Sends a reload signal; the service stays running.
Zero downtime — ideal for busy live services.
Only applies configuration changes that the service supports.
'systemctl disable'
Removes the boot-time symlink only.
You can still start the service manually with 'systemctl start'.
The service stays running if it was already active.
'systemctl mask'
Links the unit file to /dev/null, preventing any start.
Even manual 'systemctl start' fails.
Used to permanently block a service from running.
Multi-user.target
Standard non-graphical, multi-user mode.
Common default target for servers.
Set with 'systemctl set-default multi-user.target'.
Graphical.target
Adds a graphical desktop environment.
Used on workstations or GUI servers.
Set with 'systemctl set-default graphical.target'.
Mistake
Running 'systemctl start httpd' makes httpd start automatically on every boot.
Correct
'systemctl start' only starts the service right now. To make it start automatically at boot, you must also run 'systemctl enable httpd'.
The words 'start' and 'enable' sound similar in everyday English, so beginners naturally assume 'start' covers both.
Mistake
If a service fails, the first thing to do is restart it with 'systemctl restart'.
Correct
First check the logs with 'journalctl -u servicename' to understand why it failed. Restarting without diagnosis can hide the root cause.
Beginners focus on fixing the symptom (service down) rather than diagnosing the cause. The exam rewards methodical debugging.
Mistake
'systemctl reload' and 'systemctl restart' do the same thing.
Correct
'reload' tells the service to re-read its configuration files without stopping, while 'restart' stops and starts the service completely, causing a brief outage.
Both commands make the service 'refresh', so beginners conflate them. The exam tests this distinction directly.
Mistake
Editing a unit file in '/usr/lib/systemd/system/' will take effect immediately.
Correct
You should never edit system unit files directly. Instead, override them using '/etc/systemd/system/' with a name like 'servicename.service.d/override.conf'. After any unit file change, run 'systemctl daemon-reload'.
Beginners do not understand the layout of unit file directories and think editing the default file is sufficient.
Mistake
Once a service is 'enabled', it starts immediately on the next boot regardless of any other system state.
Correct
systemd respects dependencies: if a required target or another service is not ready, the enabled service waits. Also, if you 'mask' a service, even enable does not make it start.
Beginners see 'enable' as a magic switch and forget that systemd manages startup order and constraints.
Mistake
'systemctl disable servicename' stops the service right now.
Correct
'disable' only removes the symlink that starts the service at boot. It does not stop the currently running service. Use 'systemctl stop' for that.
Again, the natural-language meaning of 'disable' implies immediate deactivation, but the technical meaning is boot-time only.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This means the service named 'httpd' is not installed on your system. You need to install the Apache web server package first using 'sudo dnf install httpd'. Once installed, the unit file will appear and systemctl will recognise it.
'systemctl stop' halts the service immediately — it stops running right now. 'systemctl disable' removes the instruction that starts the service at boot — it does not affect the currently running service. You often use 'stop' when you want to take a service down now, and 'disable' to prevent it from coming back after a reboot.
Use 'systemctl list-unit-files --type=service --state=enabled'. This shows every service unit file that is set to start at boot. You can also use 'systemctl list-units --type=service --state=running' to see which ones are currently active.
You must run 'sudo systemctl daemon-reload' after editing or adding any unit file. This command tells systemd to re-read all unit files from disk. Without it, systemd uses the old cached version.
'mask' creates a symlink from the unit file to /dev/null, making it impossible to start the service even manually with 'systemctl start'. 'disable' only prevents automatic start at boot — you can still start it manually. Use 'mask' to lock out a service completely.
Use 'sudo systemctl enable servicename'. This sets up the boot-time symlink but does not start the service immediately. The service will start automatically the next time the system boots.
'restart' stops the service and then starts it again — this causes a brief interruption. 'reload' sends a signal to the service telling it to re-read its configuration files while staying active. Use 'reload' when you want to apply config changes with zero downtime.
You've finished Managing Services with systemd. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?