Exercise 2: disable vs. mask, and When disable Alone Fails — Possible Solution
====================================================================

Explanation:

Per the chapter's own description, systemctl disable myapp "removes
the boot-time symlink" -- it stops myapp from starting automatically
as part of normal boot sequencing. But the chapter is explicit that
"a disabled unit can still be started manually, or pulled in as a
dependency of something else that Wants=/Requires= it." Disabling
only removes ONE specific mechanism (the automatic boot-time
[Install]/WantedBy= symlink) that could cause the unit to start --
it doesn't touch any of the other ways a unit can be started.

systemctl mask myapp is described as "genuinely stronger" -- it
replaces the unit entirely with a symlink to /dev/null, meaning
systemd can find no real unit definition there at all. Per the
chapter's own wording, this makes the unit "impossible to start at
all -- not manually, not as anyone else's dependency, nothing -- until
explicitly unmasked."

-- A scenario where disable alone would not prevent myapp from
starting --
--
-- Suppose another, unrelated unit -- call it webapp.service -- has
-- Wants=myapp.service in its own [Unit] section (systemd1-4's own
-- material on how one unit can pull in another as a dependency).
-- Even after myapp has been disabled, webapp.service starting (for
-- any reason, including its own normal boot-time enable) would still
-- cause systemd to start myapp anyway, as a side effect of satisfying
-- webapp's own Wants= dependency -- disable never touched that
-- dependency relationship at all, since it only removed myapp's OWN
-- boot symlink, not anything referencing myapp from elsewhere. Only
-- masking myapp would prevent this, since a masked unit cannot be
-- started under any circumstance, including as someone else's
-- dependency.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real mechanical difference between the two
commands using the chapter's own exact language, and constructs a
concrete scenario (a dependency relationship via Wants=) explaining
specifically why disable's own limited scope wouldn't prevent
myapp from starting in that case.