Score:0

How do we find where the rsync is scheduled and how can we reschedule it?

cn flag

How do we find where the rsync is scheduled? I have a rsync that's done in server A to server B, and I need to find in server A where rsync is called and where and how it's scheduled. Is there a file for this where the config are set like for cronjobs? I have some performance issues in server B and I need to reschedule the rsync so that it only happens outside of peak hours.

in flag
I would probably start with something simple like `grep 'rsync' -R /etc /var/spool/cron /var/log`. Assuming the job or script contains the name 'rsync' that is probably likely to find either the cron log entry or the crontab, or maybe a script. If you know when it starts, you could look at your logs, and see cron running the task, assuming cron is running it.
Score:2
pt flag

Sadly rsync doesn't automatically log somewhere every time it is being used. Some detective work will be required.

A good bet is that rsync is being run from "cron" somewhere. (cron is a system that periodically runs a command line or script. For example, I have an hourly cron job that updates a database, and a daily cron job that runs my backup scripts.)

Cron (actually crond) keeps a log of all the commands ("jobs") that it runs in /var/log/cron. (Some Unix/Linux systems put it in a different place. Check the man page.) You can cat that file to examine it (it is a textfile.)

Cron's configuration is stored in /etc or /var/spool/cron or both depending on your Unix/Linux system. The man page will help, as will doing something like

find /etc /var -name '*cron*'

You can look for rsync in those files by doing something like:

grep rsync -R /etc /var/spool/cron

However the cron job might be calling a script which calls rsync. That script name might not include the letters "rsync". It might be called "backup" or "update" or maybe it is named after the system the data is being pushed too or pulled from.

If your system uses "systemd", there is a chance that it is being run from there. Check those configurations by greping /etc recursively.

If none of that works there are two "desperation mode" things you could do.

  1. Remove the rsync command to force the backup to fail. The error message might appear in email (cron emails the owner of the job when something goes wrong) or in syslog. You could just do:
mv /usr/bin/rsync /usr/bin/rsync.NOT
# wait a while, see what happens.

# Revert the change
mv /usr/bin/rsync.NOT /usr/bin/rsync
  1. Replace rsync with a wrapper script that logs what it is doing then calls the real rsync.

Create a file called /usr/bin/rsync.wrapper which contains:

#!/bin/sh
echo "$@" >>/var/tmp/my.rsync.log
pwd >>/var/tmp/my.rsync.log
exec /usr/bin/rsync.REAL "$@"

Now install the wrapper:

touch /var/tmp/my.rsync.log
chmod a+w /var/tmp/my.rsync.log
chmod a+rx /usr/bin/rsync.wrapper
mv /usr/bin/rsync /usr/bin/rsync.REAL
ln -s /usr/bin/rsync.wrapper /usr/bin/rsync

When you are done, revert those changes with

rm /usr/bin/rsync
mv /usr/bin/rsync.REAL /usr/bin/rsync

FYI: I don't recommend these last 2 ideas (removing rsync, using a wrapper). They are dangerous and could mess up your system. However, if all else fails, the wrapper solution should do the trick!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.