Opened 4 years ago

Closed 4 years ago

#335 closed баг (fixed)

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

Reported by: san Owned by: alx
Priority: средний Milestone: 1 очередь
Component: VE-01 Keywords:
Cc:

Description (last modified by san)

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

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

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

Change History (18)

comment:1 by alx, 4 years ago

Resolution: не воспроизводится
Status: newclosed

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

comment:2 by san, 4 years ago

Resolution: не воспроизводится
Status: closedreopened

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

comment:3 by alx, 4 years ago

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

comment:4 by san, 4 years ago

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

comment:5 by san, 4 years ago

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

comment:6 by san, 4 years ago

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

in reply to:  5 comment:7 by alx, 4 years ago

Replying to san:

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

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

in reply to:  6 comment:8 by alx, 4 years ago

Replying to san:

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

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

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

comment:9 by san, 4 years ago

Description: modified (diff)

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

comment:10 by san, 4 years ago

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

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

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

comment:11 by san, 4 years ago

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

in reply to:  10 comment:12 by alx, 4 years ago

Replying to san:

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

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

comment:13 by san, 4 years ago

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

in reply to:  13 comment:14 by alx, 4 years ago

Replying to san:

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

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

comment:15 by san, 4 years ago

Да.

comment:16 by alx, 4 years ago

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

comment:17 by alx, 4 years ago

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

  • При изменении режима журналирования выполняется перезапуск 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() устранило проблему пересоздания транспортов.

comment:18 by alx, 4 years ago

Resolution: fixed
Status: reopenedclosed

In 1733/sip_ua:

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

Note: See TracTickets for help on using tickets.