NetXMS Support Forum

Планируем в течении одной-двух недель выпустить 1.2.17.

Hi,

I was able to reproduce this problem on my system and found the bug causing it. I'll fix it till next release.

Best regards,
Victor

Hi,

it seems that it is update of IP topology network map. I'll take a look at it.

Best regards,
Victor

В данный момент контекст для устройства задать нельзя (хотя SNMP библиотека его поддерживает). Я постараюсь добавить к следующему релизу. А как используются в вашем случае контексты - один на устройство или разные данные читаются из разных контекстов?

Hi,

you can disable or remove event processing rule for SYS_INVALID_NETMASK event altogether, or add this particular node as an exclusion. I've also registered it as a bug (https://www.radensolutions.com/chiliproject/issues/646) because it is normal situation to have /32 network mask on tunnel interface and server should not report it.

Best regards,
Victor

Hi,

when system will be on 100%, please attach to netxmsd process with gdb and send me result of command

thread apply all bt

Best regards,
Victor

Hi!

NetXMS shows all interfaces reported by device. You may also see logical interfaces (like software loopbacks). To configure data collection for interface, right click on interface you want to monitor and choose "Create data collection items" from menu. Collected data will be displayed in last values for interface's node object.

Best regards,
Victor

Hi,

so far our analysis shows that root of the problem is that some internal data structures are not initialized properly (if you are familiar with C++ - it seems that constructor for global instance of AlarmManager class is not called), although it is not clear why this happens. I try your binaries on CentOS 6.3 (closest that I can find) and it works as expected. Is it an option to do system upgrade to latest versions of kernel and glibc and try again? If this will not help, I'll re-write alarm manager initialization and provide you with intermediate build for testing.

Best regards,
Victor

You can gdnerate events using nxevent command line tool.

Best regards,
Victor

Hi,

I'll check this. Anyway, MIB compilation is a last step, so even if it fails, all new binaries are already in place. You can delete offending MIB file and run MIB compiler manually. You got same error after building 1.2.3 because this MIB file was already copied into MIB directory by 1.2.16 installer.

Best regards,
Victor

Hi,

you can do this using agent and parameter File.Size with recursive option set to on. For example, to monitor total size of all files under /home/user, add the following DCI:

File.Size(/home/user,*,1)

For reference, full description of File.Size is below:

File.Size(path, pattern, recursive, size, age)
where
    path    : path to directory or file to check
    pattern : pattern for file name matching
    recursive : recursion flag; if set to 1 or true, agent will scan subdirectories
    size      : size filter; if < 0, only files with size less than abs(value) will match;
                          if > 0, only files with size greater than value will match
    age       : age filter; if < 0, only files created after now - abs(value) will match;
                          if > 0, only files created before now - value will match

all arguments except path are optional.

Same syntax is for File.Count, which will return number of files instead of size.

Best regards,
Victor

Hi,

it seems one of the most mysterious bugs we've ever encounter. I've done load tests with lot of alarm generation and termination, and system works as expected. Seems it is some rare combination of events and/or environment. Is it possible to get remote access to your system to debug it in place? Alternatively, can you try to get core dump after crash (most likely it will note be generated by default, you'll have to enable it with ulimit) and sent to us along with compiled binaries? If you run it as virtual machine and can provide a VM image it also could help us with debugging.

Best regards,
Victor

Looks like some bug either in console or server cause incorrect severity value in the rule, and then this severity was copied into all matching alarms. I'll do additional source code checks to find out the root cause. But your configuration should be good now.

Best regards,
Victor

Hi,

I think yes, it should be very simple change.

Best regards,
Victor

Hi!

can you please provide full valgrind log (assuming there are more records then you post already)? Those errors logged looks like consequences of some memory corruption that happened before.

Best regards,
Victor