Looks like this is because the command takes longer than a minute to run, so the commands pile up until your system is starved of resources.
You can ensure that only one instance of that rsync
runs by using a lock file. util-linux
includes a file locking wrapper called flock
, which you can use in your crontab like so:
* * * * * /usr/bin/flock -n '/tmp/example.lock' -c 'rsync -azP /local_path [email protected]:/remote_path' > /dev/null
In the above example, the lock file path is /tmp/example.lock
, but you can set it to be anything sensible. -n
will prevent flock
commands from piling up because it'll exit immediately instead of wait for the lock to be released to continue.
Alternatively, you can also prevent your cron command from piling up by making a script with a fairly simple lock that ensures only one instance of the script can be running at a time:
#!/bin/bash
PIDFILE=/tmp/example.pid
if [ -f "$PIDFILE" ]
then
PID="$(cat "$PIDFILE")"
ps -p $PID > /dev/zero 2>&1
if [ $? -eq 0 ]
then
echo "Instance of this script is still running as PID $PID"
exit 1
fi
fi
echo $$ > $PIDFILE
if [ $? -ne 0 ]
then
echo "Could not create PID file: $PIDFILE"
exit 1
fi
# YOUR CODE GOES BELOW
rsync -az /local_path use[email protected]:/remote_path
# YOUR CODE GOES ABOVE
rm -f "$PIDFILE"
Locking mechanism inspired by Preventing duplicate cron job executions by Benjamin Cane
Note that the main limitation in the script is if the PID file isn't removed for whatever reason and another process has the same PID, the script will erroneously quit.
Save this script somewhere, like in /usr/local/bin/example.sh
, chmod +x /usr/local/bin/example.sh
, and then call it from your crontab like this:
* * * * * /usr/local/bin/example.sh > /dev/null