При применении настроек после изменении настроек журналирования плата перезагружается

[san]

Эксперимент такой:

• открываю окно платы и меняю настройки журналирования NOTICE/буфер на DEBUG/файл
• нажимаю Применить
• меняю настройки обратно
• нажимаю Применить
• снова меняю настройки
• нажимаю Применить

...
После нескольких таких операций смен настроек плата говорит в консоль: root@comcerto:/# comcerto_wdt: closed unexpectedly. WDT will not stop! и перезагружается.

[alx]

Произвел описанное изменение журналирования 20 раз. Проблема не воспроизвелась.
Поскольку изменение настроек журналирования - это дополнительная сервисная функция, которой будут пользоваться лишь в отдельных редких случаях, а также учитывая, что проблема трудновоспроизводимая, я решил закрыть тикет.

[san]

На мой взгляд, решить эту проблему нужно. С платой VE довольно часто возникает необходимость проводить эксперименты, т.к. плата поддерживает много сигнализаций и функций. И часто бывает что лог нужно писать на "живой АТС", в этом случае вероятность перезагрузки критична.
А воспроизводится стабильно, как минимум у одного из пользователей, да и у меня без особого труда воспроизводилось, могу попробовать продемонстрировать на твоей плате.

[alx]

Произвел описанное изменение режима журналирования 200 (двести) раз. Падение не воспроизвелось...

[san]

Попробую сейчас у себя...

[san]

У меня воспроизвелось со 2 (второго раза).
Правда я нечаянно нажал "Применить" между сменами настроек.
Сейчас попробую без этого действия.

[san]

Хм.. без нажатия применить у меня не получилось...
А с нажатием применить очень быстро.

[alx]

Replying to san:

У меня воспроизвелось со 2 (второго раза).

Хорошо. Будем считать, что имеет место эффект кармы. :)
Буду тестировать твоими руками.
Сейчас попробую надобавлять дополнительный отладочный вывод чтобы определить, в каком месте происходит падение...

[alx]

Replying to san:

Хм.. без нажатия применить у меня не получилось...
А с нажатием применить очень быстро.

В таком случае, логика подсказывает, что падение происходит не в процессе изменения режимов логгирования, а в процессе применения настроек...

Предлагаю тебе повторить описанное в тикете изменение режимов журналирования (без применения настроек) 200 раз и, если падения не возникнет, предлагаю закрыть тикет.

[san]

Добавил кнопку Применить в описание эксперимента, т.к. без её нажатия у меня не получается теперь.

[san]

В таком случае, логика подсказывает, что падение происходит не в процессе изменения режимов логгирования, а в процессе применения настроек...

Согласен. Возможно я ошибся тестируя эту проблему в первый раз и таки когда-то нажал применить.

Но при изменении других настроек, плата не перезапускается, только при Применении изменённых настроек логирования.

[alx]

Replying to san:

только при Применении изменённых настроек логирования.

??? То есть тебе все-таки удалось воспроизвести проблему изменением только настройки журналирования?

[san]

Нет.
Проблема проявляется если применить настройки после изменения настроек логирования.

[alx]

Replying to san:

Проблема проявляется если применить настройки после изменения настроек логирования.

Верно ли я понял, что если применять настройки без предварительного изменения режима журналирования, то проблема также не воспроизводится?

[san]

Да.

[alx]

В таком случае, прошу приложить к тикету конфиг платы.

[alx]

Проблему удалось воспроизвести. Происходящая цепочка событий примерно следующая:

• При изменении режима журналирования выполняется перезапуск syslogd с другими опциями. Для этого выполняется следующий код:

system("killall syslogd");
system(mode == "file" ? "syslogd -s 1024 -O /www/messages -S" : "syslogd -C1024");

• При последующей записи в плату конфигурации плата может захотеть перезапустить прокси-сервер (repro).
• В процессе перезапуска repro уничтожаются имеющиеся транспорты и создаются новые. Как показал эксперимент, по неизвестной причине, если рестарту предшествовал вышеописанный перезапуск syslogd, в процессе создания нового транспорта выполнение системного вызова bind() возвращает ошибку EADDRINUSE, в результате чего код repro бросает исключение "port already in use".

• Это исключение ловит функция MyReproRunner::addTransports(), которая, в свою очередь, возвращает false.

• Это значение сигнализирует вызывающему коду, что создание транспортов закончилось неудачей, и собственно прокси-сервер не создается.

• Затем плата получает список маршрутов SIP (возможно, пустой), и при попытке обратиться к прокси-серверу все падает из-за обращения по нулевому указателю mProxy.

Интересные дополнительные наблюдения:

• После того как не смогли создать транспорты и прокси-сервер (когда устранил падение, временно убрав обращение к прокси), netstat -uln показывал, что 0.0.0.0:5060 и :::5060 по-прежнему слушаются.

• Выполнение в консоли команды killall syslogd приводило к тому, что 0.0.0.0:5060 и :::5060 пропадали из вывода netstat -uln, после чего запись конфигурации в плату приводила к успешному созданию транспортов и прокси-сервера.

• Выполнение в консоли последовательности команд killall syslogd и syslogd -C1024 не приводило к ошибкам при последующем пересоздании транспортов при применении конфигурации.

• Замена вызовов system() на эквивалентную последовательность fork()-exec()-wait() устранило проблему пересоздания транспортов.

[alx]

In 1733/sip_ua:

Вызовы system(), с помощью которых перезапускался syslogd при изменении режима журналирования
заменены на эквивалентную последовательность fork()-exec()-wait(). Этим устранена ошибка,
возникавшая при последующем пересоздании транспортов при рестарте repro, приводившая к
выбрасыванию исключения "port already in use" и, в конечном итоге, падению из-за обращения
по NULL-указателю mProxy при попытке применить список маршрутов SIP. Closes #335.