Exercise 3: An Edited Restart= Setting That Doesn't Take Effect — Possible Solution
====================================================================

Most likely cause: systemctl daemon-reload was never run after the
unit file was edited.

Explanation:

Per the chapter's own warn-box, systemd "keeps using its own cached,
in-memory copy of unit files until explicitly told to reload." Editing
/etc/systemd/system/myapp.service on disk changes the FILE, but
systemd's own currently-loaded understanding of that unit's
configuration -- including its Restart= setting -- is not
automatically refreshed just because the file changed. Running
systemctl restart myapp in this state restarts the SERVICE process
using systemd's still-cached, pre-edit configuration -- the exact old
Restart= behavior the user is still seeing, even though the file on
disk is now correct.

-- The fix --

Run sudo systemctl daemon-reload first, which tells systemd to
re-read all unit files from disk (including the edited
myapp.service), refreshing its own in-memory configuration. Only
after that should systemctl restart myapp be run again -- at that
point, the restart will actually apply the new Restart= setting from
the edited file. Simply restarting the service without first
reloading the daemon's own configuration cache leaves the edit
sitting correctly on disk but genuinely unused, exactly the "why isn't
my change taking effect" symptom the chapter's own warn-box describes,
and exactly parallel to grub1-3's own "edited the right file but
forgot update-grub" gotcha.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific missing step (daemon-reload) and explains
mechanically why the old behavior persists (systemd's own cached
config, not the file on disk, governs the restart), rather than
guessing at an unrelated cause, and gives the correct ordered fix.