Opened 7 years ago
Closed 5 years ago
#330 closed улучшение (не будем делать)
Отложенная перезагрузка
Reported by: | san | Owned by: | alx |
---|---|---|---|
Priority: | средний | Milestone: | 2 очередь |
Component: | sw | Keywords: | |
Cc: |
Description
В нашей аппаратуре есть функция "Отложенный перезапуск swd"
Предлагаю аналогично добавить функцию "Отложенная перезагрузка"
Случай который натолкнул на это предложние:
При обновлении ПО на нескольких блоках оказалось что веб-морда "не работает", после перезагрузки работает, исследовать это нет возможности/времени, а нужно обновить ещё много подобных удалённых блоков.
Change History (6)
comment:1 by , 7 years ago
follow-up: 3 comment:2 by , 7 years ago
Я в тикете описал ситуацию с которой столкнулся Витя, функция отложенной перезагрузки помогла бы ему обновить остальные блоки.
с платами SM-01 и/или SM-02
не думал об этом, не могу представить такой сценарий)
comment:3 by , 7 years ago
Replying to san:
функция отложенной перезагрузки помогла бы ему обновить остальные блоки.
Не понимаю, откуда уверенность (особенно учитывая, что "исследовать это нет возможности/времени"), что эта функция ему бы помогла.
Давай пойдем по-порядку. Как ты сам написал, у нас уже есть функция "Отложенный растарт swd". Ее смысл в том, что если оператор случайно "испортил" настройки блока так, что потерял к нему доступ, по истечении установленного таймаута swd перечитает и применит последнюю сохраненную конфигурацию (предполагается, что сохранять будут только заведомо рабочие конфигурации, иначе эта функция не имеет смысла).
Чем отличается перезагрузка платы от рестарта процесса swd в данном контексте? Насколько я помню, тем, что перед перезагрузкой на кросс-плату передается RESET и команда RESTART всем платам блока. Есто только две известные мне платы, для которых рестарт с последующей записью конфигурации отличается от просто записи конфигурации без предшествующего рестарта: это SM-01 и SM-02.
Попробую сам сконструировать сценарий, в котором перезагрузка поможет, а рестарт swd - нет.
- Исходное состояние - "хорошая" конфигурация, сохраненная в конфиг-файле.
- Оператор изменяет конфигурацию платы SM-01.
- Чтобы применить изменение конфигурации оператор выполняет рестарт SM-01.
- После рестарта плата SM-01 применяет измененную конфигурацию, но оказывается, что оператор допустил ошибку, в результате чего к блоку больше нет доступа.
В описанной ситуации рестарт swd, действительно, не поможет: swd прочитает хорошую конфигурацию из конфиг-файла и запишет ее в плату SM-01, но плата SM-01 не применит эту конфигурацию, так как не был выполнен рестарт. А перезагрузка, очевидно, поможет. Так?
follow-up: 5 comment:4 by , 7 years ago
откуда уверенность, что эта функция ему бы помогла.
после рестарта питанием, блоки из примера работали нормально, думаю что программный рестарт платы sw тут бы тоже помог (у нас были похожие случаи когда при обновлении почему-то упал или не запустился http сервер или когда коммутатор перестал форвардить длинные пакеты)
А перезагрузка, очевидно, поможет. Так?
Да, такой сценарий вероятен
comment:5 by , 7 years ago
Replying to san:
после рестарта питанием, блоки из примера работали нормально, думаю что программный рестарт платы sw тут бы тоже помог
В описанном мной гипотетическом сценарии - помог бы. Но мы не знаем, что происходило в действительности. Возможно, что-то совсем другое. Не вижу оснований для такого предположения.
(у нас были похожие случаи когда при обновлении почему-то упал или не запустился http сервер
Ты хочешь сказать, что были случаи, когда упал или не запустился swd (http сервером у нас является swd)? В первом случае (падение) и так произойдет перезагрузка платы по watchdog'у, поэтому никакая дополнительная функция не требуется. Во втором случае (swd почему-то не запустился) предлагаемая функция не поможет - кто будет выполнять-то эту функцию, если нет swd?
или когда коммутатор перестал форвардить длинные пакеты)
Да, в этом случае перезагрузка платы помогла (видимо, помогал reset коммутатора). Но предлагаемая функция вряд ли может помочь в данном случае. Ведь для ее успешного применения оператор должен заранее ожидать, то вот сейчас может что-то случиться, что приведет к проблеме, и заранее активировать отложенную перезагрузку. В случае, когда он собирается менять конфигурацию удаленного блока, он это может предвидеть, так как сам является потенциальным источником проблемы. В случае же, когда проблема возникает сама собой, предвидеть ее невозможно. Не предполагаешь же ты, что обслуживающий персонал все время будет держать на всех блоках отложенную перезагрузку активированной, и каждый час переустанавливать таймер, чтобы блоки не перезагружались, пока все хорошо? Этакий LOST получается... :)
comment:6 by , 5 years ago
Resolution: | → не будем делать |
---|---|
Status: | new → closed |
Replying to san:
Аргументируй, пожалуйста, свое предложение. Какова может быть польза этой функции? Не могу придумать, в каком случае эта функция может пригодиться.
Смутно догадываюсь, что польза может быть связана с платами SM-01 и/или SM-02, особенность которой в том, что запись в нее конфигурации еще не означает, что эта конфигурация вступила в действие. Но конкретный сценарий представить не могу...