Practical lab guide
Lab: diagnose a failed user service
Capture an exit failure, repair the unit, and verify the next run.
Linux
Predict before you try
Does a successful start command prove the service keeps running and serves its intended request?
Try it: Build the evidence trail →On this page
Scope and prerequisites
Use Ubuntu with systemd in the disposable Linux machine, a regular user, and a functioning user service manager. Check systemctl --user status first. If it cannot connect, fix the user-session setup or use a suitable full VM; do not run this fixture as a system-wide root service to bypass the issue.
Confirm that ~/.config/systemd/user/learnwithsk-check.service does not already exist. Create the directory if needed, then save this unit there:
[Unit]
Description=LearnWithSK deliberate failure fixture
[Service]
Type=oneshot
ExecStart=/usr/bin/false
To create the unit with explicit commands, first check the target in your Linux terminal:
mkdir -p ~/.config/systemd/user
ls -l ~/.config/systemd/user/learnwithsk-check.service
A missing-file message is expected for a new fixture. If the file exists, stop and inspect it; do not overwrite another unit. Only for the new unused name, save the unit:
cat > ~/.config/systemd/user/learnwithsk-check.service <<'EOF'
[Unit]
Description=LearnWithSK deliberate failure fixture
[Service]
Type=oneshot
ExecStart=/usr/bin/false
EOF
The quoted delimiter writes the contents literally. The fixture uses your user manager and does not need sudo or boot enablement.
Build the evidence trail
systemctl --user daemon-reload
systemctl --user start learnwithsk-check.service
systemctl --user show learnwithsk-check.service -p Result -p ExecMainStatus
journalctl --user -u learnwithsk-check.service -n 20 --no-pager
The start is expected to fail because false exits unsuccessfully. Capture the failure before editing. Change only ExecStart to /usr/bin/true, reload unit definitions, and start again. Read the same properties and new journal entries.
A successful oneshot may be inactive afterward. The unit's result and exit status, not a continuously running PID, are the useful evidence here. This is a command-lifecycle fixture; it does not simulate an HTTP application or prove application readiness.
For the failure, expect Result=exit-code and ExecMainStatus=1. After editing the file's ExecStart from /usr/bin/false to /usr/bin/true, repeat daemon-reload, start, show, and the journal query. Expect Result=success and ExecMainStatus=0; the journal should distinguish the failed attempt from the later successful one. Exact status prose may vary by systemd release.
Why reload definitions? Otherwise the manager can still use its previous definition. Why not expect a lasting PID? The new command exits immediately and the oneshot has completed its job. A later HTTP fixture needs an expected page request in addition to manager state; a running MicroBank profile also needs application-level checks.
Cleanup
Stop the fixture if necessary. Remove only ~/.config/systemd/user/learnwithsk-check.service, then run systemctl --user daemon-reload. It was never enabled at boot. If a failed-state record remains, clear it with systemctl --user reset-failed learnwithsk-check.service; an absent-unit response after removal is not a new application failure.
Checkpoint and revision
Explain why daemon-reload was needed, why enabling would not fix the false command, and why an inactive oneshot can be successful. Supply before/after exit evidence and the exact one-line repair.
Revision: unit definition → exit evidence → scoped edit → manager reload → same check → cleanup. Keep the report short enough that another person could reproduce the fixture without guessing which service to touch.
Apply this to MicroBank
Keep the deliberate oneshot failure as your first MicroBank operating-evidence exercise. Report the failed command, exact edit, manager reload, and new result. The readiness project adds a separate local HTTP fixture with a page check. Neither fixture starts Accounts or proves Ledger processing, so record those application checks as pending until the DevOps lab.
Keep this observation in the MicroBank readiness project.
Sources
Primary references: systemd service semantics↗; systemctl↗.
Prove what you learned
Inspect the result
Retain exit/status evidence and the same behaviour check after recovery.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one fixture start condition and predict its effect before rerunning the same check.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Build the evidence trail”.
- Retain exit/status evidence and the same behaviour check after recovery.
- Explain the transfer challenge and retain the same verification question.
Hint
Compare the manager result, current process state and application response.
Answer guide: compare after predicting
No. Inspect the service result and logs, then repeat the intended behaviour check.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the caller and endpoint from the browser request exercise. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.