DevOps Foundations · Module 1: Linux working model · Lab
Diagnose a Boot Failure from Environment and Unit
45 min hands-on · Core
Local Linux shell; a systemd user unit or any supervisor file you can read. No root required: a broken unit file under /tmp plus journal reading is enough.
Two ways to do this lab: in your browser on Killercoda (free, no install), or on your own machine as a local guide. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.
Objectives
- Read a service definition and predict its startup behavior
- Separate an environment-variable fault from a unit-definition fault
- Show the evidence chain from first error to cause
Step 1
Plant two faults
Take a minimal unit (or a start script) that runs 'APP_PORT=8080 myapp'. Introduce fault A: an env file setting APP_PORT to a word instead of a number. Introduce fault B: a unit pointing ExecStart at a renamed binary path. Keep both written down separately.
Step 2
Read, do not restart yet
Run the equivalent of 'systemctl status' plus the last 30 journal lines for the unit. Identify which fault fires first at boot: the missing binary (immediate exit, status 203) or the bad value (starts, then errors). Quote both lines.
Step 3
Fix in fault order and verify
Fix the first-firing fault, re-run, watch the second fault appear, fix it too. End with the service active and one request or process check proving it. Record symptom, checks, cause, fix, verification.
How to confirm it worked
- Both planted faults are documented before diagnosis starts
- The journal/status output shows which fault fires first
- The final state is verified with a live check, not assumed from exit code
- The record follows the five-line shape from lesson 4