Services, disk space and network checks
Start and inspect services with systemctl, find what is filling the disk, and confirm a port is open before you escalate.
When a site is down, a first-line Linux engineer runs the same short checklist: is the service running, is the disk full, is the port listening, can the box reach what it needs. Each step is one or two commands. This lesson gives you that checklist and the output you should expect to see.
Services with systemctl
Modern distributions manage services with systemd. The commands you will use most:
systemctl status nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl enable --now nginx
systemctl is-active nginx
systemctl list-units --type=service --state=failed
status shows whether the unit is active, its process ID, and the last few log lines. restart stops and starts the process, which drops connections for a moment. reload asks the service to re-read its config without stopping, so prefer it for config changes when the service supports it. enable makes the service start at boot; it does not start it now unless you add --now. If a service fails right after a config edit, run nginx -t (or the equivalent check for that program) before restarting again.
Disk space
df -h
sudo du -xh --max-depth=1 /var | sort -h | tail
sudo du -sh /var/log/* | sort -h | tail -5
df -h shows each filesystem and its use percentage. Once you know which mount is full, du narrows it down one directory level at a time. Logs and old package caches are the usual culprits. If you delete a log that a running process still has open, the space is not released until the process restarts. Empty it instead with sudo truncate -s 0 /var/log/app/huge.log.
Ports and connectivity
ss -tulpn | grep :8080
curl -I http://localhost:8080/
curl -sS -o /dev/null -w "%{http_code}\n" https://api.example.com/health
ping -c 3 10.0.1.25
ip a
ss -tulpn lists listening TCP and UDP ports with the owning process. If nothing is on the port, the application is not up, no matter what the status page says. curl -I fetches only headers and proves the app answers locally. The third line prints just the status code, which is handy in scripts. Copy files with scp report.log user@host:/tmp/ when someone needs the evidence.
Common mistakes and a practice habit
- Running
systemctl enableand assuming the service started. - Restarting a service in a loop without reading
journalctl -u name -n 50first. - Deleting open log files and wondering why
dfdid not change. - Checking the port from your laptop and blaming the app when a firewall or security group is the real block. Test from the server itself first.
Practice habit. Install nginx or a small Python web server on a test machine. Break it on purpose: a bad config line, a full disk made with fallocate, a changed port. Each time, work through the checklist above until you find the cause without guessing.
More in Cloud and DevOps