Start request repeated too quickly

systemd Service Restart Limit Reached: 3 Fixes That Work

Linux & Unix Intermediate 👁 11 views 📅 Jun 27, 2026

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 1 or signal=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:

  1. Save your changes.
  2. Run sudo systemctl daemon-reload.
  3. Run sudo systemctl restart myservice.service.
  4. Check the status: systemctl status myservice.service — should show active (running).
  5. 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

SymptomFix
Service crashes immediately with no logFix 1: extend restart interval
Service crashes but logs show "connection refused"Fix 3: add After= dependency
Service crashes only after a few hoursFix 1 or Fix 2, then investigate memory usage
Service crashes only when memory is lowFix 3: add memory limit in service file (MemoryMax=)
You don't care about restart limitsFix 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?