Я использую rsync для резервного копирования некоторых данных с одного сервера на другой. Все работает нормально, но это может занять больше времени в зависимости от того, сколько данных нужно передать.
Есть ли какой-либо гарантированный способ гарантировать, что команда rsync не запускается до того, как предыдущая завершила работу с помощью cronjob?
Например, каждый час я запускаю команду rsync, но, возможно, передача занимает более 1 часа, поэтому следующая начнется раньше, чем закончится предыдущая.
Вы можете использовать стадо команда, которая поможет вам в этом, например В таком случае flock -n вероятно, это то, что вы хотите, так как это приведет к немедленному отказу команды, если она не может получить блокировку, например.
30 * * * * /usr/bin/flock -n /tmp/myRsyncJob.lck /path/to/your/rsyncScript
Вы можете реализовать какую-то блокировку. Это напечатает количество все еще работающих процессов rsync:
pgrep -cx rsync
И это запустит rsync, только если не существует другого процесса rsync:
pgrep -cx rsync || rsync ...
С помощью -x предотвратит случайное совпадение нежелательных имен (например, "foobarsyncхронизатор »или« not_an_rsync_totally "- работает так же, как pgrep -c ^rsync$)
Если вы хотите рассмотреть другие инструменты, вы также можете взглянуть на rdiff-резервное копирование. Он использует librsync для резервного копирования и сохраняет настраиваемое количество дельт / приращений. Он также блокируется, так что в любой момент времени может выполняться только один процесс rdiff-backup.
Вот что я бы сделал. Создайте сценарий оболочки вокруг rsync для создания файла блокировки.
script 1
- create lock file
- rsync
- remove lock file
script 2 (running later then script 1)
- check if lock file is there
- if not run
- if it is there wait 10 minutes in a loop. break out of lopp when the lock file is gone
- continue to run script
Мой ответ отчасти совпадает с тем, что сказал Майк.
В скрипте вы должны поместить что-то вроде этого:
Но есть одна очень важная вещь, которую вы должны сделать. и это для реализации системы ловушек.
Итак, что вы можете сделать, так это то, что даже если каким-то образом ваш скрипт был убит или кто-то убил его, вы можете перехватить этот сигнал и удалить файл блокировки, чтобы у вас не было устаревшего файла блокировки.
Вы можете прочитать, как это реализовать Вот.
Только одна мелочь, вы не можете поймать сигнал 9, я имею в виду, если кто-то kill -9, вы не можете перехватить это, поскольку этот сигнал напрямую взаимодействует с ядром, и нет способа перехватить это.
Кроме того, как предложил Джон, вам необходимо удалять файл блокировки каждый раз при перезагрузке системы, просто чтобы убедиться, что не осталось устаревшего файла.
Это легко сделать, поставив небольшой rm -f <FILE> команда в /etc/rc.local
Взгляните на anacron (анахроничный cron) с переключателем -s (сериализовать). Serialize гарантирует, что команда не будет вызвана снова, если предыдущая все еще выполняется.
Используйте hatools (http://www.fatalmind.com/software/hatools/), чтобы заблокировать rsync cron в режиме ожидания.
Мне не удалось заставить решение mgabriel работать на OSX, поскольку версия pgrep для OSX, похоже, не имеет опции -c (я предполагаю, что это для подсчета). Вместо этого я использовал следующее:
[ $(pgrep ping | wc -l) -eq 0 ] && ping multiplay.co.uk || echo "Sorry, ping already in progress"
Я использовал ping в качестве примера команды.
Надеюсь это поможет.