Explain systemd service code

What this systemd service sample shows

[Unit], [Service] and [Install]

[Unit] names the service and sets its order, [Service] says what to run and how, and [Install] is ignored while the service runs: systemctl --user enable and disable read it (systemd.unit). Enabling it created a link to the file in default.target.wants, the list of what your user session starts. systemd-analyze --user verify printed nothing for this file and exited with code 0.

WorkingDirectory= and ExecStart=

ExecStart= is the command, with the full path to the program. %h is your home folder, so python3 started in ~/apps/notes-api and found app.py there. With that folder missing, systemd printed Changing to the requested working directory failed and Failed at step CHDIR, then scheduled a restart because of Restart=on-failure, which failed the same way.

Environment= and EnvironmentFile=

Environment= set APP_ENV=production and PORT=8040, and the app reported both. A .env file with PORT=8041 won over that line: the app moved to 8041 and 8040 stopped answering. The - before the path makes the file optional. Without it, a missing .env stopped the start with Failed to load environment files: No such file or directory.

Restart= and RestartSec=

Restart=on-failure brings the service back when it exits with an error. When the app exited with code 1, systemd logged status=1/FAILURE, then Scheduled restart job, restart counter is at 1, and after the 2-second RestartSec= wait a new process, with a new PID, answered. When the app exited with code 0, it stayed stopped, because a clean exit isn't a failure.

Good to know

• Run with systemd 261 and Python 3.14.7 on Linux as a user service, with no root: systemctl --user link pointed systemd at the file and systemctl --user start notes-api started it. app.py is a short test server that reports its settings and exits with code 1 or 0 on request.
• After an edit to the file, systemctl --user status warned that the unit file changed on disk and said to run systemctl --user daemon-reload to load the new version.
• After=network.target does nothing in a user service. After= only sets the order and doesn't start anything by itself (systemd.unit), and network.target belongs to the system service manager: it isn't in the user manager's list of units (systemd.special), and systemctl --user show network.target printed LoadState=not-found. default.target is the main target of the user service manager (systemd.special).

Watch out: Restart=on-failure gives up on a service that keeps crashing. With RestartSec=0 and the app crashing each time it came back, systemd restarted it 4 times, refused the 5th with Start request repeated too quickly and left it failed, with nothing on port 8040. This file doesn't set a limit, so systemd's defaults applied: 5 starts in 10 seconds (StartLimitBurst= and StartLimitIntervalSec=). After fixing the cause, systemctl --user reset-failed notes-api clears that state so you can start it right away.