[Comm] Зеркалирование по расписанию.

[Yura Kalinichenko]

Vladimir Karpinsky пишет:
> Yura Kalinichenko пишет:
>>> Насколько я понял, --- понял ещё не всё, разбираюсь, --- это не 
>>> совсем то. У меня проблема такая: по крону раз в 15 минут 
>>> запускается скрипт, пытающийся достучаться до удалённого ресурса и 
>>> скачать оттуда данные. Связь, даже когда она есть, терпимая, хуже 
>>> другое: 20 часов из 24 нет там нет электричества. Скрипт без связи 
>>> отваливается, лок-файл удаляется, всё хорошо. Мне надо отследить 
>>> момент, когда связь есть, и уже происходит перекачка данных, а тут 
>>> подходит время следующего запуска скрипта: возможны разные 
>>> неприятности при одновременной закачке, поэтому повторный скрипт 
>>> должен обнаружить блокировку и просто отвалится, не трогая её.
>> Так это и происходит, когда используете для блокировки функцию 
>> test_lock. Плюс проверяется - существует ли еще процесс, создавший 
>> блокировку, и если нет (напр. был убит по kill -9) - блокировка 
>> перехватывается.
>
> Я  прошу прощения, а что такое kill -0? kill -l про сигнал 0 молчит... 
Ну это в общем-то классика. Этот псевдосигнал используется для проверки 
существования процесса. Вот что говорит, к примеру, info kill:

The special signal number `0' does not denote a valid signal, but can
be used to test whether the PID arguments specify processes to which a
signal could be sent.


> Я до конца не понимаю смысл цикла until: ставится запрет на перезапись 
> существующего файла и дальше зацикливаемся в попытке его перезаписать. 
> Далее, если kill -0 успешен,
Т.е. лок выставлен, и процесс, его создавший, активен
> то удалять лок-файл не надо, ждём, что он процессе счёта до 10 сам 
> уйдёт (?)
Т.е. ожидаем (если нужно) что процесс, заблокировавший ресурс, 
завершится сам и тогда мы выставим свою блокировку и начнем свою обработку.
> или мы его убьём в следующей итерации until.
Не его - себя. Если за определенное время процесс, ранее заблокировавший 
ресурс, его не освободил - обычно ждать далее не имеет смысла, и мы 
выходим в расчете на следующий запуск. Хотя иногда (но не в вашей 
ситуации) может иметь смысл ожидать до победного конца.
> Что-то я запутался, пните, пожалуйста, в нужном направлении.
>
>>> А если произойдёт штатный выход или kill -9, то блокировку надо 
>>> снять, чтобы разрешить следующий запуск. kill -9 нужен на тот 
>>> случай, когда связь разрывается в процессе закачки и скрипт 
>>> подвисает (wget не отваливается). Для отработки такого случая, я 
>>> убиваю соответствующий pid, в том случае, когда блокировка есть, а 
>>> связи нет.
>> IMHO, логичнее заставить wget отваливаться при разрыве связи 
>> (--timeout ?). Убивать чужой процесс - как-то некрасиво.
>
> Полностью согласен, но мои эксперименты с выдёргиванием сетевого шнура 
> из компьютера, с котрого уже качает wget, показал, что wget не 
> отваливается, несмотря на наличие таймаутов.
Странно. Только что проверил: wget --timeout=3 -c 'http://...' 
благополучно разрывается через 3 сек. после выдергивания шнура либо 
укладывания интерфейса.


-- 
SY, 
   Yura Kalinichenko