Module 10 · Putting it all together
A troubleshooting checklist
A calm, repeatable method for when something fails: read the message, check the exit status, the command, the path, the permissions, the resources and the script itself, one step at a time.
What you will learn
- Map the most common error messages to their usual causes.
- Work through a fixed checklist instead of guessing.
- Debug scripts with `sh -n` and `sh -x`, and find and stop a runaway process.
Things will break: a script that worked yesterday, a command that says not found, a machine that suddenly feels slow. Experienced administrators are not people who never see errors; they are people who have a method. This lesson collects the tools of the previous ninety-eight lessons into a checklist you can follow when you have no idea where to start. Then the three exercises let you practise it on real, broken things.
The checklist
- Read the whole message. It usually names the program that complained, the file and the reason.
cat: can't open 'notes.txt': No such file or directoryalready tells you who, what and why. - Check the exit status with
echo $?right after the failure: 1 is a general error, 2 often a usage mistake, 126 found but not executable, 127 not found. - Is it the command you think?
type name,which name,echo $PATH. An alias, a typo or a missing PATH entry explains mostnot founderrors. - Does the path exist, exactly?
ls -l path, then each parent withls -ld. Watch for relative paths run from the wrong directory (pwd), uppercase letters, and spaces without quotes. - Permissions and owner.
ls -landid. A script needsx; a directory needsxto be entered. Root ignores most read and write bits, but never the execute bit. - Resources.
df -h(full disk),du -s(who is filling it),free(memory),uptime(load). - Processes.
psandtopto find what is running or stuck,kill PIDto stop it,kill -9only as a last resort. - Kernel messages.
dmesg | tailfor hardware, drivers, mounts and out-of-memory kills. - Change one thing at a time, keep a copy first (
cp f f.bak), and usediffto see what you changed.
Common messages and where they point
| Message | Usual cause | First command |
|---|---|---|
not found (127) | Typo, not in PATH, missing ./, or a shebang naming a missing interpreter | type cmd, head -1 script |
Permission denied (126) | No execute bit, or a non-root user without rights | ls -l file |
No such file or directory | Wrong path or wrong current directory | pwd; ls -l path |
No space left on device | Full filesystem | df -h, du -s /dir/* |
syntax error: unexpected … | Missing fi, done, ; or quote in a script | sh -n script |
Debugging scripts
sh -n script.sh reads the script without running it and reports syntax errors with a line number. sh -x script.sh runs it and prints every command, after expansion, with a + in front, so you see the real values of your variables. A variable that expands to nothing is a typical clue: here $dri should have been $dir, so ls listed the current directory instead.
~% sh -x lab/l99/count.sh
+ dir=/root/lab/l99/logs
+ ls
+ wc -l
+ count=2
+ echo 2
~% grep -n dri lab/l99/count.sh
3:count=$(ls $dri | wc -l)
Commands in this lesson
| Command | What it does |
|---|---|
echo $? | Exit status of the last command. |
type cmd | What the shell will run for `cmd`. |
ls -ld /path /path/sub | Check each level of a path. |
df -h; free | Disk and memory at a glance. |
sh -n script | Syntax check without running. |
sh -x script | Trace every command as it runs. |
ps | grep '[n]ame' | Find a process by name. |
dmesg | tail | Latest kernel messages. |
Quiz
A script starts with `#!/bin/bash` and running it gives `not found`, although the file exists and is executable. Why?
- The interpreter named in the shebang does not exist on this system.
- The script is too long.
- The disk is full.
Which command shows each line of a script, with variables expanded, as it runs?
- `sh -n script`
- `sh -x script`
- `cat -n script`
Writing a file fails with `No space left on device`. First command?
- `df -h`
- `chmod 777`
- `reboot`
Why does `ps | grep '[h]og'` not show the grep line itself?
- grep hides itself automatically.
- The grep's own command line contains `[h]og`, which the pattern `hog` does not match.
- ps never lists grep.
What is the best habit before editing a config file to fix a problem?
- Make a copy (`cp f f.bak`) and change one thing at a time
- Change everything that looks suspicious at once
- Delete it and start over
Practice
`/root/lab/l99/backup.sh` should create `/root/lab/l99/backup.tar`, but `./backup.sh` fails. There are **two** problems (hint: permissions and the first line). Fix both so that running `/root/lab/l99/backup.sh` directly works.
`/root/lab/l99/count.sh` should write the number of files in `/root/lab/l99/logs` (there are 4) into `/root/lab/l99/count.txt`, but it writes a wrong number. Trace it with `sh -x`, find the bug and fix the script.
Something is running a script called `hog.sh` in an endless loop. Find its process with `ps` and stop it with `kill`.
Open this lesson in the app to do the tasks in a real Linux machine and have them checked.