ws1's own hardening course ran systemctl restart apache2 and systemctl enable fail2ban without ever explaining what those words meant. ansible1-10's own capstone wrapped service: name: fail2ban state: restarted around exactly the same underlying mechanism. bash3 only gestured at it in passing. This course, starting now, is the actual explanation.

PID 1 — The First Process, With a Special Job

When the Linux kernel finishes its own initialization, it starts exactly one process directly: PID 1. Every other process on the system is, eventually, a descendant of it. PID 1 carries a genuinely special responsibility beyond just "the first thing that runs" — it also reaps orphaned processes, adopting them when their original parent process dies, so they never become permanent, un-cleaned-up zombies. On any modern Linux distribution — including Debian, ws1's own target — PID 1 is systemd.

System V init — The Sequential, Runlevel-Based Model

The traditional init system read a sequence of numbered shell scripts (the classic /etc/init.d/, rc.d-style layout), organized into runlevels — 0 for halt, 1 for single-user mode, 3 or 5 for multi-user with or without a graphical environment, 6 for reboot. The real limitation: startup was fundamentally sequential — script N+1 never started until script N finished, even when the two had nothing to do with each other, wasting real boot time waiting on completely unrelated services. Dependencies between services were expressed only informally, through the order scripts happened to be numbered — a fragile convention, not an explicit, checkable relationship.

systemd's Answer — Parallel, Dependency-Based Startup

systemd starts services in parallel wherever genuinely possible, and expresses real dependencies explicitly — previewed here, covered in full in systemd1-4's own Wants/Requires/After/Before material — rather than relying on script-numbering convention. This directly resolves System V init's own sequential-boot cost: independent services no longer wait on each other purely because of where they happened to land in a numbered sequence.

A Concrete Comparison — Booting the Same System, Two Ways

apache2 genuinely does need networking to be up first — that's a real dependency, expressed explicitly. cron has no such requirement, and under systemd it can start the moment its own dependencies are satisfied, without waiting for apache2 or anything else unrelated to finish first.

Hands-On Exercises

systemd1-1 established what systemd is and why it exists. This chapter gets concrete — the actual files systemd reads, and the real systemctl commands behind everything ws1 and ansible1-4 already used, unexplained.

What a Unit Is

A unit is systemd's own generic term for anything it manages — not just services, but sockets, timers, mounts, devices, and targets too (systemd1-3 covers .service in full depth, systemd1-7 covers .timer, systemd1-8 covers .socket). Every unit is described by a plain-text configuration file — its unit file.

Where Unit Files Actually Live — Location Precedence

• /usr/lib/systemd/system/ (or /lib/systemd/system/) — units shipped by installed packages, the vendor default
• /etc/systemd/system/ — local admin overrides and custom units, taking priority over the vendor copy
• /run/systemd/system/ — runtime-only, volatile, never survives a reboot; used by systemd itself and some tools for temporary units

If the same unit name exists in more than one location, /etc wins over /usr/lib — a real, useful override mechanism. Copying a vendor unit into /etc/systemd/system/ and editing it there lets you customize a service without touching the original package-provided file, which a future package update would otherwise silently overwrite.

Basic Unit File Syntax — A First Look

Just enough to recognize the shape — systemd1-3 does the real deep dive. [Unit] holds metadata (Description=); [Service] holds the actual execution details (ExecStart=, the command actually run); [Install] controls what happens when the unit is enabled — WantedBy=multi-user.target is exactly why this note matters back in systemd1-1's own boot-target material.

systemctl — The Real Command, In Depth

• systemctl start/stop/restart NAME — an immediate, one-time action; does not by itself survive a reboot
• systemctl status NAME — current state, recent log lines, whether it's enabled
• systemctl enable/disable NAME — a genuinely different axis: controls whether the unit starts automatically at the next boot, by creating or removing a symlink tied directly to the unit's own [Install]/WantedBy= line — completely independent of whether it's running right now

The real, common beginner confusion: enabling a service does not start it immediately, and starting a service does not enable it. These are two separate actions, frequently needed together.

Revealing What ansible1-4's Own service Module Wraps

ansible1-4's own service: name: nginx state: started is, underneath, literally invoking systemctl start nginx. Ansible's own idempotency check — is it already running? — corresponds directly to systemctl status being checked first, with start only actually called if genuinely needed. state: started maps to systemctl start; the module's own enabled: true option maps directly to systemctl enable. This is precisely what systemd1-1 promised, and what ansible1-1/ansible1-4 left unexplained.

Hands-On Exercises

systemd1-2 showed the shape of a unit file without explaining any field in depth. This chapter is that depth — and the real service written here is the same one systemd1-11's own capstone actually deploys.

[Unit] Section In Depth

Description= is shown directly in systemctl status output — worth writing something genuinely useful, not a placeholder. Documentation= is optional, a URL or man page reference. After=/Requires= are previewed here; systemd1-4 covers them in full.

[Service] Section — Type=

The field that determines how systemd knows whether the service actually started successfully:

• Type=simple (the default) — the process started by ExecStart= is the main process; systemd considers the service started the moment it forks
• Type=forking — for older-style daemons that fork into the background and exit the original process; systemd needs PIDFile= to know which PID to actually track
• Type=oneshot — a command that runs once and exits, not a long-running daemon at all; commonly paired with RemainAfterExit=yes so systemctl status still reports "active" after it finishes — directly relevant to systemd1-7's own timer-paired service units
• Type=notify — the service itself signals "I'm actually ready now" back to systemd; the most precise option, but requires the application to support it

ExecStart=, ExecStop=, ExecReload=

ExecStart= is required — the actual command that is the service. It must use an absolute path, a genuinely common beginner mistake: no shell PATH lookup happens here the way it would in an interactive terminal. ExecStop= is optional — for Type=simple, systemd can usually just send SIGTERM to stop the process cleanly; only write one when a service needs a genuinely custom shutdown command. ExecReload= runs on systemctl reload NAME — a real, common third action beyond just start/stop, typically telling a running process to re-read its config without a full restart.

Restart= — Automatic Recovery

Restart=on-failure (or always, or the default no) tells systemd to automatically restart the service if it exits unexpectedly. RestartSec= adds a delay before the restart attempt, avoiding a tight crash-loop hammering the system. A genuinely valuable capability with no clean System V init equivalent — one more concrete payoff of systemd1-1's own "why systemd replaced init" material.

[Install] Section — WantedBy=

WantedBy=multi-user.target is what systemctl enable actually acts on — the line determining which target's own .wants/ directory receives the new symlink. Different WantedBy= values matter for different kinds of services, previewed here and covered fully in systemd1-5's own targets chapter.

A Full Worked Example — Toward the Capstone

Every field here is explained above — this is the actual shape systemd1-11's own capstone deploys for real. User=myapp is worth a light callback of its own: running a service as a dedicated, non-root user rather than root by default is a genuinely security-relevant habit, the same least-privilege instinct owasp1/bc1 already established elsewhere on this site.

Applying a New or Changed Unit File

systemctl daemon-reload is required after creating or editing any unit file — it tells systemd to re-read unit files from disk. Forgetting it is a real, common "why isn't my change taking effect" gotcha.

Hands-On Exercises

systemd1-3 used After=network.target without fully explaining it. This chapter is the real depth — and the single most common point of confusion anyone new to systemd runs into.

Two Genuinely Separate Axes — What vs. When

The core confusion this chapter exists to resolve: "dependency" (should this unit even be started) and "ordering" (when, relative to another unit, should it start) are two separate, independently configured axes in systemd — not one combined concept, however natural that assumption feels at first. Wants=/Requires= control whether another unit gets started at all, as a side effect of this one starting. After=/Before= control only the order, with zero effect on whether anything actually gets started.

Wants= vs. Requires= — How Strict Is the Dependency?

Wants= is a soft dependency — if the wanted unit fails to start, the wanting unit still proceeds normally. The more common, more resilient choice for most real-world dependencies. Requires= is a hard dependency — if the required unit fails, systemd treats this unit's own startup as a failure too, and can stop it if the required unit later stops. Genuinely stricter, appropriate only when a unit truly cannot function at all without the other one.

A concrete example: a web server might Wants= a caching service — nice to have, but the site can still serve requests, just more slowly, if the cache is down — while it Requires= its own database, since it genuinely cannot function at all without one.

After= vs. Before= — Ordering Only, No Dependency Implied

This directly resolves systemd1-3's own After=network.target: it only says "if network.target is going to start anyway, for whatever reason, start after it." It does not, by itself, cause network.target to be started as a side effect. A unit with only After= and no Wants=/Requires= for the same target could, in principle, start with no network at all, if nothing else on the system independently wanted networking. This is exactly why real unit files commonly pair both together.

A Concrete Worked Example

In the second, broken version, if nothing else on the system happens to Want= network-online.target independently, this unit could start immediately — network or no network — with no error, no warning, just silently wrong behavior on a system where networking happens to come up slowly or not at all.

Target Units as Synchronization Points

systemd1-1 previewed target units replacing runlevels; systemd1-5 covers them in full. A target unit doesn't "do" anything itself — it's purely a named synchronization point, a milestone other units can Want=/Require=/order themselves around. This lets many otherwise-unrelated units all agree on "wait until networking is genuinely usable" without each one needing its own bespoke detection logic.

Viewing the Real Dependency Tree

Shows the actual, resolved dependency tree for a real unit on a real system — a genuinely concrete way to see this chapter's abstract material in practice, rather than only reasoning about it on paper.

Hands-On Exercises

systemd1-4 defined a target as a synchronization point without going further. This chapter goes further — and resolves grub1-4's own unexplained systemd.unit=rescue.target kernel parameter along the way.

What a Target Actually Is, Formally

systemd1-4 established that a target doesn't "do" anything itself. Formally: a target unit is a named grouping of other units — often implemented as essentially an empty unit that other units Want=/Require=/order themselves relative to. "Reaching a target" means every unit that target itself requires or wants, directly or transitively, has actually been started.

The Common Targets, Mapped to Legacy Runlevels

graphical.target itself Wants=multi-user.target, since graphical mode is a strict superset — everything multi-user mode provides, plus a display manager on top.

The Default Target

Which target boots by default is determined by a symlink — /etc/systemd/system/default.target pointing at the chosen target — genuinely similar in spirit to systemd1-3's own WantedBy= symlink mechanism, just applied to the top-level boot target rather than an individual service. A headless server typically defaults to multi-user.target; a desktop distro typically defaults to graphical.target.

systemctl isolate — Switching Targets Live

Run on a live graphical system, this stops everything not required by multi-user.target — the display manager included — and starts anything multi-user.target requires that wasn't already running. A genuine live runlevel-style switch, no reboot required. A real, practical use: temporarily dropping out of a graphical environment to troubleshoot a display/GPU driver issue, then isolating back to graphical.target once fixed.

Direct Legacy Comparison

systemd1-1's own System V material named telinit 3 as the legacy way to switch runlevels live. That maps directly to systemctl isolate multi-user.target — the same real-world action, but a genuinely different, more expressive mechanism underneath: an actual dependency-resolution operation, not a legacy numbered switch with no explicit relationship to what it starts or stops.

Resolving grub1-4's Own rescue.target

grub1-4 taught appending systemd.unit=rescue.target at the GRUB menu to reach a recovery shell, without explaining what that parameter actually meant. Now it's clear: this tells systemd to boot straight to this target instead of the normal default, bypassing graphical.target/multi-user.target's own much larger set of Wants=/Requires= dependencies entirely, landing in a genuinely minimal environment with far fewer units started — exactly why it's usable for recovery even when something elsewhere in the normal boot chain is broken.

Hands-On Exercises

systemd1-1's own warn-box named journald as part of systemd's broader scope beyond process supervision. This chapter is that promised depth — and it's also the single-host counterpart to obs1-7's own centralized logging material.

What journald Actually Is

systemd's own built-in logging daemon. It automatically captures stdout/stderr from every unit systemd manages, plus kernel messages, plus anything using the standard syslog() call — with no separate logging setup required for a systemd-managed service. Storage is structured and indexed, not plain text like a traditional /var/log/*.log file — queryable directly by unit, priority, or time range, without reaching for grep/awk gymnastics.

journalctl — The Basic Query Tool

-u myapp ties directly to systemd1-3's own worked example. -f is genuinely comparable to tail -f on a traditional log file. -b -1 is a real, practical tool for diagnosing a crash or unexpected reboot after the fact — the previous boot's own logs, isolated from everything since.

Persistent vs. Volatile Logging

By default on many systems, the journal lives in /run/log/journal/ — RAM-backed, volatile, wiped completely on reboot. This has a real, practical consequence: journalctl -b -1 only works at all if persistent storage is actually configured; without it, the previous boot's logs are simply gone.

Creating /var/log/journal/ with correct ownership is the actual, real-world trigger that switches journald into persistent mode automatically — logs now survive reboots. This matters directly for the same reason ws1's own security material cared about logging at all: a system with only volatile logs loses everything the moment it's rebooted, a real, practical gap for any kind of incident investigation after the fact.

Priority Filtering

The classic 8-level syslog priority scale — emerg, alert, crit, err, warning, notice, info, debug, ordered from most to least severe. -p err shows entries at error level or more severe — the scale is ordered, so this filters "at least this severe," not "exactly this level." A real, practical way to find genuinely serious issues in a noisy, chatty log without reading every routine info-level line.

The Single-Host Counterpart to obs1-7's Own Centralized Logging

obs1-7 covered structured logging and centralized aggregation (Loki) across many hosts and services, at real scale. journald solves a genuinely related but narrower problem — one host's own logs, structured and queryable, with no separate aggregation system required at all. The same underlying idea — structured, queryable logs beat unstructured, grep-able text files — applies at both scales, just with different tooling for different scopes. Real production setups often use both: journald locally on each host, with an agent (the same DaemonSet-based approach obs1-10 described) shipping journal entries onward to centralized storage. journald isn't replaced by Loki — it's frequently the local source a Loki-equivalent agent reads from in the first place.

Hands-On Exercises

systemd1-3's own Type=oneshot material previewed exactly this chapter. Timers are systemd's own scheduled-task mechanism — genuinely different from cron, not just a reskinned version of it.

The Two-Unit Pattern — .timer + .service

A systemd timer is genuinely two separate unit files working together: a .timer unit defining when to run, and a .service unit defining what to run — by convention, sharing the same base name (backup.timer + backup.service). A deliberate design decision distinct from cron: the "what" is a real, independently-runnable systemd service — exactly systemd1-3's own Type=oneshot material — cleanly separated from the "when." You can run and test the service directly at any time with systemctl start backup.service, with no need to wait for or fake the timer at all.

OnCalendar= — Scheduling Syntax

The general shape: DayOfWeek Year-Month-Day Hour:Minute:Second, with wildcards (*) and shorthand keywords (daily/weekly/monthly/hourly) covering common cases without needing the full explicit syntax.

Verifies a calendar expression means what you think it means before deploying it, printing the next several actual trigger times — genuinely worth running on any expression before trusting it.

A Full Worked Timer Example

Notice: you enable and start the timer, not the service directly — the timer itself then triggers the service at the scheduled time. WantedBy=timers.target is systemd1-5's own target material made concrete for a specific new case — a dedicated target that exists purely to group active timers.

Persistent=true — Catching Up Missed Runs

The real, standout advantage over cron. Persistent=true tells systemd to check, at boot, whether this timer's scheduled trigger was missed while the system was off — a laptop shut down overnight through the scheduled 3am backup, for instance — and if so, run it once, immediately, upon boot, rather than silently skipping that day entirely. Traditional cron has no native equivalent: a missed cron job, with the system off at the scheduled time, is simply missed, silently, until the next scheduled occurrence.

Direct Comparison Against Traditional Cron

Real, concrete advantages: dependency-awareness (a timer's own service can Wants=/After= other units — waiting for a network mount before running a backup, genuinely impossible to express cleanly in a crontab); automatic journald logging (systemd1-6's own material — every timer-triggered run is automatically logged and queryable via journalctl -u backup.service, unlike cron's own historical reliance on separate mail-based or ad-hoc logging); Persistent=true's own missed-run catch-up; and direct testability, per this chapter's own opening point. An honest note: cron's own crontab syntax is genuinely more compact for the simplest cases, and cron remains extremely widely deployed and understood — this isn't a "cron is bad" chapter, just an honest accounting of what systemd timers genuinely add.

Hands-On Exercises

systemd1-7 covered time-based activation. This chapter covers a genuinely different trigger — on-demand, connection-based activation, with no real precedent in traditional init or cron.

The Problem — Services That Are Rarely Used, But Must Always Be Ready

Some services are needed only occasionally — an SSH connection arrives once in a while, a rarely-used network service gets a request once a day. Traditionally, "must always be ready to respond" meant "must always be running," consuming memory and resources continuously, even through long idle stretches with zero actual traffic.

What Socket Activation Actually Does

systemd itself opens and listens on the network (or Unix domain) socket on behalf of a service, before that service is even running. Any connection attempt is queued by the kernel/systemd; only then does systemd actually start the real service, handing it the already-open socket. From the client's own point of view this is completely invisible — the connection appears to succeed immediately either way, whether the service was already running or had to be started on-demand just now.

A .socket Unit, Paired With a .service Unit

The same two-unit pattern as systemd1-7's own .timer/.service pairing — here, .socket + .service, sharing a base name.

myapp.service itself needs no port-binding logic of its own — systemd hands the already-listening socket to the service when it starts it, via a specific, well-known file descriptor (conventionally file descriptor 3). WantedBy=sockets.target is systemd1-5's own targets material, one more dedicated target — directly parallel to systemd1-7's own timers.target.

Enabling and Testing Socket Activation

Again, enable and start the socket, not the service directly — the same pattern systemd1-7 already established for timers. The before/after state is genuinely visible: the socket shows active/listening immediately, while the service itself stays inactive until the first real connection triggers it.

Real Efficiency Benefits

Real memory and resource savings for genuinely rarely-used services — no process running at all during idle periods. A real, historical example worth naming: SSH itself was traditionally socket-activatable this way on some systems (sshd.socket alongside sshd.service) — though many modern distros run sshd as an always-on service instead, for latency reasons on a frequently-used service. Socket activation genuinely shines for rarely-used services specifically, not universally. Faster boot, too: a socket-activated service doesn't need to actually finish starting up during the boot sequence itself — only the socket (cheap to open) is needed at boot; the real service startup is deferred until first actually used.

An Honest Limitation

Not every service is a good fit. A service with genuine startup latency — loading a large dataset, warming a cache — means the first connection after any idle period genuinely waits for that startup to finish, a real, noticeable delay an always-running service wouldn't have. Socket activation trades "always consuming resources" for "occasionally slower first response" — a genuine tradeoff, not a pure, unconditional win.

Hands-On Exercises

perf1's own CPU and Memory Bottlenecks chapters covered diagnosing a resource problem system-wide. This chapter closes the loop — once you know which specific service is the actual cause, systemd's own per-service limits are the concrete tool to contain it.

What cgroups Actually Are

Control groups (cgroups) are a Linux kernel feature that groups processes together and lets the kernel enforce resource limits — CPU, memory, I/O — on the group as a whole, not just individual processes. A genuinely important, often-unknown fact: as PID 1 and the ultimate ancestor of essentially every process on the system, systemd automatically places every unit into its own cgroup, by default, whether or not any explicit limit is ever configured. Cgroup accounting already exists per-unit before you ever write a single CPUQuota= line.

Setting Limits — CPUQuota= and MemoryMax=

CPUQuota=50% means this service can use at most 50% of a single CPU core's worth of processing time — even on a multi-core system, even with idle capacity available elsewhere — genuinely enforced by the kernel, not a polite request. MemoryMax= is a hard ceiling; exceeding it triggers the kernel's own OOM killer specifically against this cgroup, rather than the whole system hunting for an arbitrary victim process. MemoryHigh= is the softer companion — a throttling threshold below MemoryMax= that encourages memory reclaim before the hard kill ever becomes necessary.

Why This Matters — the Direct Tie to perf1

perf1's own bottleneck chapters diagnosed resource problems at the whole-system level — a genuinely common real outcome of that kind of investigation is discovering one specific misbehaving service is the actual cause. This chapter's own limits are the concrete containment tool once that diagnosis is made. Concrete scenario: a runaway process — a memory leak in a custom app — that would otherwise eventually exhaust all system memory, potentially taking down unrelated services too. MemoryMax= turns "the whole system's memory" into "just this cgroup's own memory," genuinely containing the blast radius to the one service actually responsible.

systemd-cgtop — Real-Time Per-Unit Resource Usage

A live, top-style view — but organized by cgroup/unit rather than individual process, showing CPU/memory/IO usage per service, in real time. Immediately actionable alongside this chapter's own CPUQuota=/MemoryMax= settings — observe first, then set a limit informed by real usage.

Verifying a Limit Is Actually Enforced

Confirms the configured value actually took effect. systemd1-3's own daemon-reload gotcha applies directly here again — forgetting to reload and restart after adding a resource limit means the old, unrestricted cgroup settings are still what's actually enforced.

Hands-On Exercises

systemd1-1 claimed systemd's parallel, dependency-based startup is faster than System V init's sequential one. This chapter gives you the tools to actually see that claim in practice — and to diagnose it when something goes wrong.

systemd-analyze — The Basic Boot Time Report

A first-glance breakdown: kernel time, initrd time, and userspace time — the portion systemd itself is responsible for. A genuinely useful starting point before diving deeper into any specific tool below.

systemd-analyze blame — Which Units Took the Longest

A sorted list of every unit and how long it individually took to initialize, longest first. A real, important caveat, tying directly back to systemd1-1's own parallel-startup material: a unit taking a long time doesn't necessarily delay the overall boot, if other unrelated units were starting in parallel at the same time. blame shows individual unit duration — not necessarily "this is why your boot is slow."

systemd-analyze critical-chain — The Actual Bottleneck Path

This is the tool that actually answers "what delayed the overall boot": the critical path — the specific chain of units where each one genuinely had to wait for the one before it, via real dependencies (systemd1-4's own material) — tracing back to the actual longest dependency chain, not just the longest individual unit. A unit can show up near the top of blame (genuinely slow on its own) but never appear on the critical path at all, if it was running in parallel with other things and nothing else was actually waiting on it. This is exactly the resolution to blame's own caveat above.

systemd-analyze plot — Visualizing the Whole Boot

Generates an actual visual, Gantt-style timeline of every unit's start time and duration — genuinely useful for spotting parallel vs. sequential patterns at a glance, rather than reading through a table of numbers.

Masking vs. Disabling — A Real, Important Distinction

systemd1-2 covered disable — it removes the boot-time symlink, but a disabled unit can still be started manually, or pulled in as a dependency of something else that Wants=/Requires= it. systemctl mask is genuinely stronger: it creates a symlink to /dev/null in place of the unit, making it impossible to start at all — not manually, not as anyone else's dependency, nothing — until explicitly unmasked. The real use case: a unit that's actively causing boot problems and needs to be completely, unconditionally prevented from running while you investigate, not just "not started by default."

A Real Diagnostic Workflow — Slow Boot

1. systemd-analyze — confirm the boot is genuinely slow
2. systemd-analyze critical-chain — find the actual bottleneck chain, not just guess from blame
3. Identify the specific slow unit on that chain
4. journalctl -u THATUNIT -b (systemd1-6's own tool) — investigate what it was actually doing
5. If it's not needed at boot at all, systemctl disable it; if it's actively causing harm, systemctl mask it while investigating further

A Real Diagnostic Workflow — Failed Boot / A Unit That Won't Start

Lists every unit currently in a failed state — a genuinely fast first step. Then systemctl status THATUNIT (systemd1-2's own tool) for the specific error, then journalctl -u THATUNIT -b for the full detail behind it.

Hands-On Exercises

The final chapter. A real small app — notesapp — deployed as a properly dependent, resource-limited service with a companion maintenance timer, logged and verified using every tool this course has built. This is where ws1's and ansible1-10's own unexplained systemctl/service calls finally get their full answer.

The Target — A Real Small App: notesapp

A small notes-taking web service: a long-lived process, needs the network genuinely up before starting, running on a modest, shared VPS where resource limits matter, and needing a periodic cleanup job to purge notes older than 90 days.

Step 1 — The Service Unit

Note the paired Wants= and After= for network-online.target — systemd1-4's own central lesson, applied for real: After= alone would never guarantee networking is actually started; the pair together genuinely guarantees both that it starts and that it starts first.

Step 2 — Resource Limits

These values were chosen only after observing notesapp's own real memory and CPU usage via systemd-cgtop over a representative period — systemd1-9's own warn-box, applied honestly here rather than picking arbitrary numbers.

Step 3 — Applying and Verifying

daemon-reload is not optional (systemd1-3's own gotcha); the final command confirms the resource limit actually took effect, exactly systemd1-9's own verification step.

Step 4 — The Companion Maintenance Timer

systemd1-7's own two-unit pattern, applied for real — the cleanup logic is a genuine, independently-testable Type=oneshot service; the timer only decides when it runs.

Step 5 — Reading the Logs

The first watches notesapp live after its first start; the second confirms the daily cleanup timer's own most recent run actually executed and logged correctly — systemd1-6's own tools, put to real use.

Step 6 — Verifying Boot Impact

An honest use of systemd1-10's own tool — confirming notesapp's real position (or lack of one) in the boot's actual critical path, rather than assuming a new service must automatically be a boot-time concern just because it's new.

Closing the Loop on ws1 and ansible1-10

Every systemctl command run throughout this capstone — status, restart, enable, daemon-reload — is now fully understood. This resolves exactly what ws1's own hardening chapters and ansible1-10's own capstone left unexplained at the very start of this course.

Hands-On Exercises