Load and start a new unit

systemd does not automatically reread every changed unit file. It keeps a parsed copy in memory, so you have to tell the manager when unit definitions change. Forgetting that step is the most common systemd mistake there is.

The sequence

systemd-analyze verify /etc/systemd/system/demo-api.service
sudo systemctl daemon-reload
sudo systemctl start demo-api.service
systemctl status demo-api.service
journalctl -u demo-api.service -b

systemd-analyze verify catches syntax errors, unknown directives, and missing executables before anything runs. Then daemon-reload makes the manager reread unit files, start runs the service once, and status plus the journal confirm the main PID exists and the application logged a healthy startup.

Two failures you will hit

If you edit a unit and restart without reloading, systemd runs the old definition and tells you so:

Warning: The unit file, source configuration file or drop-ins of
demo-api.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Read the warnings in systemctl status. This one means the running service and the file on disk disagree.

The other classic is a wrong WorkingDirectory=. The process never starts, and the journal names the exact step that failed:

demo-api.service: Changing to the requested working directory failed: No such file or directory
demo-api.service: Failed at step CHDIR spawning /usr/bin/node: No such file or directory
demo-api.service: Main process exited, code=exited, status=200/CHDIR

Exit statuses in the 200 range come from systemd itself, before your program ran. status=200/CHDIR points at the directory, 203/EXEC at the executable path or permissions.

Enable only after it works

Enabling a broken service just schedules a failure for the next boot. Once the current start works, wire it into boot and verify the state:

sudo systemctl enable demo-api.service
systemctl is-enabled demo-api.service   # enabled

Follow the complete sequence with a disposable service. Reboot only in a test environment; on a real server, systemctl is-enabled is enough to verify the intended boot state.