Блог

Я запускаю простой скрипт bash на сервере Debian Stretch каждую ночь для резервного копирования нескольких промышленных устройств на разных сайтах через VPN. По мере старения этих устройств у них, похоже, возникает проблема, когда они подключаются через FTP, но отказываются предоставлять список каталогов. Это приводит к тому, что wget генерирует неустранимую ошибку.

Я бы ожидал, что wget выполнит опцию —waitretry для устранения этой ошибки (с справочной страницы).:

—waitretry=секунды
Если вы не хотите, чтобы Wget ждал между каждым извлечением, но только между повторными попытками неудачной загрузки, вы можете использовать эту опцию. Wget будет использовать линейный откат, ожидая 1 секунду после первого сбоя в данном файле, а затем ожидая 2 секунды после второго сбоя в этом файле, до указанного вами максимального количества секунд. По умолчанию Wget принимает значение 10 секунд.

Однако вместо ожидания по умолчанию 10 секунд он ожидает 30 минут между повторными попытками. Он также повторял попытку по умолчанию 20 раз, задерживая резервное копирование на несколько часов. Я поискал справочную страницу, онлайн-документы wget, локальный /etc/wgetrc и не нашел вариантов, связанных с 30 минутами или 1800 секундами.

Вот две последовательные попытки, показывающие 30-минутную задержку и ответы:

 --2021-11-26 03:08:52-- ftp://user:*password*@192.168.18.4/SD1/ (try: 2) =gt; ‘192.168.18.4/SD1/.listing’  Connecting to 192.168.18.4:21... connected.  Logging in as user ... Logged in!  ==gt; SYST ... done. ==gt; PWD ... done.  ==gt; TYPE I ... done. ==gt; CWD (1) /SD1 ... done.  ==gt; PORT ... done. ==gt; LIST ...  Error in server response, closing control connection.  Retrying.  --2021-11-26 03:38:55-- ftp://user:*password*@192.168.18.4/SD1/ (try: 3) =gt; ‘192.168.18.4/SD1/.listing’  Connecting to 192.168.18.4:21... connected.  Logging in as user ... Logged in!  ==gt; SYST ... done. ==gt; PWD ... done.  ==gt; TYPE I ... done. ==gt; CWD (1) /SD1 ... done.  ==gt; PORT ... done. ==gt; LIST ...  Error in server response, closing control connection.  Retrying.  

Я добавил в командную строку опцию —tries=5 и —waitretry=30, чтобы попытаться переопределить 30-минутную задержку:

 wget --waitretry=30 -t 5 -m --no-passive -o ftplog ftp://user:password@192.168.18.4/SD1/  

Опция «Попытки» переопределила 20 попыток по умолчанию, ограничив их 5 попытками, но время ожидания остается на уровне 30 минут. Кто — нибудь знает, почему это происходит?

Я нашел ответ, хотя он не объясняет, почему wget, похоже, игнорирует некоторые варианты.

Сегодня утром у меня было еще одно устройство, которое отключилось. Как вы можете видеть, ошибки отличаются от моего исходного сообщения (тайм-ауты подключения), а задержка между повторными попытками составляет две минуты 12-13 секунд. В команде wget для этого устройства не указаны параметры ожидания / тайм-аута:

 --2021-12-06 02:49:23-- ftp://user:*password*@192.168.40.3/SD1/  =gt; ‘192.168.40.3/SD1/.listing’ Connecting to 192.168.40.3:21... failed: Connection timed out. Retrying.  --2021-12-06 02:51:35-- ftp://user:*password*@192.168.40.3/SD1/  (try: 2) =gt; ‘192.168.40.3/SD1/.listing’ Connecting to 192.168.40.3:21... failed: Connection timed out. Retrying.  

Поскольку —waitretry не возымел эффекта, я изменил этот параметр на —тайм-аут чтения для устройства с недопустимыми ответами сервера:

 wget --read-timeout=60 -t 5 -m --no-passive -o ftplog ftp://user:password@192.168.18.4/SD1/  

Теперь повторные попытки возвращаются к 2 минутам (не указанным 60 секундам) плюс линейный откат, указанный в документах wget для —waitretry. Это не отвечает на мой первоначальный вопрос, но предотвращает повторные попытки, каждая из которых занимает 30 минут, что является приемлемым обходным путем.