{"id":1466,"date":"2026-10-22T23:05:13","date_gmt":"2026-10-22T23:05:13","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1466"},"modified":"2026-10-22T23:05:13","modified_gmt":"2026-10-22T23:05:13","slug":"diagnosing-systemd-service-start-failures-after-reboot","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/diagnosing-systemd-service-start-failures-after-reboot\/","title":{"rendered":"systemd Services That Die After a Reboot: journalctl and Ordering Diagnostics"},"content":{"rendered":"\n

A unit that starts fine when you type systemctl start<\/code> and dies after a reboot has one of four causes, and each has a different fix. The efficient way to narrow it is not to read the unit file top to bottom but to query systemd for what it actually did at boot: whether the unit was pulled in, whether its dependencies were satisfied at that moment, and what exit status it produced when it was.<\/p>\n\n\n\n

This page works through that sequence using only systemctl<\/code> and journalctl<\/code>. It assumes a systemd 252 or newer guest, which is what Debian 12, Ubuntu 24.04 and current RHEL 9 ship with. If you are sizing an instance to run these services on, our VPS plan sizing by workload<\/a> covers how much RAM each service class needs beyond the unit file itself.<\/p>\n\n\n\n

First: Distinguish the Four Failure Classes<\/h2>\n\n\n\n
Symptom after reboot<\/th>Cause<\/th>Confirming command<\/th><\/tr><\/thead>
Unit not in systemctl list-units<\/code> at all<\/td>Never enabled<\/td>systemctl is-enabled myapp<\/code> → disabled<\/code><\/td><\/tr>
Unit listed but inactive (dead)<\/code><\/td>Started but exited 0, or Requires= dependency vanished<\/td>journalctl -b -u myapp<\/code><\/td><\/tr>
failed<\/code> with exit code 1<\/td>Application error at startup, often missing mount or network<\/td>systemctl show -p Result,ExecMainStatus myapp<\/code><\/td><\/tr>
Active, then dead minutes later<\/td>Ordering race: filesystem or network not ready when the unit ran<\/td>systemd-analyze critical-chain myapp.service<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Identify which row you are in before changing anything. The fix for row one (systemctl enable<\/code>) is wrong and mildly harmful for row four, where enabling is already done and the problem is ordering.<\/p>\n\n\n\n

Step 1: Read the Boot-Scoped Journal, Not the Current One<\/h2>\n\n\n\n

The most common journalctl mistake is omitting -b<\/code>. Without it you get every boot interleaved, and a failure from three weeks ago can look like the cause of today’s problem. List boots first, then filter.<\/p>\n\n\n\n

journalctl --list-boots | tail -5\njournalctl -b -1 -u myapp --no-pager | tail -40\njournalctl -b -u myapp -p warning --no-pager<\/code><\/pre>\n\n\n\n
-b -1<\/code> is the previous boot \u2014 the one that preceded the last reboot. -b -2<\/code> goes back further. -p warning<\/code> filters to severity warning and above, which removes the informational chatter that usually makes the useful line hard to find. Add -o short-precise<\/code> when you need millisecond ordering between two units.<\/p>\n\n\n\n
Step 2: Ask systemd Why, Not the Application<\/h2>\n\n\n\n
The application’s error message is often the second-order symptom. systemd’s own record of the start attempt contains the dependency that failed and the exact result code.<\/p>\n\n\n\n
systemctl show myapp.service -p Result -p ExecMainStatus -p ExecMainCode \\\n  -p ActiveEnterTimestamp -p InactiveEnterTimestamp\nsystemctl status myapp.service --no-pager -l\nsystemd-analyze critical-chain myapp.service<\/code><\/pre>\n\n\n\n
Result=exit-code<\/code> with ExecMainStatus=1<\/code> means the process ran and failed. Result=resources<\/code> means a limit was hit. Result=timeout<\/code> \u2014 with a service that takes 40 seconds to open a database connection \u2014 means TimeoutStartSec<\/code> is too short, which is common on busy hosts at boot when every service starts at once. Result=dependency<\/code> means something it Requires never came up.<\/p>\n\n\n\n
Step 3: Check the Three Ordering Traps<\/h2>\n\n\n\n
Almost all “works manually, fails at boot” reports come from one of these. Each has a specific unit-file fix.<\/p>\n\n\n\n
[Unit]\nDescription=My application\nAfter=network-online.target mysql.service\nWants=network-online.target\nRequires=mysql.service\nStartLimitIntervalSec=300\nStartLimitBurst=5\n\n[Service]\nUser=app\nWorkingDirectory=\/srv\/app\nExecStart=\/srv\/app\/bin\/server --config \/etc\/app\/config.yml\nRestart=on-failure\nRestartSec=5\n# Give slow dependencies time on a loaded host\nTimeoutStartSec=90\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\n