Run a Linux service and find where startup stopped

The practice page is working, and its server is occupying your terminal. Every request appears there, but the prompt you wanted for the next command is still busy running Python.

Systemd, the service manager in the course’s Ubuntu virtual machine, can launch and track that program while you get your terminal back. It also keeps messages from a failed start. We will use that trail to follow a deliberately broken launch command back to a program name that does not exist.

This is the same synthetic lab service, not a production deployment. Use your ordinary account in the disposable guest. Complete the package lesson, stop its foreground server with Ctrl+C, and check that ~/linux-basics/service/index.html exists. The new service belongs to your user account; it is not a system-wide unit.

Give the manager the launch command

Systemd needs a saved description of the job, called a unit file. This one names the program, supplies its arguments and says what to do if it stops:

mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/dispatch-lab.service <<'UNIT'
[Unit]
Description=Dispatch learning HTTP service

[Service]
Type=simple
ExecStart=/usr/bin/python3 -m http.server 8080 --bind 127.0.0.1 --directory %h/linux-basics/service
Restart=no
UNIT
systemctl --user daemon-reload
systemctl --user start dispatch-lab.service
systemctl --user status dispatch-lab.service --no-pager
curl -i http://127.0.0.1:8080/

The long ExecStart line is the command you already recognize: run Python’s HTTP server on port 8080, bind it to the local address and serve the practice directory. Here %h expands to your home directory. The program runs as you, with your account’s access to those files.

The commands after the file do different jobs. daemon-reload tells the manager to read its unit files. start asks it to launch this service. status shows what it knows about the process. Editing a description and running the described program are separate events; reloading the unit file does not by itself restart the server.

The final curl command asks whether the page is available. With Type=simple, systemd does not wait for Python to announce readiness before considering the service started. Status may show active before the server has opened its socket, the endpoint where it accepts connections. If that first request is refused, inspect status and try again after a moment. A persistent refusal needs investigation; one early request may simply have arrived before the listener.

For now, Restart=no keeps the experiment easy to follow. When we break the command, there will be one failed attempt rather than a run of automatic restarts filling the journal.

If systemctl --user cannot reach the user bus, it cannot communicate with your user service manager. Check that systemd is running and that you are in a normal login session inside the Ubuntu guest. Adding sudo changes the account and unit location, not the missing session. A minimal container may lack the service environment this lab uses.

A missing page still gets an answer

journalctl --user -u dispatch-lab.service -n 30 --no-pager
curl -i http://127.0.0.1:8080/missing
journalctl --user -u dispatch-lab.service -n 10 --no-pager

The first journal command shows recent messages from this service. Next you request /missing, then read the newest messages. That path should return HTTP 404, meaning the requested resource was not found, while / still serves the practice page.

A disappointing page request has nevertheless established something useful: Python ran, received the request and answered it. Its request message goes to standard error, an output stream that systemd captures in the journal. Match the timestamp and path to the request you just made.

Now we can contrast that with a failure before Python even starts. There will be no Python request log in that case, because there will be no Python server to receive a request.

Break the name, not the web page

Stop the unit and copy its unit file to dispatch-lab.service.backup. In the original, replace /usr/bin/python3 with /usr/bin/python3-missing. Run daemon-reload, then start the service again.

Inspect status and the journal together. Depending on timing, the start command may report the failure itself or return before status shows it. Systemd’s message should identify an executable it could not run. The page and DNS are not yet the place to look: this attempt has not reached a web server.

Restore the backup, reload the manager’s description and start the service again. Then request /. Copying the original file back without reloading would leave the manager with the previous description. Checking status alone would leave the page untested. The successful HTTP request completes the connection from the repaired launch command to the page you wanted.

Keep the explanation after stopping the server

Save the unit path, the actual failure message and the successful request in your lab notes. When finished, stop the server with systemctl --user stop dispatch-lab.service. You have not enabled it for boot, and the user manager’s lifetime depends on the login environment.

The host computer’s services have stayed out of the experiment. Inside the disposable VM, you have seen a manager launch a program, a running program answer a missing-page request, and a launch fail before any request could arrive. Those are different points in the journey. The messages now give you a way to tell which one you have reached.

The service description and its journal

The systemd.service and systemd.unit manuals cover service lifecycle and unit specifiers. The journalctl manual explains how to inspect the recorded messages.