Страниц: [1]
  Печать  
Автор Тема: Выпадает служба PPS  (Прочитано 929 раз)
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« : Января 05, 2018, 05:37:43 pm »

Замечательную удобную рулезную службу PPS мы применили в нашей системе АСУ ТП (под QNX 6.5.0 SP1), для коммуникации между программами управления механизмами, супервизорами маршрутов, и графической частью HMI. Логирование в общий журнал тоже сделано через PPS. Всё, в общем-то классно, разобрались как работает, жужжит всё как положено.

НО.

Не всегда.

В какие-то моменты времени весь менеджер pps просто выпадает в core dump. В какие именно - не совсем понятно, это случается на удалённых филиалах раз в несколько месяцев. Есть подозрение, что это на управляемом объекте одновременно происходят несколько событий (например, короткая просадка питания), что приводит к генерации сразу пачки сообщений, с которыми не может справиться PPS.

Поскольку сообщения к демону логирования идут тоже через PPS, то в журналах мы ничего крамольного не видим - оно не прошло. Персонал на месте в таких случаях обычно просто перегружает технологический сервер, а потом звонит "А-А-а-а! У нас в прошлом месяце сервер зависал - что делать?!". Так что отлаживать "в реальном времени" не удаётся.

Отсюда вопрос: что делать? Кто-нибудь с таким сталкивался?

Неужели придётся делать отдельного "сторожевого демона" для PPS, который бы останавливал всю технологию и выдавал оператору табличку "Ой! Всё пропало!" ?


На всякий случай, вот дамп:

Код:
# gdb pps /var/dumps/pps.core

GNU gdb 6.8 qnx-nto (rev. 506)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-pc-nto-qnx6.5.0"...
(no debugging symbols found)
Reading symbols from /usr/qnx650/target/qnx6/x86/lib/libc.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/qnx650/target/qnx6/x86/lib/libc.so.3

Program terminated with signal 11, Segmentation fault.
[New pid 434199 tid 1]
#0  0xb0328e38 in _list_release ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
(gdb) bt
#0  0xb0328e38 in _list_release ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#1  0xb032a81b in __free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#2  0xb032a33d in free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#3  0x0804c2c7 in pair_encode ()
#4  0x0804b100 in io_read ()
#5  0xb034ef1b in _resmgr_io_handler ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#6  0xb034ea97 in _resmgr_handler ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#7  0xb0335ebd in _resmgr_msg_handler ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#8  0xb03350dd in _message_handler ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#9  0xb0333db8 in dispatch_handler ()
   from /usr/qnx650/target/qnx6/x86/lib/libc.so.3
#10 0x0804b8ea in main ()
(gdb)
Записан

Gray©at
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« Ответ #1 : Января 11, 2018, 11:30:52 am »

Понятно...    Roll Eyes

Самое обидное, что не удаётся "правильно" узнать о том, что скоредампилась лужба PPS. У нас в подпрограммах я заряжаю ionotify() с пульсом на дескриптор открытого PPS-"файла" (запрашиваю события _NOTIFY_COND_OBAND, _NOTIFY_COND_INPUT, _NOTIFY_COND_EXTEN), и потом жду в MsgReceive() прихода уведомления. Этот же MsgReceive() ждёт пульсы и месседжи от других компонентов системы. В принципе, всё работает, как и задумывалось.

Но, согласно здравому смыслу, если что-то нехорошее случается с "поставщиком" пульсов, то система должна была бы хоть как-то уведомить ожидающую программу, что что-то пошло не так. Прислать сигнал, или код ошибки, или хоть что-то, чтобы клиент мог хотя бы аварийно остановить оборудование и выдать оператору табличку "Усё пропало!". . . Фиг там. Программа продолжает висеть на ожидании пульса от несуществующего уже PPS.

Может, я что-то не так делаю?

Пока что я вижу выход в написании "демона", который бы в явном виде отслеживал здоровье PPS, и рассылал останов по клиентам. Но, сами понимаете, это на фикс на патч на заплатку...
Записан

Gray©at
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« Ответ #2 : Января 11, 2018, 12:44:16 pm »

Сейчас попробовал через select() - то же самое, никаких уведомлений о смерти PPS...
 
...что и неудивительно, ибо работает select(), как я понимаю, через тот же ionotify().
 
Таки придётся сооружать демона-watchdog на PPS   Embarrassed .
Записан

Gray©at
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« Ответ #3 : Января 18, 2018, 12:41:50 pm »

Ещё одна то ли бага, то ли моё недопонимание работы PPS:

Для того чтобы прочитать текущее содержимое PPS-объекта к себе в буфер, желательно узнать заранее, какого размера буфер нужно выделить. Через стандартный fstat() получаем размер "файла", и если он больше чем имеющийся на данный момент буфер, увеличиваем его через realloc(). Обычно всё это срабатывает.

НО! Не всегда.

Когда Publisher записывает в PPS-объект сразу несколько обращений к одному "списочному" тегу в одной транзакции, типа
Код:
[i]Tag1::Val1,
[i]Tag2::val2,
...
[i]TagN::valN,
за один вызов write(), то у получателя вызов read() вываливается c ошибкой EMSGSIZE. Даже если сделать буфер больше размера получающегося файла.

Печально...

Записан

Gray©at
Hed
Full Member
***
Offline Offline

Сообщений: 105



Просмотр профиля
« Ответ #4 : Января 20, 2018, 01:27:32 am »

за один вызов write(), то у получателя вызов read() вываливается c ошибкой EMSGSIZE. Даже если сделать буфер больше размера получающегося файла.

Ну тык данная ошибка вам в помощь: делаете новые попытки чтения с увеличением размера буфера до тех пор, пока read не вернет >=0.

Сейчас попробовал через select() - то же самое, никаких уведомлений о смерти PPS...
 
...что и неудивительно, ибо работает select(), как я понимаю, через тот же ionotify().
 
Таки придётся сооружать демона-watchdog на PPS   Embarrassed .

Есть служба HAM, может помочь.
Записан
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« Ответ #5 : Января 20, 2018, 11:29:47 pm »

Ну тык данная ошибка вам в помощь: делаете новые попытки чтения с увеличением размера буфера до тех пор, пока read не вернет >=0.

Как-то кривовато это...

Цитировать
Есть служба HAM, может помочь.

От спасибо! Зависеть от ещё одной непонятной системной службы, которая в любой момент может тихо сдохнуть, и наша программа об этом не узнает?! - Не-ет уж, не надо!
Записан

Gray©at
Hed
Full Member
***
Offline Offline

Сообщений: 105



Просмотр профиля
« Ответ #6 : Января 22, 2018, 09:45:25 am »

Как-то кривовато это...

Дело ваше, но вообще то, идеология errno в POSIX как раз создана для возможности штатной обработки ошибки и PPS, в том числе, возвращая EMSGSIZE, предоставляет вам возможность корректно и с минимальными затратами обрабатывать данную ситуацию.

От спасибо! Зависеть от ещё одной непонятной системной службы, которая в любой момент может тихо сдохнуть, и наша программа об этом не узнает?! - Не-ет уж, не надо!

Во-первых, почему непонятной? Служба HAM официально входит в состав системных служб QNX, точно также как и io-pkt-v4, inetd, devc-con-hid и т.д. Вы же пользуетесь этими службами, что мешает Вам воспользоваться HAM?  Wink

Во-вторых, HAM достаточно удобная служба: реагирует, практически, на любое состояние процесса/потока, уведомляет "заказчика" об изменении состояния наблюдаемого любым, доступным в QNX, способом.



Записан
GrayCat
Full Member
***
Offline Offline

Сообщений: 127


Gray©at


Просмотр профиля
« Ответ #7 : Января 22, 2018, 12:37:53 pm »

Дело ваше, но вообще то, идеология errno в POSIX как раз создана для возможности штатной обработки ошибки и PPS, в том числе, возвращая EMSGSIZE, предоставляет вам возможность корректно и с минимальными затратами обрабатывать данную ситуацию.

Ну нифига ж себе "с минимальными затратами"!!  Cry  Ладно, бывают варианты, когда при нехватке буфера функция возвращает ошибку "мало памяти", И выдаёт значение "сколько нужно". Тогда выделяешь вот эти вот "сколько нужно" байт, и вторым запросом уже точно всё отрабатывает.

А тут мне предлагается, фактически, вслепую играть в "рулетку"? Угадал / не-угадал размер буфера? А если с пятой попытки не угадаю? А если с десятой? Или предлагаете сразу все 64 кБ откусывать? Так никакой памяти не хватит...

Цитировать
Во-первых, почему непонятной? Служба HAM официально входит в состав системных служб QNX, точно также как и io-pkt-v4, inetd, devc-con-hid и т.д. Вы же пользуетесь этими службами, что мешает Вам воспользоваться HAM?  Wink

Во-вторых, HAM достаточно удобная служба: реагирует, практически, на любое состояние процесса/потока, уведомляет "заказчика" об изменении состояния наблюдаемого любым, доступным в QNX, способом.

Чё-то после этого "PPS" у меня доверие ко всяким наворотам QNX потеряно. Так её рекламировали, в медицинские приложения пропихивали, а оказалась тормозная глючная хрень. И поздно уже менять...

Кроме того, вот что бы тут полезного смог бы HAM сделать? Уведомить "Поздно, доктор, я уже здохла"? Даже если перезапустить сам менеджер PPS, то заставить несколько сотен процессов переоткрыть все PPS-"файлы" - ни к чему хорошему не приведёт.
Записан

Gray©at
Hed
Full Member
***
Offline Offline

Сообщений: 105



Просмотр профиля
« Ответ #8 : Января 22, 2018, 01:39:25 pm »

Дело Ваше...  Roll Eyes
Записан
Страниц: [1]
  Печать  
 
Перейти в: