Lab: diagnose a failed user service

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 website service needs a page request in addition to manager state.

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.

Sources

Primary references: systemd service semantics↗; systemctl↗.