HomebaseWorks
Lesson 4 of 4

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.

EWritten by the HomebaseWorks editorial team · reviewed 26 Oct 2026

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.

Advertisement

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 enable and assuming the service started.
  • Restarting a service in a loop without reading journalctl -u name -n 50 first.
  • Deleting open log files and wondering why df did 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.

Advertisement
Continue with Linux4 lessons · 1 interview set · 1 test · 1 certificate
Not tested

More in Cloud and DevOps