If you can't reliably start, stop, or check the health of a service on a Linux server, you'll fail the LFCS exam on objective 6.1 — and worse, you'll bring down a production app at work. This chapter teaches you how to manage services using systemd, the modern system that controls nearly every Linux distribution today, so you can keep your applications running and pass the exam the first time.
Jump to a section
A simple way to picture systemd Service Management and Troubleshooting
A busy restaurant kitchen on a Friday night.
The head chef is the systemd init system. The different dishes being cooked are the system services — the web server, the database, the SSH daemon. The head chef doesn't cook each dish from scratch every time. Instead, they have a set of standardised recipe cards (unit files) that describe exactly how to prepare each dish: what ingredients it needs, what other dishes must be ready before it can be started (dependencies), and how to tell if a dish is burning (service failure).
When a customer orders a steak, the head chef doesn't fry it themselves. They tell the grill chef (a service unit) to start cooking. If the grill chef suddenly walks out (service crash), the head chef sees the grill is cold and empty. They can check the recipe card to see why the grill failed — maybe the gas line was turned off (a missing dependency). The head chef can immediately restart the grill (systemctl restart) or put it on a timer to restart automatically after a short break (Restart=always).
If the fryer is taking too long to heat up (service stuck in 'starting' state), the head chef can look at the kitchen timeline (journalctl) to see exactly when the fryer was turned on and what messages it logged. They can also ask the fryer for its current status — "Are you on fire?" (systemctl status). The head chef's entire job is to make sure every station in the kitchen starts in the right order, keeps running, and if something goes wrong, it gets fixed or replaced quickly so the customers (users) never notice the chaos.
Let's start with the big picture. Before systemd, Linux used older init systems like System V (SysV) or Upstart. These were fine but had problems: they started services one at a time in a strict order, which was slow. They also didn't have a standard way to track service health, restart a crashed service automatically, or easily see what was happening when a service failed.
systemd (short for 'system daemon') was created to solve all that. It is the first process that runs on a modern Linux system (process ID 1). Every other process is a child of systemd. It manages services, which are background programs that keep running and provide functionality — for example, a web server (httpd or nginx), a database (mariadb, postgresql), or a file-sharing service (smb).
The core unit of systemd is called a 'unit'. A unit can represent a service, a mount point, a device, a socket, a timer, and more. The most common unit type is the '.service' unit. Each unit is defined by a 'unit file', a plain-text configuration file usually stored in /etc/systemd/system/ (for admin-created units) or /lib/systemd/system/ (for distribution-provided units). The unit file tells systemd:
What command to run (ExecStart)
What command to run when stopping (ExecStop)
What dependencies must be started before this unit (Requires, Wants, After)
How to restart the service if it fails (Restart=on-failure, Restart=always)
The service's description and documentation
Let's look at a real example. The SSH server runs as a service called 'sshd.service'. When you boot your Linux machine, systemd reads the sshd.service unit file, sees that it requires networking (network.target), and waits for networking to be ready. Then systemd runs the SSH daemon command. If the SSH daemon crashes, systemd knows because it receives a notification (cgroups help track child processes). If Restart=on-failure is set, systemd will launch the SSH daemon again automatically.
You interact with systemd using the 'systemctl' command. Here are the most common actions:
systemctl start servicename.service — starts the service immediately
systemctl stop servicename.service — stops the service
systemctl restart servicename.service — stops then starts the service
systemctl status servicename.service — shows current state, recent log entries, and whether the service is running
systemctl enable servicename.service — makes the service start automatically at boot
systemctl disable servicename.service — prevents the service from starting at boot
systemctl is-active servicename.service — returns 'active' or 'inactive'
systemctl is-enabled servicename.service — returns 'enabled' or 'disabled'
systemctl list-units --type=service — lists all loaded services
Not all services are meant to run continuously. Some are 'oneshot' services that run a single command and exit. Others are 'forking' services where the main process spawns child processes and the parent exits.
If a service fails to start, you need to investigate. Logs are stored by 'journald', systemd's own logging system. You view logs with 'journalctl':
journalctl -u servicename.service — shows logs for that specific service
journalctl -xe — shows recent logs and hints about errors
journalctl -f — follows new log entries live (like tail -f)
If a service won't start, common causes include:
A missing or mistyped path in the unit file's ExecStart line
Permissions problems (the service user can't access a file)
Port already in use by another service
A dependency (like a database) that hasn't started yet
The service binary itself is not installed
systemd also introduces the concept of 'targets'. A target is a group of units that should be started together to reach a certain system state, similar to runlevels in SysV init. For example:
multi-user.target — normal multi-user mode (no graphical interface)
graphical.target — multi-user plus a display manager
rescue.target — single-user mode for troubleshooting
emergency.target — minimal environment to repair a broken system
You can change the default target with 'systemctl set-default' or switch to a different target at boot by editing the kernel command line.
Finally, systemd handles dependencies intelligently. If service A requires service B, and service B fails to start, systemd will not start service A. You can also use 'Wants' (weaker than Requires) where service A will start even if service B fails. The 'After' directive controls ordering: service A will start after service B, but they are not necessarily dependent on each other.
Understanding these basics — units, unit files, systemctl, journalctl, targets — gives you full control over service management.
Identify the service name
You need the exact name of the service you want to manage. Common names: sshd.service, httpd.service, nginx.service, mariadb.service, crond.service. Use systemctl list-units --type=service to see all loaded services if unsure.
Check the service status
Run systemctl status servicename.service. This tells you if the service is active (running), inactive (stopped), failed (crashed), or in an activating/deactivating transition. It also shows recent log entries and the service's unit file location.
Start or stop the service
Use systemctl start servicename.service to start it, systemctl stop servicename.service to stop it. If the service fails to start, systemctl status will show an error, but you need step 4 to see the full reason.
View detailed logs
Run journalctl -u servicename.service to see the full log history for that service. For live troubleshooting, run journalctl -fu servicename.service to follow new entries. Look for error messages like 'Permission denied', 'Address already in use', or 'Unit not found'.
Fix the issue and reload
Edit the unit file if needed (use /etc/systemd/system/, not /lib/). Then run systemctl daemon-reload to make systemd reread the unit file. After that, try systemctl start again. If the problem was a dependency, check systemctl list-dependencies servicename.service to see which dependency failed.
Imagine you are the sole IT administrator for a small e-commerce company running on a single Linux server. The server hosts a web server (nginx), a PHP application managing the online store, a MariaDB database, and a Redis cache. Every minute of downtime means lost sales.
On a Tuesday morning, the CEO calls you: 'The website is down. Fix it now.' You SSH into the server and run the following commands:
The LFCS exam (objective 6.1) tests your ability to manage services using systemd in a command-line environment. Here is exactly what you need to know.
First, memorise the core systemctl commands and their exact syntax. The exam will give you scenarios like: 'A user reports that the HTTP service is not running. What command should you use to check its status?' The correct answer is 'systemctl status httpd.service' (or nginx.service, depending on the distro). Traps include:
Using 'service httpd status' — that's the old SysV syntax. LFCS expects systemctl.
Omitting the '.service' suffix. While systemctl often works without it, the exam expects you to include it.
Confusing 'enable' with 'start'. Enable sets automatic start at boot; start runs it now. The exam loves to ask: 'Which command ensures the service starts automatically after a reboot?' Answer: systemctl enable.
Second, understand unit file dependencies. You may be asked: 'Service A requires service B to be running. Which directive should you add to the unit file?' The answer is Requires=serviceB.service. But they might also ask about After= to ensure ordering. The trap is thinking Requires alone ensures start order — it doesn't. You need After= for that.
Third, know journalctl filtering. Questions often ask: 'How do you view only the logs for the sshd service?' The answer: journalctl -u sshd.service. Traps include using journalctl -f (which follows logs, not filter) or journalctl -p (priority filter).
Fourth, understand service restart behaviour. The exam tests the Restart= directive options:
Restart=always — always restart regardless of exit code
Restart=on-failure — restart only if the service exits with a non-zero code or is killed by a signal
Restart=on-abort — restart only when killed by a signal like SIGKILL
Restart=no — never restart
A typical question: 'A web server crashes due to a memory error. The administrator wants it to restart automatically only when it crashes unexpectedly. Which Restart setting?' Answer: Restart=on-failure. Trap: choosing Restart=always will restart even when manually stopped.
Fifth, know how to override unit files. The exam may ask: 'An administrator needs to change a service's restart policy without editing the original unit file. What should they do?' Answer: create a drop-in file in /etc/systemd/system/servicename.service.d/override.conf. Then run systemctl daemon-reload.
Sixth, understand targets and runlevels:
The default target is stored as a symlink at /etc/systemd/system/default.target
systemctl get-default returns the current default target
systemctl set-default multi-user.target changes it
systemctl isolate multi-user.target switches to that target right now
The exam might ask: 'Which target is equivalent to runlevel 3?' Answer: multi-user.target. Trap: graphical.target is runlevel 5, rescue.target is runlevel 1.
Finally, know how to troubleshoot a service that failed to start. The exam expects this sequence:
systemctl status servicename.service — check if it's running
journalctl -u servicename.service — view logs for errors
systemctl daemon-reload — if you edited unit files
Check systemctl list-dependencies servicename.service — see if a dependency failed
Traps include checking logs without filtering by unit (too much noise), or forgetting to run daemon-reload after editing unit files.
systemd is process ID 1 and manages all services as units defined in unit files.
Use systemctl start, stop, restart, and status to control services immediately.
Use systemctl enable and disable to control whether a service starts at boot.
Always run systemctl daemon-reload after editing any unit file or creating a drop-in file.
View logs for a specific service with journalctl -u servicename.service.
The Restart= directive in a unit file controls automatic restart behaviour on failure.
Targets like multi-user.target group services into system states, replacing old runlevels.
Override original unit files by creating drop-in files in /etc/systemd/system/servicename.service.d/.
These come up on the exam all the time. Here's how to tell them apart.
systemctl start
Starts the service immediately
Does not affect boot-time behaviour
Requires the service to be installed and loaded
systemctl enable
Configures service to start at boot
Does not start the service right now
Creates symlinks in /etc/systemd/system/*.wants/
Restart=always
Restarts even if the service exits with code 0
Restarts even if manually stopped via systemctl stop
Used for critical services that must always run
Restart=on-failure
Restarts only on non-zero exit code or signal
Does not restart if manually stopped
Used for services that may exit cleanly under normal conditions
Requires
Strong dependency: service fails if dependency fails
Dependency must start before the service
Creates a failure propagation chain
Wants
Weak dependency: service starts anyway
Dependency starts in parallel if possible
No failure propagation
/etc/systemd/system/
Admin-created or customised unit files
Not overwritten by package updates
Takes precedence over /lib/
/lib/systemd/system/
Distribution-provided unit files
Overwritten by package updates (dnf update, apt upgrade)
System default location
Mistake
If I run systemctl start, the service will automatically start on every boot.
Correct
systemctl start only starts the service right now. To make it start on boot, you must run systemctl enable separately.
Beginners assume 'start' implies 'enable' because in other contexts, starting something means making it available permanently.
Mistake
systemctl restart is the same as running systemctl stop then systemctl start manually.
Correct
It is functionally the same for most services, but systemctl restart is atomic — it sends the stop signal and then the start signal in one command. However, some services may not handle this well if they need cleanup between stop and start.
This misconception stems from thinking of commands as independent scripts, not realising systemd manages the state transition internally.
Mistake
All services need to be running all the time.
Correct
Many services are oneshot (run once and exit), socket-activated (start only when a connection arrives), or timer-activated (run on a schedule). They don't stay resident in memory.
People think of 'service' as a long-running background process, but systemd defines services much more broadly.
Mistake
If I edit a unit file in /lib/systemd/system/, my changes will persist after system updates.
Correct
Files in /lib/systemd/system/ are managed by the package manager and will be overwritten on updates. Use /etc/systemd/system/ to override or create custom unit files.
Beginners don't realise that /lib is for distribution-provided files, while /etc is for local configuration. It's a common Linux filesystem hierarchy mistake.
Mistake
A service that fails to start will always show a clear error message in systemctl status.
Correct
systemctl status shows the last few log lines, but often the real error is several lines earlier or requires looking at journalctl with higher verbosity. The status output truncates logs.
The status output looks complete, so beginners don't think to dig deeper into journalctl for the full log.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
systemctl start runs the service right now. systemctl enable configures the service to start automatically when the system boots. You usually need both: enable once, start every time you need it.
The service name is misspelled, or the package providing the service is not installed. Double-check the exact name with systemctl list-units --type=service or install the package (e.g., sudo dnf install httpd).
Edit the unit file and add Restart=on-failure or Restart=always under the [Service] section. Then run systemctl daemon-reload and systemctl restart servicename.service.
It tells systemd to re-read all unit files from disk. You must run it after editing a unit file or creating a drop-in file, otherwise systemd will still use the old configuration.
journalctl may add timestamps, hostnames, and other metadata before the actual log message. Use journalctl -u servicename.service -o cat to show only the message text without metadata.
Requires means the dependency must start successfully for the service to start. If it fails, the service will not start. Wants means the dependency is desired but not required — the service will start even if the dependency fails.
You've finished systemd Service Management and Troubleshooting. Continue through the LFCS study guide to build a complete picture of the exam.
Done with this chapter?