Stop systemd from blowing up your service when your dependencies arent ready

Technical Briefing | 8/29/2026

We have all been there. You write a nice service file, point it at a database or a network mount, and start it up. It fails immediately. You check the status, and it claims the service failed to start because the remote mount or the socket wasn’t available yet. systemd is fast, but it is not magic; it doesn’t know your app isn’t ready for a database that is still booting.

Why simple Wants or Requires wont save you

Most of us start by adding Requires=network-online.target or After=postgresql.service to our unit files. That works for standard local services. But the reality of modern cloud environments is that network targets are often reported as ready while the actual routing table is still shifting or the backend service is still in the middle of a TCP handshake. If your app attempts to connect during that gap, it will crash or exit, and systemd will mark it as dead.

systemctl edit --full my-service.service

Instead of relying solely on unit ordering, you should be baking resiliency into how the service restarts. If you force a hard failure, you’re creating a manual intervention requirement for a transient issue. Use Restart=on-failure and set a decent RestartSec to give your dependencies a fighting chance to come online.

• Use Restart=on-failure to ensure systemd handles the retry logic for you
• Set RestartSec to at least 5 or 10 seconds to avoid slamming a struggling database
• Add StartLimitBurst and StartLimitIntervalSec if you want to prevent endless retry loops that eat your CPU
• Consider using an ExecStartPre script that polls for your dependency’s readiness before the actual binary launches

Stop fighting the startup race condition by forcing your binary to be perfect on the first millisecond of execution. It is always better to have a process that waits patiently for five seconds than one that crashes and requires a sysadmin to ssh in and restart it at 3 AM. If you are still seeing race conditions, check the journal logs for the specific error code, and you will likely find that a simple retry delay is all you needed.