NetXMS Support Forum

добрый день Владимир, есть новости.

Вот такой недочет или пожелание. Когда настраиваешь auto resolving/terminate alarms, то в поле ack/resolved значится admin. Может лучше переделать на что нибудь другое потому как если что-то случится то будет проблематично разобраться какие alarm были закрыты самой системой, а кикие под учеткой admin.

как варианты
system
EventProcessor
Event Processor №[number of event processing policy]

помоему битый report-generator в архиве 1.2.3
по следам этой темы
https://www.netxms.org/forum/oe-oo/reporting-bug/msg7308/#msg7308

заглядывал в dmesg сегодня, а там

Quotepid 1577 (netxmsd), uid 0: exited on signal 11 (core dumped)
pid 66318 (netxmsd), uid 0: exited on signal 11 (core dumped)
pid 79046 (netxmsd), uid 0: exited on signal 11 (core dumped)

segmentation fault как я понимаю?

pohozhe chto da. A est' vozmozhnost' najti core file i poluchit' stack trace iz nego?

Quote from: Victor Kirhenshtein on October 17, 2012, 12:37:14 PM
pohozhe chto da. A est' vozmozhnost' najti core file i poluchit' stack trace iz nego?

Ну попробую поискать core файлы, вот один нашел

Quote(gdb) backtrace
#0  0x280ed457 in NXSL_Program::error (this=0x3f8ff4c0, nError=16) at program.cpp:412
#1  0x280eff87 in NXSL_Program::run (this=0x3f8ff4c0, pEnv=0x41fff740, argc=1, argv=0xbeef3998, pUserLocals=0x0, ppGlobals=0x0,
    pConstants=0x0, entryPoint=0x0) at program.cpp:470
#2  0x2818f762 in DCItem::transform (this=0x3da9c000, value=@0x31263600, nElapsedTime=60) at dcitem.cpp:1115
#3  0x281916a1 in DCItem::processNewValue (this=0x3da9c000, tmTimeStamp=1349867032, originalValue=0x29b61000) at dcitem.cpp:936
#4  0x281c5a38 in Node::processNewDCValue (this=0x28ef1000, dco=0x3da9c000, currTime=1349867032, value=0x29b61000) at node.cpp:4805
#5  0x2818cbe8 in DataCollector (pArg=0x0) at datacoll.cpp:187
#6  0x286ba76f in pthread_getprio () from /lib/libthr.so.3
#7  0x00000000 in ?? ()

Владимир, почему то некорректно варбинд получается.

MAC notification. (02 37 00 30 39 36 31 00 20 33 )
хотя это octet string
смотрю сниффером, там все нормально. (01b870f48d86ab000700)

в мибах

swL2macNotifyInfo   OBJECT-TYPE
        SYNTAX  OCTET STRING(SIZE (0..1024))
        MAX-ACCESS  read-only
        STATUS  current
        DESCRIPTION
            "This object indicates the last time reboot information.
            "
        ::= { swl2NotificationBidings 1 }

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

А если nxsnmpget с командной строки вызвать, тоже результат неправильный будет?
Про варбинды я что-то не понял до конца, в каком именно месте вылезает неправильное значение?

Quote from: Victor Kirhenshtein on October 24, 2012, 10:42:35 PM
А если nxsnmpget с командной строки вызвать, тоже результат неправильный будет?
Про варбинды я что-то не понял до конца, в каком именно месте вылезает неправильное значение?

Quotenetxms# nxsnmpwalk -v 2c -c syslog 192.168.7.9 .1.3.6.1.2.1.17.4.3.1.1
.1.3.6.1.2.1.17.4.3.1.1.0.21.23.214.223.228 [Hex-STRING]: 00 15 17 D6 DF E4
netxms#
netxms# nxsnmpget -v 2c -c syslog 192.168.7.9 .1.3.6.1.2.1.17.4.3.1.1.0.21.23.214.223.228
No such instance: .1.3.6.1.2.1.17.4.3.1.1.0.21.23.214.223.228
netxms#

про варбинды я отдельную темку создал.

Т.е. получается, что nxsnmpwalk выдает правильные данные, а walk из консоли - с 00 вместо правильного последнего байта?

Quote from: Victor Kirhenshtein on October 25, 2012, 06:36:53 PM
Т.е. получается, что nxsnmpwalk выдает правильные данные, а walk из консоли - с 00 вместо правильного последнего байта?

да, в данном случае да, но вообще не регулярно, а каким-то хаотическим образом он все октеты где присутствуют литеры (f0, 3a и т.д.) выдает как 00. А с варбиндами в соседней теме разъяснено.