In short: Roughly twenty Linux commands cover most day-to-day administration and troubleshooting. Learn them grouped by the question they answer, what is running, what is using resources, what changed, what is in the logs, rather than as an alphabetical list.
Command lists are easy to find and hard to retain. What makes commands stick is attaching each one to a question you will actually ask while something is broken.
What is running, and what is it doing?
| Command | Answers |
|---|---|
| ps aux | What processes exist right now |
| top / htop | What is consuming CPU and memory, live |
| systemctl status <unit> | Is this service running, and why did it stop |
| journalctl -u <unit> -n 100 | What did this service say before it failed |
What is using resources?
| Command | Answers |
|---|---|
| df -h | Which filesystem is full |
| du -sh * | What inside this directory is large |
| free -h | How much memory is actually available |
| iostat / vmstat | Is the bottleneck disk or CPU |
What is happening on the network?
| Command | Answers |
|---|---|
| ip a / ip r | What addresses and routes does this host have |
| ss -tulpn | What is listening, and which process owns it |
| dig <name> | What does DNS actually return |
| curl -v <url> | What happens on the wire for this request |
What is in the files, and what changed?
| Command | Answers |
|---|---|
| grep -rn <pattern> <path> | Where does this string appear |
| find <path> -mtime -1 | What changed in the last day |
| tail -f <file> | What is being written right now |
| diff -u a b | What is different between these two files |
How to actually retain them
- Learn the four groups above as questions, not as a list
- When you use a command successfully during a real problem, write the line down
- Read the man page for one command a week rather than memorizing flags
- Replace any sequence you type more than three times with a small script
Fluency comes from diagnosis, not from flashcards. Break something in a virtual machine on purpose and fix it, that single habit does more than any reference list.
Where to go next
Linux for Network Engineers
The operating system underneath the network: shell, networking stack, services, permissions and the diagnostics every infrastructure role assumes.
View courseReal-Time Network Automation Projects
Extended automation build work: multi-device tooling under version control, with CI running the validation on every change.
View course