Surviving a Reboot

Verifying That It Really Survives a Reboot

enabled is a promise, not a proof: reboot and look. On a server that is sudo reboot. Under WSL2 6 , run wsl --terminate Ubuntu-26.04 in PowerShell 55,538 and then any wsl -d Ubuntu-26.04 command, which boots the distribution's systemd 142,543 afresh.

After the restart: did hello-api come back by itself?Shell

systemctl show -p UserspaceTimestamp
systemctl status hello-api --no-pager
curl -s http://127.0.0.1:8105/

Output

UserspaceTimestamp=Wed 2026-09-23 13:35:51 +08
● hello-api.service - hello-api JSON status endpoint
     Loaded: loaded (/etc/systemd/system/hello-api.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/hello-api.service.d
             └─override.conf
     Active: active (running) since Wed 2026-09-23 13:35:52 +08; 5s ago
   Main PID: 214 (php)
...
{"app":"hello-api","env":"staging","pid":214,"php":"8.5.4","user":"helloapi"}

systemd started at 13:35:51 and hello-api a second later, with no command from you, as a new process (PID 214), with the drop-in applied and the secrets file read again ("env":"staging"). On a real server, journalctl -b -1 -u hello-api also shows how it stopped at the previous shutdown; under WSL, journalctl --list-boots shows only one boot because all distributions share one kernel boot ID.

When a service does not come back, check systemctl is-enabled and systemctl --failed, run systemd-analyze critical-chain on the unit to see what it waited on, and add Wants= beside After= for anything it needs at start, such as mysql.service.

MENU

Surviving a Reboot