Security and troubleshooting
Complete the service review
Review one production-style unit from identity and dependencies through recovery, logging, limits, and deployment.
8 minute lesson
A good unit file is a small operational contract. Another person should understand how the service starts, stops, fails, and recovers — without asking you. This closing lesson turns everything from the course into one repeatable review.
Collect the evidence
Review the service’s account, paths, configuration, dependencies, restart policy, timeouts, resources, sandboxing, logs, timer relationships, health check, and rollback procedure. Each item maps to a command you already know:
systemctl cat demo-api.service
systemctl show demo-api.service -p User,WorkingDirectory,Wants,After
systemctl show demo-api.service -p Restart,RestartSec,TimeoutStopSec,NRestarts
systemctl show demo-api.service -p MemoryMax,TasksMax,Result
systemd-analyze security demo-api.service
systemctl list-timers --all
journalctl -u demo-api.service -p warning -b
systemctl cat shows the contract as written, drop-ins included. The show queries reveal the effective values — including defaults nobody set on purpose, like a missing memory limit or the 90 second stop timeout. The journal query surfaces warnings the service has been logging while everyone looked away.
Two questions have no command and matter most: where is the health check, and what is the rollback procedure? If the answer to either is “ask Flavio”, the contract is incomplete.
Write it down, small
A review that lives in your head expires in a week. Keep the artifact tiny:
Service: demo-api.service Reviewed: 2026-08-03
Strength: restart policy verified — killed the process,
recovered in 2s, NRestarts incremented as expected
Risk: DATABASE_URL passed via Environment=,
visible in `systemctl show` to any local user
Improvement (tested): moved the password to
LoadCredential=, restarted, login path verified
Name one verified strength, one concrete risk, and one reversible improvement you tested. Each claim needs evidence: the strength was exercised, not assumed; the risk names how you would exploit or trigger it; the improvement was applied, verified, and could be rolled back with a single drop-in removal.
The trap in service reviews is producing opinions instead of observations. “Restart policy looks fine” is an opinion. “I killed the main process and watched it recover in two seconds” is a review.
Run this review against one real service you operate. It usually takes twenty minutes and almost always finds something.
Lesson completed