The Linux commands you actually need on a server fit on one page, and there are about twenty-five of them: ls, cd, cat, less, grep, find, tail, df, du, free, top, ps, kill, systemctl, journalctl, ss, curl, dig, chmod, chown, tar, rsync, ssh, scp, and sudo. Everything else is either a variation on those or something you will look up the twice a year you need it. The hundred-command cheat sheets are optimised for looking comprehensive, not for the thing you are actually doing at 2am, which is almost always answering one of five questions: is the disk full, is memory exhausted, is the process running, can it reach the network, and what do the logs say.
A cheat sheet should fit the situation you use it in. Nobody scrolls a hundred-item table while a service is down. So here is the short list, grouped by the question you are trying to answer.
Table of contents
- Is the disk full?
- Is it out of memory?
- Is the process running?
- Can it reach the network?
- What do the logs say?
- Files, permissions, and moving things
- The five-minute triage
- How this fits the rest of the stack
- FAQ
Is the disk full?
The single most common cause of a server behaving bizarrely. Not down - bizarre. Writes fail, logs stop, the database goes read-only, and the error messages make no sense until you check.
df -h # free space per filesystem. Start here.
du -sh /var/log/* # what is big in this directory?
du -h --max-depth=1 / | sort -h # walk down to find the culprit
ls -lah # sizes in this directory
ncdu / # interactive, if installed. Excellent.The df -h then du walk is the whole procedure. df tells you which filesystem is full; du tells you what filled it. Ninety percent of the time the answer is logs, an old build artifact, or Docker images.
docker system df # Docker's disk usage. Often the answer.
docker system prune -a # reclaim it. Read what it will delete first.One trap worth knowing: df says the disk is full but du cannot find the space. That usually means a deleted file is still held open by a running process - the space is not freed until it exits. lsof | grep deleted finds it.
Is it out of memory?
free -h # total, used, available. Read 'available'.
top # live view, sort by memory with Shift+M
htop # nicer, if installed
ps aux --sort=-%mem | head # top memory consumers, one shotRead the available column in free -h, not free. Linux deliberately uses spare RAM for disk cache, so free looks alarmingly small on a perfectly healthy machine. available is what your applications can actually get. Every year someone panics about the wrong column.
If a process vanished without explanation, check whether the kernel killed it:
dmesg -T | grep -i oom
journalctl -k | grep -i 'killed process'An OOM kill leaves no application log - the process is simply gone mid-sentence. dmesg is the only place that records why, and it is the first thing to check when a service died with no traceback.
Is the process running?
systemctl status nginx # the modern answer for a service
systemctl restart nginx
systemctl enable nginx # start on boot - easy to forget
ps aux | grep -v grep | grep myapp
pgrep -af myapp # cleaner than ps | grep
kill -TERM <pid> # ask it to stop
kill -9 <pid> # make it stop. Last resort.
pkill -f 'python worker' # by command line patternsystemctl status is the one to reach for first: it gives you running state, the last few log lines, and the PID in one output. That embedded log excerpt is often the entire diagnosis.
On kill -9: it gives the process no chance to flush, close, or clean up. Use kill (which sends TERM) first and give it a few seconds. -9 is for something genuinely wedged, and reaching for it reflexively is how state gets corrupted.
Can it reach the network?
ss -tulpn # what is listening, and what owns it
curl -v https://api.example.com # full request/response detail
curl -I https://example.com # headers only
dig example.com # what does DNS actually say?
dig @8.8.8.8 example.com # bypass the local resolver
ping 1.1.1.1 # is the network up at all?
traceroute example.com # where does it stop?ss -tulpn replaced netstat and is the most useful of these. It answers is my app listening, on what port, on what interface, and under what PID - which resolves a surprising share of it works locally but not remotely.
Watch the interface in that output. A service bound to 127.0.0.1:8000 is unreachable from anywhere else, and the fix is binding to 0.0.0.0. That single distinction accounts for a lot of wasted debugging.
For DNS, dig beats ping for diagnosis because it shows you the actual record and TTL rather than just succeeding or failing.
What do the logs say?
journalctl -u myapp -f # follow a service's logs
journalctl -u myapp --since '10 min ago'
journalctl -p err -b # errors this boot
journalctl -u myapp -n 100 --no-pager
tail -f /var/log/nginx/error.log
tail -n 100 /var/log/syslog
grep -i error /var/log/myapp.log | tail -50journalctl -u <service> --since is the one worth memorising. Being able to say show me this service’s logs from ten minutes ago converts a vague report into a specific window.
grep options that pay for themselves:
-i- case-insensitive. ERROR, Error, error.-r- recursive through a directory.-n- line numbers.-C 3- three lines of context either side. The traceback is usually in the context, not the matching line.-v- invert.grep -v healthcheckto drop the noise.
-C 3 is the underused one. The line that matched is rarely the whole story.
Files, permissions, and moving things
find /var -name '*.log' -mtime +30 # older than 30 days
find . -type f -size +100M # big files
find /tmp -type f -mtime +7 -delete # preview WITHOUT -delete first
chmod 600 secrets.env
chown app:app /var/www/html -R
tar -czf backup.tar.gz /var/www # create
tar -xzf backup.tar.gz # extract
rsync -avz --progress ./dist/ server:/var/www/ # the good one
scp file.txt server:/tmp/ # the simple oneAlways run find without -delete first and read the list. The command is identical minus four characters, and the difference between them is whether you get a preview or a fait accompli.
rsync over scp for anything repeated: it only transfers differences, it can resume, and -a preserves permissions and timestamps. scp is fine for one file, once. For a deploy, rsync is the right tool - and worth noting that the trailing slash on the source directory changes the behaviour, which is the classic rsync surprise.
The five-minute triage
When something is wrong and you do not know what, in order:
df -h- is the disk full? Fixes more mysteries than anything else on this list.free -h- is memory exhausted? Thendmesg -T | grep -i oom.systemctl status <service>- is it even running, and what did it last say?journalctl -u <service> --since '10 min ago'- what happened just before?ss -tulpn- is it listening where you think it is?curl -v localhost:<port>- does it answer locally? That splits app problems from network problems.
Six commands, under a minute, and they identify the layer for the overwhelming majority of incidents. The hundred-command cheat sheet does not help here because the problem was never that you did not know enough commands - it was knowing which question to ask first.
How this fits the rest of the stack
Every command on this page exists because someone is maintaining a server by hand, and the honest question is how much of that work belongs to you rather than to a platform. Log aggregation, disk headroom, and process supervision are solved problems that no product gets better by re-solving. The RunxBuild hosting calculator shows what the compute, database, storage, and bandwidth cost together so that trade-off is a number you can look at, and the RunxBuild dashboard puts the deploy and the runtime logs in the same place.
Useful related references:
- Show CPU Usage on Linux: The Commands That Stay Useful
- Linux View Environment Variables: The Five Commands, the .bashrc, the systemd Unit, and the One Mistake That Leaks the Secret to ps
- How to Rename a File in Linux: mv, rename, and git mv
- Services on RunxBuild
FAQ
What are the most important Linux commands to know for a server?
About twenty-five cover nearly everything: df and du for disk, free and top for memory, ps, kill, and systemctl for processes, ss, curl, and dig for network, journalctl, tail, and grep for logs, plus find, chmod, chown, tar, rsync, ssh, and scp for files. Longer cheat sheets add breadth you will rarely use during an actual incident.
How do I find what is using disk space on Linux?
Start with df -h to find which filesystem is full, then du -h --max-depth=1 /path | sort -h to walk down and find the culprit. ncdu is excellent if installed. On a container host, check docker system df - images and volumes are frequently the answer. If df shows full but du cannot account for it, a deleted file is still held open by a process: find it with lsof | grep deleted.
What is the difference between kill and kill -9?
Plain kill sends SIGTERM, asking the process to shut down gracefully so it can flush buffers, close connections, and clean up. kill -9 sends SIGKILL, which the process cannot catch or handle - it stops immediately, mid-write if necessary. Always try SIGTERM first and give it several seconds; reach for -9 only when the process is genuinely wedged, because it risks corrupt state.
Why does free -h show almost no free memory?
Because Linux uses spare RAM for disk cache, which is a feature rather than a problem - that memory is reclaimed instantly when applications need it. Read the available column, not free. available is what your applications can actually obtain. A machine showing little free memory and plenty of available memory is healthy and running exactly as designed.
What replaced netstat on modern Linux?
ss, from the iproute2 package. ss -tulpn lists TCP and UDP listening sockets with the owning process, and it is faster than netstat on busy systems. It is the quickest way to answer whether your application is listening, on which port, and on which interface - the last of which catches the common case of a service bound to 127.0.0.1 being unreachable from outside.