Fix a service that will not start, and one that starts but cannot serve

short · 40 min · Objective 4.2

Task

Break nginx on lin-b in two different ways -- another program already holding its port, so it will not start, and a web root its worker cannot read, so it starts and serves nothing -- and diagnose each from the service's status and logs, not from memory of what you broke. Name the process holding the port by its ID, and the file the service could not open.

Steps

  1. Stop nginx, start python3 -m http.server 80 in the background, then try to start nginx. Save systemctl status nginx and journalctl -u nginx -n 20 to lab/app/port-conflict.txt.
  2. Find the process holding port 80 with ss -tlnp and save the line to lab/app/holder.txt. Stop it and start nginx.
  3. Stop nginx and make its web root unreadable to the worker with chown root:root and chmod 700 on the directory the default site's root names (/var/www/html on Ubuntu, /usr/share/nginx/html on Rocky). Start nginx -- it starts, because the master process runs as root and opens the logs itself; only the worker, running as www-data or nginx, reads the content -- then request the page with curl -i http://localhost/. Save systemctl status nginx, the curl output and tail -n 5 /var/log/nginx/error.log to lab/app/permission.txt.
  4. Restore the web root's owner and permissions and check the page loads.
  5. Record both diagnoses in lab/app/diagnosis.csv with header symptom,evidence,cause,fix.

Verify

These checks run in a POSIX shell: Terminal on macOS or Linux, and on Windows Git Bash (it comes with Git for Windows) or WSL. A stock Windows PowerShell or Command Prompt has no awk or grep, so there the first line fails.

grep -Eic 'Address already in use' lab/app/port-conflict.txt
grep -Eo 'pid=[0-9]+' lab/app/holder.txt
grep -Eic 'Permission denied|failed [(]13' lab/app/permission.txt
grep -c '403 Forbidden' lab/app/permission.txt
awk -F, 'NR>1 {n++} END {print n" diagnosis row(s)"}' lab/app/diagnosis.csv

The first failure's journal says the address is already in use and the holder line names a process ID; the second's error log says permission denied, error 13, and names the file, while the page came back 403 Forbidden. Neither status line gave the cause: the first said only "failed", and the second said "active (running)" while every request failed. The cause was in the service's own log, which is why reading it comes before any theory.

Notes

If nginx had also been configured not to start at boot, or had a dependency on a service that failed, systemctl status would say so. On Windows, the System log's Service Control Manager events carry the same information.

This is an independent study companion for CompTIA Server+ SK0-005 and is not produced by or endorsed by CompTIA.