Repair the Linux lab when the server answers with the wrong thing

The server answers with HTTP 200. Where the practice page should be, you see a directory listing.

The request reached a running server and got a successful response, yet the thing you wanted did not arrive. This final Linux lab creates that disagreement deliberately. You will follow it back to the course files or launch settings, make a matching repair, and ask for the original page again.

Use only the synthetic course service inside your disposable Ubuntu VM. Finish the earlier package and user-service lessons first. Establish the starting state with systemctl --user start dispatch-lab.service, then curl -i http://127.0.0.1:8080/. Confirm that the practice page returns, save the response, and back up the unit file and page before changing either.

Change one thing so the result has one cause

Choose one of these scenarios. Repair it and return to the verified starting state before attempting another. Keep every change within the course files and user unit.

Scenario	Fault to introduce	What a useful investigation should distinguish
Missing content	Rename service/index.html to index.html.saved.	A responding HTTP server versus the expected page.
Wrong listener	Change 8080 to 8081 in the unit, reload and restart.	A live process versus the address the client uses.
Failed launch	Change /usr/bin/python3 to /usr/bin/python3-missing in the unit, run systemctl --user daemon-reload, then systemctl --user restart dispatch-lab.service.	A startup error versus a network error.

Renaming the page is a revealing first experiment. Python still has a directory to serve and may return its listing with HTTP 200. The connection and HTTP exchange succeeded, but the expected “Dispatch practice service” text is missing. A check that reads only the status code would accept the wrong result.

The other two faults interrupt different parts of the same request. Changing the port leaves a server running somewhere the client did not ask. Changing the executable path prevents it from launching. All three can look like a missing page in a browser, so the next useful question depends on what the request actually returned.

Follow the response to the next check

Write down the exact URL, time, expected content and actual response or connection error. These commands give you different views of the service:

systemctl --user status dispatch-lab.service --no-pager
journalctl --user -u dispatch-lab.service -n 30 --no-pager
ss -ltn
ls -l ~/linux-basics/service
systemctl --user cat dispatch-lab.service

Status tells you whether the process is running. The journal records what happened to it. The sockets show where it listens, the directory shows the files available to serve, and the unit describes how the program starts. There is no need to collect all five automatically. Choose the view that can answer the question raised by the last result.

Suppose curl reports a refused connection while status shows an active process. Look at the listener. Finding 127.0.0.1:8081 explains the mismatch: the server waits on 8081 while the client asks at 8080. Inspecting the unit file can show where that port came from. Restarting the unchanged unit would start the same mismatch again.

A directory listing leads somewhere else. Python has already received and answered the request, so changing the port would address a problem you do not have. Inspect the served directory and compare its filenames with the backup. The response has helped narrow the repair to the part that changed.

Ask for the original page, not a substitute

For missing content, restore the saved page. For a changed unit, restore its backup, run systemctl --user daemon-reload and restart the service. Then request the original URL and look for its original expected text. A command returning successfully, or a page working at a different address, does not yet show that the first request has been repaired.

If the result still differs, keep that new observation and reconsider the explanation. Repeating an unchanged restart adds little information; in more complex systems it can also destroy state that would have helped the investigation. Here the useful repair is the one that explains why the response changed.

Save the part worth keeping

Write a short account of the symptom, introduced fault, competing explanation, decisive observation, exact repair and successful check. Include what the test did not cover: this loopback page says nothing about a remote load balancer, authentication or a real export pipeline.

Restore the starting state and stop the service when finished. If you intend to delete the VM, first save the notes and backups outside it. The disposable guest let you create failures without leaving a customer waiting. The account you keep should let someone else follow how a successful-looking response turned out to be wrong, where the fault was found, and how the intended page returned.

The service behavior and the next investigation

The systemd documentation and Python http.server documentation explain the behavior used in this lab. Continue to Linux performance tuning once you can identify the process, resource and user-visible failure you want to improve.