We have all been there. You deploy a legacy Java app or a massive database migration tool, systemd fires it up, and then immediately kills it because the application didn’t signal readiness in the default 90 seconds. Watching your production deploy loop in a restart cycle because the service start timeout wasn’t tuned is one of those annoying, preventable wastes of time.

Why systemd kills your slow-starters

By default, systemd waits 90 seconds for a service to transition from starting to running. If your binary spends two minutes pre-allocating memory or indexing local files before it ever opens a port or hits a signal, systemd assumes the process hung and sends a SIGTERM. It is a guardrail that is usually helpful, but it’s completely silent about why it’s killing your process if you aren’t checking the journal for the specific transition state error.

systemctl set-property my-slow-service.service TimeoutStartSec=300

• Use Type=notify if your application supports sd_notify so systemd knows exactly when you are ready
• Avoid setting the timeout to infinity because you lose the protection against real deadlocks
• Check systemctl status right after a failed start to confirm it was a timeout and not a library link error

If you are overriding this in a drop-in file, remember that systemd merges these properties. Running the set-property command is safer than manual file edits because it handles the unit file reload for you immediately. If you find yourself constantly bumping this number, take a hard look at whether your application needs an actual health check script instead of just waiting for the daemon to stabilize.

Next time a deploy looks like it’s taking too long, don’t just tail the application logs. Check the cgroup state to see if the process is still sitting in the starting phase before you waste ten minutes debugging the wrong layer.