systemd targets & dependencies.
A unit. A dependency. A target. How those three concepts let systemd start a hundred services in the right order, in parallel where it can. Pace through the model and the boot graph. Maps to RH134 service-management objectives.
systemd targets and dependencies explained with animations. Units, Requires vs Wants vs After vs Before, target nesting, the boot graph, systemctl isolate, and default.target. Covers the RHCSA EX200 exam objectives on systemd service management.systemd is a graph engine. Every service is a node; every dependency is an edge. Targets are special nodes that bundle other nodes under a name. Booting is just "activate default.target and chase the edges".
- ·Starting/stopping a service with systemctl
- ·Reading basic Linux logs (journalctl)
- ·What 'a process' is (PID, foreground/background)
Read a unit file, distinguish the four dependency directives, and use systemctl isolate to switch system state without rebooting.
pace: 10 minutes
A unit file — the building block
Everything systemd manages is called a 'unit'. The most common type is a service — like nginx or sshd — but there are also timers (scheduled tasks), sockets, mounts, and the 'target' units you'll meet in step 3. Every unit is described by a small text file in INI format with up to three sections: [Unit] for metadata + what it depends on, [Service] for how to run it, [Install] for what 'enabling' attaches it to.
$systemctl cat nginx.service$systemctl status nginx.service$systemctl show nginx.serviceA target isn't something that runs — it's a label for a state. The state is "all these units are active". That's why isolate works the way it does: it says "make this state the truth" and systemd brings up what's needed, stops what isn't.
$systemctl status UNIT$systemctl start / stop / restart UNIT$systemctl enable / disable UNIT$systemctl enable --now UNIT$systemctl mask UNIT$systemctl daemon-reload$systemctl cat UNIT$systemctl edit UNIT$systemctl list-units --type=service$systemctl list-units --failed$systemctl list-dependencies UNIT$systemctl get-default / set-default TARGET$systemctl isolate TARGET$journalctl -u UNIT$journalctl -u UNIT -f$systemd-analyze blameservice-a depends on service-b. If service-b fails to start, service-a should NOT start. Which directive do you use?
What's the difference between After= and Requires=?
You're on a GUI system. You want to drop to a text-only console without rebooting. Which command?
Your service is enabled but won't start at boot. Best first command?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
Read this lesson as text5 chapters · quiz answers
01A unit file — the building block
Everything systemd manages is called a 'unit'. The most common type is a service — like nginx or sshd — but there are also timers (scheduled tasks), sockets, mounts, and the 'target' units you'll meet in step 3. Every unit is described by a small text file in INI format with up to three sections: [Unit] for metadata + what it depends on, [Service] for how to run it, [Install] for what 'enabling' attaches it to.
$ systemctl cat nginx.service— show the unit file$ systemctl status nginx.service— live state + last log lines$ systemctl show nginx.service— all resolved properties (deep dive)
02Dependencies — order and strength
After= and Before= set ORDERING (when, relative to others). Requires= and Wants= set STRENGTH (must this dependency be running? what if it fails?). Requires is hard — failure cascades. Wants is soft — failure is logged but ignored.
$ systemctl list-dependencies nginx.service— see what nginx pulls in$ systemctl list-dependencies --reverse nginx.service— see who needs nginx
03A target groups many units
A target is a unit with no payload of its own — it exists to be a sync point. multi-user.target says 'when I'm reached, these services must be running'. That's how systemd bundles 50 services behind one named state.
$ systemctl list-units --type=target— all active targets$ systemctl list-dependencies multi-user.target— what's in this target
04Targets nest — graphical → multi-user → basic → sysinit
Each target above 'requires' the one below it, so they stack like Russian dolls. From the bottom up: sysinit.target sets up mounts and cgroups; basic.target adds sockets, paths, and timers; multi-user.target adds the network, SSH, and your services; graphical.target adds the desktop (GDM). Reaching graphical.target pulls in everything below it automatically.
$ systemctl get-default— show current default target$ systemctl set-default multi-user.target— boot to text login next time (no GUI)$ ls -l /etc/systemd/system/default.target— default.target is just a symlink
05isolate — switch state without reboot
systemctl isolate <target>activates that target AND stops every active unit that's NOT a dependency of it. So 'isolate multi-user.target' tears down the GUI but keeps SSH, networking, services. Same boot graph, different anchor.$ systemctl isolate multi-user.target— drop GUI without rebooting$ systemctl isolate rescue.target— drop to single-user with mounted FS$ systemctl isolate emergency.target— bare minimum, root shell only$ systemctl isolate graphical.target— back to GUI
Quiz — answers
- service-a depends on service-b. If service-b fails to start, service-a should NOT start. Which directive do you use?
- →Requires=service-b.serviceRequires is the hard dependency — if it fails, the dependent unit fails too. Wants is the soft version (logs but ignores).
- What's the difference between After= and Requires=?
- →After= sets ordering only; Requires= sets dependency strength (failure cascades)Two different axes — order (After/Before) vs strength (Wants/Requires). You almost always want both.
- You're on a GUI system. You want to drop to a text-only console without rebooting. Which command?
- →systemctl isolate multi-user.targetisolate activates the named target AND stops anything not in it. So GUI services stop; SSH/networking/your services keep running.
- Your service is enabled but won't start at boot. Best first command?
- →systemctl status YOURSVCstatus shows the current state plus the last few log lines — almost always tells you exactly what went wrong.
keep going — these pair well with what you just learned.
SELinux contexts
Why Apache can't read your file. Watch the policy engine decide — and learn the workflow for fixing denials. RHCSA-ready.
Linux boot process
From power button to login prompt. Every stage in the chain — UEFI, GRUB, kernel, initramfs, systemd — with the rescue moves that save you. RHCSA-ready.
LVM stacking
Layer-by-layer build of an LVM stack: disks → PVs → VG → LVs → filesystem. Then extend live and snapshot. RHCSA-ready.