змусити чекати роботу, коли завершиться попередня робота rsync

Я використовую rsync для резервного копіювання деяких даних з одного сервера на інший. Все працює нормально, але це може зайняти більше часу, залежно від того, скільки даних потрібно передати.

Чи є якийсь гарантований спосіб переконатися, що команда rsync не запускається до того, як попередня закінчила використання cronjob?

Наприклад, щогодини я запускаю команду rsync, але її можлива передача займає більше 1 години, тому наступна розпочнеться до завершення попередньої.

Ви можете реалізувати якесь блокування. Це надрукує кількість процесів rsync, які все ще запущені:

pgrep -cx rsync

І це запустить rsync, лише якщо немає іншого процесу rsync:

pgrep -cx rsync || rsync ...

Використання -xзапобіжить випадковому зіставленню небажаних імен (наприклад, "fooba rsync hronizator" або "not_an_ rsync _totally" - воно працює так само pgrep -c ^rsync$)

Ви можете скористатися командою flock, щоб допомогти вам це зробити. Наприклад, це flock -n, мабуть, те, що ви хочете, оскільки це спричинить негайний збій команди, якщо він не може отримати блокування, наприклад

30 * * * *  /usr/bin/flock -n /tmp/myRsyncJob.lck /path/to/your/rsyncScript 

Якщо ви готові розглянути інші інструменти, ви також можете ознайомитися з rdiff-backup . Він використовує librsync для створення резервних копій і зберігає настроювану кількість дельт / приростів. Він також блокується, щоб у будь-який момент часу міг працювати лише один процес резервного копіювання rdiff.

Ось що б я зробив. Створіть сценарій обгортки навколо 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

Погляньте на анакрон (анахронічний крон) за допомогою перемикача -s (серіалізувати). Serialize гарантує, що команда не буде викликана знову, якщо попередня програма все ще виконується.

Використовуйте hatools ( http://www.fatalmind.com/software/hatools/ ), щоб заблокувати rsync cron у режимі очікування.

Я не зміг отримати рішення mgabriel для роботи на OSX, оскільки версія OSX pgrep, схоже, не має опції -c (я вважаю, це для підрахунку). Натомість я використав наступне:

[ $(pgrep ping | wc -l) -eq 0 ] && ping multiplay.co.uk || echo "Sorry, ping already in progress"

Я використовував ping як приклад команди.

Сподіваюсь, це допомагає.