systemd Service Restart Limit Reached: 3 Fixes That Work
Your systemd service keeps crashing and hitting the restart limit. Here are 3 fixes, from quick to deep.
What's Happening?
You're running a service with systemctl and you see something like:
systemd[1]: myservice.service: Start request repeated too quickly.
systemd[1]: myservice.service: Failed with result 'start-limit'.
That's systemd's way of saying: "I tried starting this service a bunch of times, but it crashed every time, so I'm giving up."
This usually happens when:
- The service itself is broken and keeps crashing right after starting.
- The service depends on something (like a database or a network) that isn't ready yet.
- You changed something in the service file and forgot to reload systemd.
Here's the fix. Start with the simplest one and work your way down. You can stop when the service starts and stays running.
Fix 1: Extend the Restart Interval (30 seconds)
Your service isn't broken — it just needs more time between restart attempts. Systemd by default only allows 5 restarts in 10 seconds. That's too fast for services that take a moment to initialize.
Step 1: Open the systemd service file. Run:
sudo systemctl edit myservice.service
Replace myservice with your actual service name.
What to expect: This opens a blank file in a text editor (likely nano). This file is an override — it only adds or changes what you put in it.
Step 2: Paste these exact lines:
[Service]
RestartSec=30s
StartLimitIntervalSec=120s
StartLimitBurst=3
What these do:
RestartSec=30s— wait 30 seconds between restart attempts.StartLimitIntervalSec=120s— check the restart count over a 2-minute window.StartLimitBurst=3— allow 3 failures in that window before giving up.
Step 3: Save the file and exit. In nano, that's Ctrl+O then Ctrl+X. In vim, :wq.
Step 4: Reload systemd and restart the service:
sudo systemctl daemon-reload
sudo systemctl restart myservice.service
What you should see:
- No errors.
- The service status shows
active (running). - If the service crashes again, it'll wait 30 seconds before trying again.
Test it: run systemctl status myservice.service. If it's green and alive, you're done. If it still shows the start limit error, move to Fix 2.
Fix 2: Disable the Restart Limit Entirely (5 minutes)
If the service needs to restart immediately after a crash (like a critical system service), you can turn off the limit completely. I don't recommend this for user services — it can hide real problems. But for services you trust and actively maintain, it works.
Step 1: Open the same override file:
sudo systemctl edit myservice.service
Step 2: Replace everything with:
[Service]
Restart=always
RestartSec=5s
StartLimitIntervalSec=0
The key line is StartLimitIntervalSec=0. That disables the rate limiting. The service can restart as many times as it wants.
Step 3: Save, exit, reload systemd, restart the service:
sudo systemctl daemon-reload
sudo systemctl restart myservice.service
What you should see: The service starts immediately. If it crashes, systemd restarts it within 5 seconds. No limit error.
Warning: This can cause a restart loop that fills your logs with the same error every 5 seconds. Only use this if you're actively debugging the service and restarting it manually. Once the service is stable, set StartLimitIntervalSec back to a reasonable number (like 60s).
Still stuck after this? The service is probably genuinely broken. Move to Fix 3.
Fix 3: Fix the Service Itself (15+ minutes)
systemd's restart limit is just a symptom. The real problem is that the service keeps crashing. You need to figure out why.
Step 1: Check the service log. Run:
journalctl -u myservice.service -n 50 --no-pager
This shows the last 50 log entries for that service.
What to look for:
- Exit codes like
exit code 1orsignal=SEGV. - Error messages like
Connection refused,Permission denied,File not found. - Timestamps — if it crashes every 5 seconds exactly, it's probably a dependency issue.
Step 2: Look at the full error. For example, if you see Can't connect to MySQL, your service needs the database to be running first. Fix the dependency in the service file:
[Unit]
Description=My App
After=mysql.service
Requires=mysql.service
Then reload and restart.
Real-world scenario: I had a web app service that kept hitting the restart limit. The log showed Cannot open /var/log/myapp.log: Permission denied. The service user didn't have write access to that directory. Fixed it with:
sudo chown myappuser:myappuser /var/log/myapp.log
sudo chmod 644 /var/log/myapp.log
After that, the service started and stayed up. No restart limit issues.
Step 3: If you can't figure out the error, show the full logs to someone who knows the app. Or try running the service command manually to see the error in real time:
sudo -u myserviceuser /path/to/myservice --debug
That often reveals the root cause instantly.
After fixing the underlying issue:
- Save your changes.
- Run
sudo systemctl daemon-reload. - Run
sudo systemctl restart myservice.service. - Check the status:
systemctl status myservice.service— should showactive (running). - Test that the service actually works (make a request, check the port, etc.).
If the service still crashes after fixing the root cause, you might have a bigger problem — like a memory leak or a broken binary. In that case, roll back your last change to the service or update the app.
Quick Reference: Common Fixes By Symptom
| Symptom | Fix |
|---|---|
| Service crashes immediately with no log | Fix 1: extend restart interval |
| Service crashes but logs show "connection refused" | Fix 3: add After= dependency |
| Service crashes only after a few hours | Fix 1 or Fix 2, then investigate memory usage |
| Service crashes only when memory is low | Fix 3: add memory limit in service file (MemoryMax=) |
| You don't care about restart limits | Fix 2: disable limit entirely |
That's it. Start with Fix 1. Most people stop there. If not, Fix 3 is the real solution. Your systemd service will stay running after this.
Was this solution helpful?