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

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

[Vladimir Karpinsky]

Здравствуйте!

Есть задача: проверять не появилась ли связь с уделённым сервером, если 
появилась --- отзеркалировать ftp-ресурс с данными. В принципе, всё 
понятно: cron+ping, если всязь есть, то wget --mirror. Сейчас работает 
проверка связи раз в 15 минут, но пока без wget. Что пока не понятно: что 
произойдёт, если в какой-то момент времени будет выяснено, что связь есть, 
wget займётся своей работой, за 15 минут он скорее всего не успеет всё 
сделать, а тут подойдёт время следующей проверки и он должен быть запущен 
ещё раз? Конечно, можно определить pid процесса wget, и вторую сессию wget 
не запускать при наличии этого pid, но как будет вести себя wget и его pid 
при обрыве и последующем восстановлении связи (интервалы между сеансами 
связи могут достигать нескольких суток). В общем, тут многое надо 
предусматривать и отслеживать, м.б. есть какой-то путь попроще или 
кто-нибудь уже проторил эту дорожку?

З.Ы. Удалённый ftp-ресурс работает под WinXP (Filezilla).

-- 
	С уважением,
		Владимир.

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

[Yuri Bushmelev]

В сообщении от Среда 10 декабря 2008 Vladimir Karpinsky написал(a):
> Здравствуйте!
>
> Есть задача: проверять не появилась ли связь с уделённым сервером, если
> появилась --- отзеркалировать ftp-ресурс с данными. В принципе, всё
> понятно: cron+ping, если всязь есть, то wget --mirror. Сейчас работает
> проверка связи раз в 15 минут, но пока без wget. Что пока не понятно: что
> произойдёт, если в какой-то момент времени будет выяснено, что связь
> есть, wget займётся своей работой, за 15 минут он скорее всего не успеет
> всё сделать, а тут подойдёт время следующей проверки и он должен быть
> запущен ещё раз? Конечно, можно определить pid процесса wget, и вторую
> сессию wget не запускать при наличии этого pid, но как будет вести себя
> wget и его pid при обрыве и последующем восстановлении связи (интервалы
> между сеансами связи могут достигать нескольких суток). В общем, тут
> многое надо предусматривать и отслеживать, м.б. есть какой-то путь
> попроще или кто-нибудь уже проторил эту дорожку?

man flock может помочь :)

-- 
С уважением,
Бушмелев Юрий

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

[Alexey Borovskoy]

* Среда 10 декабря 2008 Vladimir Karpinsky

--кусь--

#!/bin/bash

exit_handler() {
    trap - EXIT
    [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
}

trap exit_handler HUP PIPE INT QUIT TERM EXIT

date> "$LOCK_FILE"

--кусь--

Логику дописать по вкусу

-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

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

[Vladimir Karpinsky]

Alexey Borovskoy пишет:
> * Среда 10 декабря 2008 Vladimir Karpinsky
> 
> --кусь--
> 
> #!/bin/bash
> 
> exit_handler() {
>     trap - EXIT
>     [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
> }
> 
> trap exit_handler HUP PIPE INT QUIT TERM EXIT
> 
> date> "$LOCK_FILE"
> 
> --кусь--
> 
> Логику дописать по вкусу
> 

Простите, а можно пояснений к приведённому выше. Я уже занялся изучением 
trap (раньше никогда не сталкивался) и примерно понял что происходит, но 
пока я не понимаю, как это мне применить. Спасибо!

-- 
	С уважением,
		Владимир.

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

[Alexey Borovskoy]

* Среда 10 декабря 2008 Vladimir Karpinsky

> Alexey Borovskoy пишет:
> > * Среда 10 декабря 2008 Vladimir Karpinsky
> >
> > --кусь--
> >
> > #!/bin/bash
> >
> > exit_handler() {
> >     trap - EXIT
> >     [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
> > }
> >
> > trap exit_handler HUP PIPE INT QUIT TERM EXIT
> >
> > date> "$LOCK_FILE"
> >
> > --кусь--
> >
> > Логику дописать по вкусу
>
> Простите, а можно пояснений к приведённому выше. Я уже занялся
> изучением trap (раньше никогда не сталкивался) и примерно
> понял что происходит, но пока я не понимаю, как это мне
> применить. Спасибо!

Это немножно чорной магии.
Создается обработчик события, который умеет удалять файл 
блокировки.

Затем на сигналы вешается этот обработчик. Тоесть по завершению 
скрипта, будет вызван обработчик и локфайл сотрется.

Вот про PIPE я не уверен, нужно ли его перехватывать.

-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

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

[Vladimir Karpinsky]

Alexey Borovskoy пишет:
> * Среда 10 декабря 2008 Vladimir Karpinsky
> 
>> Alexey Borovskoy пишет:
>>> * Среда 10 декабря 2008 Vladimir Karpinsky
>>>
>>> --кусь--
>>>
>>> #!/bin/bash
>>>
>>> exit_handler() {
>>>     trap - EXIT
>>>     [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
>>> }
>>>
>>> trap exit_handler HUP PIPE INT QUIT TERM EXIT
>>>
>>> date> "$LOCK_FILE"
>>>
>>> --кусь--
>>>
>>> Логику дописать по вкусу

> Создается обработчик события, который умеет удалять файл 
> блокировки.
> 
> Затем на сигналы вешается этот обработчик. Тоесть по завершению 
> скрипта, будет вызван обработчик и локфайл сотрется.

И, если я правильно понимаю логику, то при запуске скрипта проверяется 
наличие этого лок-файла, если он есть то что-то (в моём случае wget) 
повторно не запускается...

Я ещё пока не могу понять, как будет себя чувствовать wget, если в процессе 
зеркалирования, произойдёт обрыв связи на сутки, а потом восстановится, но 
содержимое ресурса несколько изменится. Или надо при продолжительном 
отсутствии связи wget убивать, чтобы он потом запустился с чистого листа. 
Надо как-то эксперимент поставить что ли...

> Вот про PIPE я не уверен, нужно ли его перехватывать.

Это для меня уже наверное следующее приближение.

-- 
	С уважением,
		Владимир.

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

[Vladimir Karpinsky]

Есть ли у wget умение при зеркалировании удалять локальные файла уже 
отсутствующие удалённо?

-- 
	С уважением,
		Владимир.

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

[Denis Nazarov]

On Wednesday 10 December 2008 22:00:44 Vladimir Karpinsky wrote:
> Есть ли у wget умение при зеркалировании удалять локальные файла уже
> отсутствующие удалённо?

а почему вас rsync не устраивает? кажется, под винду есть rsync сервера, 
вместо ftp, а написать скрипт, который будет в цикле крутить rsync - я так 
себе выкачку бранча сделал на неустойчивой связи. есть связь - качает, нет 
связи - тупо стучится и ждет пока не появится. И вполне нормальное 
зеркалирование получится. Кстати, мысль... надо у клиента на выньтукей  
поднять и посмотреть, как это получится :)

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

[Vladimir Karpinsky]

> а почему вас rsync не устраивает? кажется, под винду есть rsync сервера, 
> вместо ftp, а написать скрипт, который будет в цикле крутить rsync - я так 
> себе выкачку бранча сделал на неустойчивой связи. есть связь - качает, нет 
> связи - тупо стучится и ждет пока не появится. И вполне нормальное 
> зеркалирование получится. Кстати, мысль... надо у клиента на выньтукей  
> поднять и посмотреть, как это получится :)

В принципе, rsync меня устраивает. Но две проблемы: погуглить наличие rsync 
  для Вин, я не догадался.

Вторая проблема: удалённый компьютер действительно удалённый, FTP-сервер 
там уже есть, а rsync надо ставить по VNC, что не очень просто 
организационно (надо попасть в сеанс связи, и чтобы там никто клавиши бы не 
трогал). Но если не сейчас, то на будущее этот вариант надо мне будет освоить.

Спасибо за наводку!

-- 
	С уважением,
		Владимир.

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

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Wed, Dec 10, 2008 at 08:00:44PM +0300, Vladimir Karpinsky wrote:
> Есть ли у wget умение при зеркалировании удалять локальные файла уже
> отсутствующие удалённо?

wget вроде бы так не умеет, а вот lftp -c "mirror -e ..." - умеет.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Vladimir Karpinsky]

Здравствуйте!

Sergey Vlasov пишет:
> On Wed, Dec 10, 2008 at 08:00:44PM +0300, Vladimir Karpinsky wrote:
>> Есть ли у wget умение при зеркалировании удалять локальные файла уже
>> отсутствующие удалённо?
> 
> wget вроде бы так не умеет, а вот lftp -c "mirror -e ..." - умеет.

О, количество вариантов растёт и растёт. Спасибо, буду смотреть.

-- 
	С уважением,
		Владимир.

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

[Vladimir Karpinsky]

Здравствуйте!

Продолжаю налаживать зеркалирование, возникла проблема: если во время 
работы wget'а (wget  -A VAL  -c  -t 5 -T 5 -r -l 1 -N -nH) разорвать связь, 
то он продолжает висеть и пытаться соединиться. Мне бы хотелось другого: 
сделать несколько попыток и отвалиться. Есть ли такая возможность?

-- 
	С уважением,
		Владимир.

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

[Костарев Алексей]

Vladimir Karpinsky пишет:
> Здравствуйте!
>
> Продолжаю налаживать зеркалирование, возникла проблема: если во время 
> работы wget'а (wget  -A VAL  -c  -t 5 -T 5 -r -l 1 -N -nH) разорвать 
> связь, то он продолжает висеть и пытаться соединиться. Мне бы хотелось 
> другого: сделать несколько попыток и отвалиться. Есть ли такая 
> возможность?
>
man wget:
       -t number
       --tries=number
           Устанавливает число повторов number. Укажите 0 или inf для 
бесконечного числа повторов.


-- 
С Уважением
Директор ООО НЕВОД
Костарев А.Ф.

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

[Vladimir Karpinsky]

Костарев Алексей пишет:
> Vladimir Karpinsky пишет:
>> Здравствуйте!
>>
>> Продолжаю налаживать зеркалирование, возникла проблема: если во время 
>> работы wget'а (wget  -A VAL  -c  -t 5 -T 5 -r -l 1 -N -nH) разорвать 
>> связь, то он продолжает висеть и пытаться соединиться. Мне бы хотелось 
>> другого: сделать несколько попыток и отвалиться. Есть ли такая 
>> возможность?
>>
> man wget:
>       -t number
>       --tries=number
>           Устанавливает число повторов number. Укажите 0 или inf для 
> бесконечного числа повторов.

Это я читал, более того в приведённой в моём письме строке запуска wget Вы 
можете увидеть -t 5. Но это работает в том случае, если связи нет на момент 
запуска wget'а: 5 раз попытались соединится, не получилось --- отвалились. 
Если же wget уже запущен, качает, и потом произошёл обрыв связи, то он 
пытается восстановить закачку много больше 5 раз (я ни разу не дождался).

-- 
	С уважением,
		Владимир.

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

[Michael Shigorin]

On Sat, Dec 13, 2008 at 06:53:46PM +0300, Vladimir Karpinsky wrote:
> Это я читал, более того в приведённой в моём письме строке
> запуска wget Вы можете увидеть -t 5. Но это работает в том
> случае, если связи нет на момент запуска wget'а: 5 раз
> попытались соединится, не получилось --- отвалились.  Если же
> wget уже запущен, качает, и потом произошёл обрыв связи, то он
> пытается восстановить закачку много больше 5 раз (я ни разу не
> дождался).

Можно ещё --timeout поменьше, если там не бага с тем, что число
попыток становится неограниченным.  В любом разе не лучше ли
смотреть в сторону lftp?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Vladimir Karpinsky]

Здравствуйте!

Michael Shigorin пишет:
> On Sat, Dec 13, 2008 at 06:53:46PM +0300, Vladimir Karpinsky wrote:
>> Это я читал, более того в приведённой в моём письме строке
>> запуска wget Вы можете увидеть -t 5. Но это работает в том
>> случае, если связи нет на момент запуска wget'а: 5 раз
>> попытались соединится, не получилось --- отвалились.  Если же
>> wget уже запущен, качает, и потом произошёл обрыв связи, то он
>> пытается восстановить закачку много больше 5 раз (я ни разу не
>> дождался).
> 
> Можно ещё --timeout поменьше, если там не бага с тем, что число
> попыток становится неограниченным.  В любом разе не лучше ли
> смотреть в сторону lftp?

Так у меня и t и T равны 5, на мой взгляд и так не много...

А что касается lftp, то я не нашёл вообще ключей про число попыток и 
таймауты. Если учесть, что периоды времени, когда связь есть, в разы меньше 
периодов, когда её нет (в самом лучшем случае 4 часа в сутки связь есть), 
то зачем постоянно процессу висеть и ломиться в закрытые наглухо двери. Или 
я всё-таки что-то не дочитал?

Я думаю, что лучше всего для моей задачи подходит rsync, но сначала надо 
настроить и потестировать rsync-сервер для Вин, в лабораторных условиях, а 
потом везти это всё в экстрим.



-- 
	С уважением,
		Владимир.

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

[Костарев Алексей]

Vladimir Karpinsky пишет:
> Здравствуйте!
>
> Michael Shigorin пишет:
>> On Sat, Dec 13, 2008 at 06:53:46PM +0300, Vladimir Karpinsky wrote:
>>> Это я читал, более того в приведённой в моём письме строке
>>> запуска wget Вы можете увидеть -t 5. Но это работает в том
>>> случае, если связи нет на момент запуска wget'а: 5 раз
>>> попытались соединится, не получилось --- отвалились.  Если же
>>> wget уже запущен, качает, и потом произошёл обрыв связи, то он
>>> пытается восстановить закачку много больше 5 раз (я ни разу не
>>> дождался).
>>
>> Можно ещё --timeout поменьше, если там не бага с тем, что число
>> попыток становится неограниченным.  В любом разе не лучше ли
>> смотреть в сторону lftp?
>
> Так у меня и t и T равны 5, на мой взгляд и так не много...
>
> А что касается lftp, то я не нашёл вообще ключей про число попыток и 
> таймауты. Если учесть, что периоды времени, когда связь есть, в разы 
> меньше периодов, когда её нет (в самом лучшем случае 4 часа в сутки 
> связь есть), то зачем постоянно процессу висеть и ломиться в закрытые 
> наглухо двери. Или я всё-таки что-то не дочитал?
>
> Я думаю, что лучше всего для моей задачи подходит rsync, но сначала 
> надо настроить и потестировать rsync-сервер для Вин, в лабораторных 
> условиях, а потом везти это всё в экстрим.
>
Я думаю может подойти под данную задачу и fmirror


-- 
С Уважением
Директор ООО НЕВОД
Костарев А.Ф.

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

[Vladimir Karpinsky]

Костарев Алексей пишет:
>> Я думаю, что лучше всего для моей задачи подходит rsync, но сначала 
>> надо настроить и потестировать rsync-сервер для Вин, в лабораторных 
>> условиях, а потом везти это всё в экстрим.
>>
> Я думаю может подойти под данную задачу и fmirror

Спасибо, пошёл искать-смотреть.

-- 
	С уважением,
		Владимир.

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

[Vladimir Karpinsky]

Здравствуйте!

Alexey Borovskoy пишет:
> * Среда 10 декабря 2008 Vladimir Karpinsky
> 
> --кусь--
> 
> #!/bin/bash
> 
> exit_handler() {
>     trap - EXIT
>     [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
> }
> 
> trap exit_handler HUP PIPE INT QUIT TERM EXIT
> 
> date> "$LOCK_FILE"
> 
> --кусь--
> 
> Логику дописать по вкусу

Логику дописал, уже работает пару месяцев, но сегодня углядел проблемы: 
если на скрипт, содержащий вышележащий кусок натравить kill -9, то 
lock-файл не уничтожается. Можно ли как-то такой вариант учесть.

Второй момент: я запускаю этот же скрипт второй раз при наличии lock-файла, 
он обнаруживает lock-файл, ничего не делает и выходит с ненулевым кодом. 
Всё казалось бы хорошо. Но: он выходит-то по команде exit и автоматом 
убивает lock-файл, т.е. при третьем запуске скрипта уже lock-файл не будет 
найден, и скрипт будет пытаться работать, чего бы не хотелось. Не могу 
сообразить, как это обойти.

-- 
	С уважением,
		Владимир.

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

[Yura Kalinichenko]

Vladimir Karpinsky пишет:
> Здравствуйте!
>
> Alexey Borovskoy пишет:
>> * Среда 10 декабря 2008 Vladimir Karpinsky
>>
>> --кусь--
>>
>> #!/bin/bash
>>
>> exit_handler() {
>>     trap - EXIT
>>     [ -f "$LOCK_FILE" ] && rm -f "$LOCK_FILE"
>> }
>>
>> trap exit_handler HUP PIPE INT QUIT TERM EXIT
>>
>> date> "$LOCK_FILE"
>>
>> --кусь--
>>
>> Логику дописать по вкусу
>
> Логику дописал, уже работает пару месяцев, но сегодня углядел 
> проблемы: если на скрипт, содержащий вышележащий кусок натравить kill 
> -9, то lock-файл не уничтожается. Можно ли как-то такой вариант учесть.
>
> Второй момент: я запускаю этот же скрипт второй раз при наличии 
> lock-файла, он обнаруживает lock-файл, ничего не делает и выходит с 
> ненулевым кодом. Всё казалось бы хорошо. Но: он выходит-то по команде 
> exit и автоматом убивает lock-файл, т.е. при третьем запуске скрипта 
> уже lock-файл не будет найден, и скрипт будет пытаться работать, чего 
> бы не хотелось. Не могу сообразить, как это обойти.
>
Обычно блокировки выполняются несколько другим образом. Вот пример, 
надеюсь, достаточно понятно, что ваших проблем здесь не будет:

---------------------------cut-----------------------------
USE_LOCK=yes
LOCKDIR=/tmp
LOCKFILE=test.pid
mypid=$$

test_lock() {

  LOCK_LOOP_COUNT=10
  test "$USE_LOCK" \!= "yes" && return 0
  set -o noclobber
  until echo $mypid > $LOCKDIR/$LOCKFILE ; do
     kill -0 `cat $LOCKDIR/$LOCKFILE` || rm -f $LOCKDIR/$LOCKFILE
     if [ -f  "$LOCKDIR/$LOCKFILE" ]; then
       echo "Locking ($LOCK_LOOP_COUNT)..."
       let LOCK_LOOP_COUNT--
       if [ $LOCK_LOOP_COUNT -eq 0 ]; then
          break
       else
          sleep 1
       fi
     else
       echo "Remove stalled lock"
     fi
  done
  set +o noclobber
  if [ $LOCK_LOOP_COUNT -eq 0 ]; then
     return 1
  else
     return 0
  fi
}

test_unlock() {
  test -f $LOCKDIR/$LOCKFILE -a $mypid -eq `cat $LOCKDIR/$LOCKFILE` && rm -f $LOCKDIR/$LOCKFILE
  return $?
}


---------------------------cut-----------------------------


-- 
SY, 
   Yura Kalinichenko

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

[Vladimir Karpinsky]

Здравствуйте!

Насколько я понял, --- понял ещё не всё, разбираюсь, --- это не совсем то. 
У меня проблема такая: по крону раз в 15 минут запускается скрипт, 
пытающийся достучаться до удалённого ресурса и скачать оттуда данные. 
Связь, даже когда она есть, терпимая, хуже другое: 20 часов из 24 нет там 
нет электричества. Скрипт без связи отваливается, лок-файл удаляется, всё 
хорошо. Мне надо отследить момент, когда связь есть, и уже происходит 
перекачка данных, а тут подходит время следующего запуска скрипта: возможны 
разные неприятности при одновременной закачке, поэтому повторный скрипт 
должен обнаружить блокировку и просто отвалится, не трогая её. А если 
произойдёт штатный выход или kill -9, то блокировку надо снять, чтобы 
разрешить следующий запуск. kill -9 нужен на тот случай, когда связь 
разрывается в процессе закачки и скрипт подвисает (wget не отваливается). 
Для отработки такого случая, я убиваю соответствующий pid, в том случае, 
когда блокировка есть, а связи нет.

Сейчас для двух ресурсов в качестве качалок используется wget и rsync. 
rsync пока только пробую, потому что с той стороны поставил rsync для 
Windows, надо посмотреть насколько он стабилен.

Вполне допускаю, что может быть надо постановку задачи поправить...

-- 
	С уважением,
		Владимир.

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

[Yura Kalinichenko]

Vladimir Karpinsky пишет:
> Здравствуйте!
>
> Насколько я понял, --- понял ещё не всё, разбираюсь, --- это не совсем 
> то. У меня проблема такая: по крону раз в 15 минут запускается скрипт, 
> пытающийся достучаться до удалённого ресурса и скачать оттуда данные. 
> Связь, даже когда она есть, терпимая, хуже другое: 20 часов из 24 нет 
> там нет электричества. Скрипт без связи отваливается, лок-файл 
> удаляется, всё хорошо. Мне надо отследить момент, когда связь есть, и 
> уже происходит перекачка данных, а тут подходит время следующего 
> запуска скрипта: возможны разные неприятности при одновременной 
> закачке, поэтому повторный скрипт должен обнаружить блокировку и 
> просто отвалится, не трогая её.
Так это и происходит, когда используете для блокировки функцию 
test_lock. Плюс проверяется - существует ли еще процесс, создавший 
блокировку, и если нет (напр. был убит по kill -9) - блокировка 
перехватывается.
> А если произойдёт штатный выход или kill -9, то блокировку надо снять, 
> чтобы разрешить следующий запуск. kill -9 нужен на тот случай, когда 
> связь разрывается в процессе закачки и скрипт подвисает (wget не 
> отваливается). Для отработки такого случая, я убиваю соответствующий 
> pid, в том случае, когда блокировка есть, а связи нет.
IMHO, логичнее заставить wget отваливаться при разрыве связи (--timeout 
?). Убивать чужой процесс - как-то некрасиво.

-- 
SY, 
   Yura Kalinichenko

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

[Vladimir Karpinsky]

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

Я  прошу прощения, а что такое kill -0? kill -l про сигнал 0 молчит... Я до 
конца не понимаю смысл цикла until: ставится запрет на перезапись 
существующего файла и дальше зацикливаемся в попытке его перезаписать. 
Далее, если kill -0 успешен, то удалять лок-файл не надо, ждём, что он 
процессе счёта до 10 сам уйдёт (?) или мы его убьём в следующей итерации 
until. Что-то я запутался, пните, пожалуйста, в нужном направлении.

>> А если произойдёт штатный выход или kill -9, то блокировку надо снять, 
>> чтобы разрешить следующий запуск. kill -9 нужен на тот случай, когда 
>> связь разрывается в процессе закачки и скрипт подвисает (wget не 
>> отваливается). Для отработки такого случая, я убиваю соответствующий 
>> pid, в том случае, когда блокировка есть, а связи нет.
> IMHO, логичнее заставить wget отваливаться при разрыве связи (--timeout 
> ?). Убивать чужой процесс - как-то некрасиво.

Полностью согласен, но мои эксперименты с выдёргиванием сетевого шнура из 
компьютера, с котрого уже качает wget, показал, что wget не отваливается, 
несмотря на наличие таймаутов. Если переход на rsync окажется удачным, то 
там это не понадобится. Но я уже вижу, что можно реализовать то, что я хочу 
путём анализа перезаписи лок-файла при наличии запрета на перезапись в 
сочетании с успешностью работы ping.


-- 
	С уважением,
		Владимир.

Re: [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

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

[Vladimir Karpinsky]

Здравствуйте!

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

Спасибо! Странно, что нет ни в man, ни в kill -l.

>> Я до конца не понимаю смысл цикла until: ставится запрет на перезапись 
>> существующего файла и дальше зацикливаемся в попытке его перезаписать. 
>> Далее, если kill -0 успешен,
> Т.е. лок выставлен, и процесс, его создавший, активен
>> то удалять лок-файл не надо, ждём, что он процессе счёта до 10 сам 
>> уйдёт (?)
> Т.е. ожидаем (если нужно) что процесс, заблокировавший ресурс, 
> завершится сам и тогда мы выставим свою блокировку и начнем свою обработку.
>> или мы его убьём в следующей итерации until.
> Не его - себя. Если за определенное время процесс, ранее заблокировавший 
> ресурс, его не освободил - обычно ждать далее не имеет смысла, и мы 
> выходим в расчете на следующий запуск. Хотя иногда (но не в вашей 
> ситуации) может иметь смысл ожидать до победного конца.

Понял, вроде.

>> Полностью согласен, но мои эксперименты с выдёргиванием сетевого шнура 
>> из компьютера, с котрого уже качает wget, показал, что wget не 
>> отваливается, несмотря на наличие таймаутов.
> Странно. Только что проверил: wget --timeout=3 -c 'http://...' 
> благополучно разрывается через 3 сек. после выдергивания шнура либо 
> укладывания интерфейса.

Попробую ещё раз на днях... Ставил  ключи -t 5 -T 5: т.е. 5 попыток по 5 
секунд. У меня не отваливался wget, только если сеть рвалась уже имеено 
в момент закачки. Во всех остальных случаях (подключение, получение 
списка и т.п.) всё отваливалось нормально.

-- 
	С уважением,
		Владимир.

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Mon, Mar 23, 2009 at 09:55:49AM +0300, Vladimir Karpinsky wrote:
> >> Я  прошу прощения, а что такое kill -0? kill -l про сигнал 0 молчит... 
> > Ну это в общем-то классика. Этот псевдосигнал используется для проверки 
> > существования процесса. Вот что говорит, к примеру, info kill:
> Спасибо! Странно, что нет ни в man, ни в kill -l.
В kill(2) есть.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<Lost> wRAR: положи образ ливефлаша на пипл
<roman> я прочитал ливерфарша
<Lost> roman: иди на обед

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Vladimir Karpinsky]

Здравствуйте!

Yura Kalinichenko пишет:
>  set -o noclobber
>  echo $mypid > $LOCKDIR/$LOCKFILE

Юрий, скажите, пожалуйста, можно ли избавиться от сообщения о невозможности 
перезаписи файла в таком случае? Попытка перенаправить и stdin, и stderr  в 
/dev/null не помогают, а cron письма с этим всё шлёт и шлёт...

-- 
	С уважением,
		Владимир.

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Wed, Mar 25, 2009 at 10:29:54PM +0300, Vladimir Karpinsky wrote:
> >  set -o noclobber
> >  echo $mypid > $LOCKDIR/$LOCKFILE
> Юрий, скажите, пожалуйста, можно ли избавиться от сообщения о невозможности 
> перезаписи файла в таком случае? Попытка перенаправить и stdin
LOL
> и stderr  в /dev/null не помогают
Как перенаправляли?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

А самое приятное - быть отловленным девушкой из 1C, которая на вопрос о
наличии их бухгалтерии под Linux даст положительный ответ ;-))
		-- rider in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Vladimir Karpinsky]

Andrey Rahmatullin пишет:
> On Wed, Mar 25, 2009 at 10:29:54PM +0300, Vladimir Karpinsky wrote:
>>>  set -o noclobber
>>>  echo $mypid > $LOCKDIR/$LOCKFILE
>> Юрий, скажите, пожалуйста, можно ли избавиться от сообщения о невозможности 
>> перезаписи файла в таком случае? Попытка перенаправить и stdin
> LOL

естественно, stdout, хотя это тоже было глупо

>> и stderr  в /dev/null не помогают
> Как перенаправляли?

touch 2
set -o noclobber
echo qw > 2  2> /dev/null
-bash: 2: cannot overwrite existing file

-- 
	С уважением,
		Владимир.

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

[Yura Kalinichenko]

Vladimir Karpinsky пишет:
> Здравствуйте!
>
> Yura Kalinichenko пишет:
>>  set -o noclobber
>>  echo $mypid > $LOCKDIR/$LOCKFILE
>
> Юрий, скажите, пожалуйста, можно ли избавиться от сообщения о 
> невозможности перезаписи файла в таком случае? 
Можно. Перед тем как - вставьте в скрипт строку:

exec 2>&-

Что это значит - man bash.

-- 
SY, 
   Yura Kalinichenko

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

[Vladimir Karpinsky]

Yura Kalinichenko пишет:
> Vladimir Karpinsky пишет:
>> Здравствуйте!
>>
>> Yura Kalinichenko пишет:
>>>  set -o noclobber
>>>  echo $mypid > $LOCKDIR/$LOCKFILE
>>
>> Юрий, скажите, пожалуйста, можно ли избавиться от сообщения о 
>> невозможности перезаписи файла в таком случае? 
> Можно. Перед тем как - вставьте в скрипт строку:
> 
> exec 2>&-
> 
> Что это значит - man bash.

Спасибо!

-- 
	С уважением,
		Владимир.

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

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Wed, Mar 25, 2009 at 11:42:43PM +0200, Yura Kalinichenko wrote:
> exec 2>&-

Так делать нельзя.  Если нужно подавить вывод в stderr, используйте
exec 2>/dev/null, но не закрытие дескриптора 2.  Также не следует
закрывать дескрипторы 0 и 1.

Проблема с закрытием стандартных дескрипторов в том, что для файлов,
открываемых в дальнейшем, будут назначаться минимальные номера из
доступных - т.е., после закрытия дескриптора 2 следующий файл,
открываемый программой, запущенной из этого экземпляра shell, получит
номер дескриптора 2, и в него может попасть вывод, который должен был
быть направлен в stderr.  Авторы большинства программ не заботятся о
защите от подобных ошибок.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Yura Kalinichenko]

Sergey Vlasov пишет:
> On Wed, Mar 25, 2009 at 11:42:43PM +0200, Yura Kalinichenko wrote:
>   
>> exec 2>&-
>>     
>
> Так делать нельзя.  Если нужно подавить вывод в stderr, используйте
> exec 2>/dev/null, но не закрытие дескриптора 2.  Также не следует
> закрывать дескрипторы 0 и 1.
Да, действительно грабли. Посыпаю голову пеплом.

-- 
SY, 
   Yura Kalinichenko