Decoding the “Start request repeated too quickly” Error with rclone and systemd

At revWhiteShadow, we understand the frustration that arises when automated processes, especially those critical for data backup, encounter unexpected errors. One such perplexing issue is the “Start request repeated too quickly” error observed in conjunction with rclone and systemd user services. This error can be particularly baffling when your configured retry logic within systemd appears sound, yet the service continues to be flagged for rapid restarts. We’ve delved deep into this specific problem, analyzing the provided configurations and logs to offer a comprehensive explanation and actionable solutions that aim to outrank any other resource you might find on this topic.

Understanding the Core of the “Start request repeated too quickly” Error

The “Start request repeated too quickly” error in systemd is a protective mechanism designed to prevent a runaway service from overwhelming the system. When a service fails repeatedly and attempts to restart in quick succession, systemd intervenes, stopping further restarts to conserve resources and avoid potential system instability. The StartLimitIntervalSec and StartLimitBurst directives within a systemd service unit control this behavior. Your configuration correctly sets StartLimitBurst=5 and StartLimitIntervalSec=12h, indicating that systemd should allow up to 5 restarts within a 12-hour window before preventing further attempts.

The critical observation from your journalctl logs is the recurring error message preceding the “Start request repeated too quickly” error: “lookup api.dropboxapi.com: no such host”. This DNS resolution failure is the root cause of your rclone command’s inability to connect to Dropbox. The “Start request repeated too quickly” error is not an independent issue; it’s a consequence of rclone failing repeatedly due to a persistent network problem. systemd, seeing these repeated failures from the rclone service, is applying its protective throttling.

Analyzing the rclone and systemd Unit Configurations

Let’s break down your provided unit files and logs to pinpoint the interaction leading to this error.

#### The rclone-copy-dropbox.timer Configuration 

[Install]
WantedBy=timers.target

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=10m

[Unit]
Description=rclone copy to dropbox
  • OnCalendar=daily: This directive schedules the timer to activate once a day. The exact time is determined by the system’s clock and potentially influenced by RandomizedDelaySec.
  • Persistent=true: This is a crucial setting for laptops or systems that might not be running at the scheduled time. If the system is off when the timer is supposed to trigger, Persistent=true ensures that the associated service will be started as soon as possible after the system boots up or the timer becomes active again.
  • RandomizedDelaySec=10m: This adds a random delay of up to 10 minutes to the OnCalendar event. This is good practice to avoid thundering herd problems if you had multiple scheduled tasks.

#### The rclone-copy-dropbox.service Configuration 

[Service]
ExecStart=rclone copy dropbox: /home/me/dropbox --bwlimit 10M:20M --config=/home/me/rclone.conf
Restart=on-failure
RestartSec=10m
Type=oneshot

[Unit]
After=graphical-session-pre.target
Description=rclone copy dropbox
OnFailure=notify-email@%n.service
StartLimitBurst=5
StartLimitIntervalSec=12h
Wants=graphical-session.target
X-RestartIfChanged=false
  • ExecStart=rclone copy dropbox: /home/me/dropbox --bwlimit 10M:20M --config=/home/me/rclone.conf: This is the command that rclone executes. It attempts to copy files to your Dropbox.
  • Restart=on-failure: This tells systemd to restart the service if the ExecStart command exits with a non-zero status code, indicating an error.
  • RestartSec=10m: This specifies a 10-minute delay between restart attempts if Restart=on-failure is triggered.
  • Type=oneshot: This indicates that the service performs a single action and then exits.
  • After=graphical-session-pre.target and Wants=graphical-session.target: These dependencies ensure that the graphical environment is at least starting or is ready before the rclone service attempts to run. This is generally a good idea, especially if network initialization is tied to the graphical session.
  • StartLimitBurst=5 and StartLimitIntervalSec=12h: As discussed, these are the throttling parameters for rapid restarts.
  • OnFailure=notify-email@%n.service: This is a good addition for alerting you when the service fails permanently.

#### Interpreting the journalctl Output

The journalctl output is the most revealing. Let’s focus on the sequence of events:

  1. Initial Failure: The service starts, but rclone immediately fails with a “no such host” error. This means the system couldn’t resolve api.dropboxapi.com to an IP address. This typically points to a DNS issue.
  2. Multiple Attempts by rclone: rclone itself has internal retry logic (implied by “Attempt 1/3 failed”). It tries three times, but the underlying DNS problem persists.
  3. Service Failure: rclone exits with a failure status (status=1/FAILURE).
  4. systemd’s Restart=on-failure: systemd sees the failure and, because Restart=on-failure is set, schedules a restart after RestartSec=10m.
  5. The Crucial Moment:
    • Jan 09 07:15:44 yoga systemd[8306]: rclone-copy-dropbox.service: Main process exited, code=exited, status=1/FAILURE
    • Jan 09 07:15:44 yoga systemd[8306]: rclone-copy-dropbox.service: Failed with result 'exit-code'.
    • Jan 09 07:15:44 yoga systemd[8306]: Failed to start rclone copy dropbox.
    • Jan 09 07:25:44 yoga systemd[8306]: rclone-copy-dropbox.service: Scheduled restart job, restart counter is at 1.
    • Jan 09 07:25:44 yoga systemd[8306]: Stopped rclone copy dropbox.
    • Jan 09 07:25:44 yoga systemd[8306]: rclone-copy-dropbox.service: Start request repeated too quickly.
    • Jan 09 07:25:44 yoga systemd[8306]: rclone-copy-dropbox.service: Failed with result 'exit-code'.
    • Jan 09 07:25:44 yoga systemd[8306]: Failed to start rclone copy dropbox.

Notice the timestamps: the first failure happens at 07:15:44. The system schedules a restart for 07:25:44 (10 minutes later). At 07:25:44, the service attempts to start again. However, the log shows “Start request repeated too quickly” immediately after. This implies that systemd perceived a restart attempt happening too soon after the previous failure, even though the RestartSec=10m should have been respected.

Why the discrepancy? The “Start request repeated too quickly” message typically appears when systemd itself is attempting to reschedule a service that has failed and is under its restart throttling. The error message itself is a bit misleading in this context; it’s not necessarily that the service is trying to restart too quickly, but that systemd’s internal mechanism for managing repeated restarts is being triggered.

Given that the RestartSec=10m is explicitly set, and the log shows the service starting again after exactly 10 minutes, the “Start request repeated too quickly” message here is likely a symptom of systemd detecting a pattern of rapid failures within its own internal state management, rather than a direct violation of RestartSec. The key is that the underlying cause (DNS failure) is still present on this second attempt.

Pinpointing the Root Cause: Network and DNS Issues

The persistent “no such host” error strongly indicates a problem with your system’s ability to perform Domain Name System (DNS) lookups. This is particularly relevant in your scenario involving a laptop that is woken from sleep.

#### DNS Resolution on Laptop Wake-Up

When a laptop wakes from sleep, several subsystems are reinitialized, including the network stack. It’s common for network interfaces to take a few seconds to become fully functional, acquire an IP address, and establish DNS resolution capabilities. Your description explicitly mentions: “If I wake up the laptop, it takes a few seconds until the network is up. It is therefore expected, that the first attempt after wake up fails.”

The problem is that while you expect the first attempt to fail, the current systemd configuration is too aggressive in its interpretation of repeated failures once the underlying cause persists across restarts.

#### Potential Network/DNS Configuration Issues

Several factors can contribute to DNS lookup failures, especially after sleep:

  • DHCP Lease Renewal: When the network interface reinitializes, it might be renewing its DHCP lease. If the DHCP server or its responses are slow, DNS settings might not be immediately available.
  • NetworkManager or systemd-networkd Delays: These services manage network configurations. If there are delays in them properly configuring DNS resolvers after sleep, rclone will fail.
  • Firewall Rules: Less likely for DNS, but sometimes aggressive firewalls can interfere.
  • DNS Server Availability: The DNS servers configured on your system might be temporarily unavailable or slow to respond.
  • Systemd-networkd vs. NetworkManager Conflicts: If both are trying to manage the network, they can sometimes interfere.

Solutions to Resolve “Start request repeated too quickly” and rclone Failures

The primary goal is to ensure that rclone has a stable network connection and successful DNS resolution before it attempts to run. The “Start request repeated too quickly” error will then naturally disappear as the underlying rclone failures cease.

#### Solution 1: Enhancing Service Dependencies for Network Readiness

The most robust solution is to explicitly tell systemd that your rclone service depends on a fully functional network. While After=graphical-session-pre.target and Wants=graphical-session.target are present, these don’t guarantee network connectivity.

We need to add dependencies that signal network readiness. A common target for this is network-online.target.

Modified rclone-copy-dropbox.service:

[Unit]
Description=rclone copy to dropbox
# Ensure network is fully online before attempting to run
Wants=network-online.target
After=network-online.target
# Also keep graphical session dependencies if they are relevant for your network setup
After=graphical-session-pre.target
Wants=graphical-session.target
OnFailure=notify-email@%n.service
# The StartLimit directives are still relevant for preventing runaway processes,
# but the primary issue is the underlying error.
StartLimitBurst=5
StartLimitIntervalSec=12h

[Service]
# Set Type to simple if rclone forks, otherwise oneshot is fine.
# Assuming rclone runs as a foreground process here.
Type=oneshot
ExecStart=/usr/bin/rclone copy dropbox: /home/me/dropbox --bwlimit 10M:20M --config=/home/me/rclone.conf
# Increased RestartSec for a more patient retry, although the dependency should handle it.
Restart=on-failure
RestartSec=20m # Increased from 10m to give more buffer

[Install]
WantedBy=default.target

Explanation of Changes:

  • Wants=network-online.target: This makes network-online.target a weak dependency. It means that network-online.target will be started if it’s not already active, but the rclone service will start even if network-online.target fails.
  • After=network-online.target: This ensures that your rclone service starts after network-online.target has been reached. network-online.target is a systemd unit that is typically activated when the network is considered “online” (e.g., has an IP address and can potentially reach remote hosts).

Important Note: For network-online.target to work correctly, your network management service (like NetworkManager or systemd-networkd) must be configured to emit this target when the network is ready. This is usually the default behavior.

#### Solution 2: Adjusting RestartSec and StartLimitIntervalSec for More Patience

While the dependency fix is paramount, you can also slightly adjust the retry timing to be more forgiving, especially considering the laptop wake-up scenario.

  • Increase RestartSec: You already have RestartSec=10m. Increasing this further, for example, to 20m or 30m, might give the network more time to stabilize after a wake-up event before another restart is attempted. However, the core issue is still the StartLimit preventing retries after multiple rapid failures.
  • Adjust StartLimitIntervalSec: If the “Start request repeated too quickly” error persists even with the network-online.target dependency, you might consider a larger StartLimitIntervalSec if your RestartSec is very small. However, your current 12h interval is generous. The problem is the burst.

The primary trigger for “Start request repeated too quickly” is when systemd detects too many failed attempts within the StartLimitIntervalSec. The current setup should be fine, but if the network initialization is consistently taking longer than RestartSec, and then the service fails again, and then systemd immediately re-evaluates its state, the “too quickly” can be hit.

Let’s reconsider the order of operations:

  1. Service starts.
  2. Network is down (DNS fails).
  3. Service exits with failure.
  4. systemd notes failure.
  5. systemd waits RestartSec.
  6. systemd attempts to start service again.
  7. If network is still down, it fails again.
  8. Now, systemd counts this as a rapid repeat within its internal tracking.

Adding network-online.target should prevent step 6 from happening until the network is ready, thus breaking the cycle.

#### Solution 3: Explicitly Waiting for DNS Resolution

If network-online.target alone isn’t sufficient (though it usually is), you can add a small sleep command within the ExecStart to give DNS a final chance to come online. This is less elegant but can be a fallback.

Modified rclone-copy-dropbox.service (using a wrapper script):

First, create a small wrapper script, for example, /home/me/scripts/rclone_dropbox_backup.sh:

#!/bin/bash

# Give network a moment to ensure DNS is resolvable
sleep 30 # Adjust this value as needed

# Execute the rclone command
/usr/bin/rclone copy dropbox: /home/me/dropbox --bwlimit 10M:20M --config=/home/me/rclone.conf

exit $? # Exit with the status of the rclone command

Make the script executable: chmod +x /home/me/scripts/rclone_dropbox_backup.sh

Then, update your rclone-copy-dropbox.service file:

[Unit]
Description=rclone copy to dropbox
Wants=network-online.target
After=network-online.target
After=graphical-session-pre.target
Wants=graphical-session.target
OnFailure=notify-email@%n.service
StartLimitBurst=5
StartLimitIntervalSec=12h

[Service]
Type=oneshot
ExecStart=/home/me/scripts/rclone_dropbox_backup.sh
Restart=on-failure
RestartSec=20m

[Install]
WantedBy=default.target

Explanation:

  • The wrapper script introduces a sleep 30 (you can tune this 30 seconds). This delay occurs after systemd has determined the network is online (via network-online.target), providing an additional buffer for DNS servers to become fully responsive.

#### Solution 4: Checking DNS Configuration Directly

If none of the systemd adjustments work, the problem might be deeper within your system’s DNS setup.

  • /etc/resolv.conf: Ensure this file is being updated correctly by your network manager.
  • systemd-resolved: If you are using systemd-resolved, check its status:
    systemctl status systemd-resolved
resolvectl status
  • NetworkManager Configuration: If you use NetworkManager, check its logs and configuration for any delays or issues.
  • Manual DNS Settings: Ensure your DNS servers are reachable. You can test DNS resolution manually from your terminal:
    ping api.dropboxapi.com
host api.dropboxapi.com
nslookup api.dropboxapi.com
    If these commands fail after waking your laptop, the issue is with your system’s network configuration, not rclone or systemd directly.

Revisiting the Persistent=true Interaction

Your Persistent=true in the timer is designed to ensure that if the system was off, the timer runs once it’s back on. When you wake your laptop, the Persistent flag might also play a subtle role. If the timer’s scheduled time has passed while the laptop was asleep, systemd will consider it “pending” and attempt to run it upon waking or upon the next timer evaluation. Combined with network initialization delays, this can lead to scenarios where the service is triggered, finds no network, fails, and then the rapid restart throttling kicks in.

The network-online.target dependency is the most robust way to synchronize the service start with actual network availability, irrespective of the Persistent flag’s behavior on wake-up.

Final Recommendation and Strategy

We recommend implementing Solution 1: Enhancing Service Dependencies for Network Readiness by adding Wants=network-online.target and After=network-online.target to your rclone-copy-dropbox.service file. This is the most idiomatic and effective way to address service startup timing issues related to network availability in systemd.

If the problem still persists after applying this change, then consider Solution 3: Explicitly Waiting for DNS Resolution using a wrapper script with a sleep command as a secondary measure.

The “Start request repeated too quickly” error is a symptom of repeated underlying failures. By ensuring your rclone service only runs when the network is verifiably online and DNS resolution is functional, you eliminate the root cause of the repeated failures, and thus, the throttling error will be resolved. Always remember to reload your systemd daemon after modifying unit files:

systemctl --user daemon-reload
systemctl --user restart rclone-copy-dropbox.timer

By carefully configuring dependencies and understanding the interplay between systemd’s retry mechanisms and network service availability, you can achieve reliable, automated backups with rclone. This comprehensive approach, focusing on the core network dependency, will ensure your automated tasks function as expected, even on a mobile setup.