Stop systemd from silently waiting for units that will never start

Technical Briefing | 9/24/2026

We have all been there. You run a deployment script, restart a service, and then your shell hangs. You wait ten seconds, then thirty, watching the cursor blink while systemd hangs on a dependency that is stuck in a loop or simply doesn’t exist. By default, systemd will patiently wait for these dependencies to reach an active state for 90 seconds. If they don’t, it finally gives up, but that is 90 seconds of your life you aren’t getting back.

Why the default timeout is a trap

Most of the time, the default job timeout is fine. But if you are managing a cluster where services are chained together in complex dependency trees, one dead unit creates a cascading delay that kills your automation. It’s especially painful during PXE boots or automated provisioning where you want a fast failure rather than a long, agonizing wait.

systemctl show --property=DefaultTimeoutStartUSec

• Check systemd.conf for DefaultTimeoutStartSec to adjust the global behavior.
• Use JobTimeoutSec in individual unit files if you need to be surgical.
• Avoid using Requires for non-essential services unless you want them to stop everything else.

If you edit system.conf to lower this value, keep in mind you are changing the behavior for everything on the box. If you have a slow-starting database that actually takes 20 seconds to warm up, a global setting of 10 seconds will break your boot sequence. Don’t go blindly lowering these values without checking your longest startup time first.

Next time you find yourself staring at a hung terminal, use systemctl list-jobs to see what exactly is holding up the queue. Usually, it is a rogue Requires= line pointing to a service that failed to start five minutes ago. Clean up your dependencies, and stop letting systemd be the reason your deployment pipeline drags on.