Доступность программного обеспечения во время обновления?

Обычно это до программного обеспечения, посылающего электронное письмо для организации очередей его вплоть до сервиса, становится доступным. Когда сервер недоступен существует несколько возможных причин, что означает, что отправка программного обеспечения т.е. соединение с сервером должны иметь механизмы, чтобы повторно подключить и повторить транзакцию (транзакции).

Вдобавок к этому я должен был бы попросить логику того, почему Вы обновляете какую-либо часть программного обеспечения в Вашей системе, если Вы знаете, что не можете занять время простоя? Вы загружаете (?), распаковывая (?) и заменяя исполняемые файлы и возможно совместно использованные библиотеки для этой конкретной части программного обеспечения, которое могло привести отъезд к сбою Вас с неприменимой системой, поэтому если Вы не можете занять время простоя на нем, почему Вы делаете это?

Это зависит полностью от поддержки программного обеспечения и на сценариях установки/обновления пакета.

Некоторые программы продолжат работать нормальными во время обновления и будут только нужны в перезапуске, когда обновление будет завершено.... и, обычно, специалисты по обслуживанию пакета используют в своих интересах тот факт со своими упаковочными сценариями.

(Я обычно сообщаю об этом как об ошибке, когда я вижу, что пакет излишне останавливается во время обновления, поскольку это может привести к чрезвычайно длинным отключениям электричества на, например, apt-get dist-upgrade если существует много пакетов для обновления или если один из обновляемых пакетов задает вопрос на tty. Я также склонен обновлять самые важные сервисы индивидуально, а не как часть dist-обновления для уменьшения времени простоя.... после тестирования обновления на непроизводственных машинах, конечно),

Другие программы не являются настолько прощающими из своего изменения среды, в то время как они все еще работают и должны быть остановлены во время процесса обновления. Снова, это обычно обрабатывается автоматически сценариями специалиста по обслуживанию пакета.

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

Большинство MTAs работает путем отбрасывания электронных писем в каталоге очереди, затем взятия файлов с очередями и отправки им, если это возможно. Во время обновления MTA демон, который посылает электронные письма, будет остановлен на короткое время, но если клиентская программа пошлет электронное письмо, то она будет все еще поставлена в очередь для обработки, когда демон перезапустит.

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

Для других видов программного обеспечения могло бы быть маленькое время простоя, в то время как демон перезапускается. Такое время простоя обычно обрабатывается при наличии нескольких машин сервера и балансировке соединений между ними. Такое дублирование необходимо для высоконадежных систем так или иначе (отказы оборудования могут всегда происходить).

Существует программное обеспечение, которое может быть обновлено без времени простоя. Для этого программное обеспечение должно быть способным для выполнения обеих версий - нового и старой - одновременно. Во время обновления старая версия все еще служит клиентам, соединяющимся с ним. После обновления новая версия принимает управление и обрабатывает новые клиенты. Старая версия является shutted вниз после того, как последний клиент разъединяется от него и затем может быть удален (или остаться в фоновом режиме как режим нейтрализации, если новая версия не работает правильно и существуют механизмы для реализованного постепенного ухудшения.), Но те механизмы реализованы в очень немногих вариантах использования.

Иначе jordanm прав с его комментарием относительно дублирования.