Здравствуйте.
Предоставить официальную информацию, что именно Ваш перезапуск был исправлен в новой версии ПО, к сожалению, невозможно без проведения детальной диагностики.
При этом надо понимать, что сама диагностика такого рода проблем как самопроизвольный перезапуск достаточно нетривиальна и трудоёмка,
а это означает, что данный процесс может потребовать значительных затрат времени и ресурсов только чтобы попытаться понять причину перезапуска,
и если подтвердится, что Ваша проблема одна из тех, что была исправлена в более новой версии ПО, то время и ресурсы будут потрачены впустую.
Поэтому первым шагом в решении подобного рода проблем всегда идет апгрейд до актуальной версии ПО, чтобы заведомо исключить из рассмотрения все ранее исправленные ошибки
и для минимизации потерь времени эксплуатации/тех.поддержки/разработки.
В случае сохранения проблемы на актуальной версии ПО уже будет иметь смысл детальнее анализировать ситуацию, и разработка сможет максимально оперативно отреагировать и предоставить исправления.
1. Классификация перезапусков и начало диагностики
Перезапусков может быть два вида:
- программный (перезапуск ПО)
- аппаратный (перезапуск всей платформы)
Диагностика типа перезапуска начинается с анализа двух показателей: "время работы системы" и "время работы ПО" из раздела "Информация о системе".
В штатной ситуации и в случае аппаратного перезапуска данные показатели не отличаются более чем на 30-90 секунд.
Если же эта разница значительно больше (несколько минут, несколько десятков минут, несколько часов), значит произошел программный перезапуск.
2. Трассировки и данные для диагностики
В случае аппаратного перезапуска в системе будет доступен только лог загрузки app_log, в котором будет указано:
- время и дата запуска ПО
- текущая версия ПО
- лог инициализации.
Если же перезапуск был программный, то система создаст два или более комплекта логов, состоящих из файлов "app_log*" и "gzcore*.
В gzcore система укажет какой процесс, когда и по какой причине вызвал нештатный перезапуск ПО.
По сути это системный дамп сбойнувшего процесса, т.е. бинарник. Сами Вы его не проанализируете, это могут сделать только наши разработчики.
Данные логи сохраняются в энергонезависимой флеш-памяти и должны быть доступны даже при аппаратном перезапуске/перезагрузке.
Для анализа любых инцидентов всегда нужно присылать app_log и gzcore к нам.
3. Аппаратный перезапуск
Для диагностики аппаратного перезапуска устройства очень полезным бывает запись вывода с COM-порта устройства (просто подключить COM-порт и записывать всё что там будет выведено)
На устройстве SMG2016 есть возможность узнать дополнительную информацию по аппаратному перезапуску используя показатель "Причина последней перезагрузки".
Возможные варианты:
- перезапуск по питанию
- срабатывание watchdog
- по команде пользователя
Если перезапуск возникает "по команде пользователя", то нужно записывать syslog-трассировки действий пользователя,
которые включаются в разделе Трассировки->SYSLOG: "Конфигурация системного журнала"+"Вывод истории введенных команд".
В этих логах видно, кто под какой учетной записью и что делал, и если время этих действий совпадает с временем падения ПО, значит к падению привели действия пользователя.
Также обязательно нужно прилагать конфигурацию на проверку, чтобы исключить точки взлома системы, public интерфейсы и т.д.
Иногда один объект попадает под зону ответственности нескольких компаний, которые не согласовывают между собой перезагрузки системы и перебои связи.
Если перезапуск "по срабатыванию watchdog", то нужно проверять исправность аппаратной платформы, уточнять ревизию платы, проверять работу узла связи на другом шасси.
Эта проблема возникает если какой то из аппаратных модулей на плате перестал отвечать модулю watchdog.
Если перезапуск "по питанию", то нужно проверять цепи питания, работоспособность БП,
а так же исправность цепей питания на самой аппаратной платформы (последний пункт требует отправки шасси в ремонт к производителю).