NetXMS Support Forum

Hi,

I was able to reproduce this issue and fixed it in current development branch. Fix will be included into next release.

Best regards,
Victor

Hi,

it seems that trap OID is different for version 1 and versions 2-3. For version 1 it is .1.3.6.1.4.1.2589.1.2.0.8 and version 2 it is .1.3.6.1.4.1.2589.1.2.8
(no .0 before last element). I'm not sure if it is NetXMS bug in parsing trap PDUs or device bug - will check that further. Anyway you just need to create second mapping with v2/3 OID and it will work.

Best regards,
Victor

Hi,

please do the following:

1. Enter

debug client.* 6

in server console. This will turn on debug of incoming client requests.

2. Connect with console and wait for CPU to go up.

3. Capture threads using attached script (you should have gdb and all relevant netxms-*-dbg packages installed).

Send me thread dump (will be in /tmp) and server log file (part for the duration of client session).

Best regards,
Victor

Hi,

I assume those nodes does not have SNMP nor NetXMS agent. In that case server relies on ARP caches to find MAC addresses for corresponding IP addresses - so it need access to some device(s) where those IP addresses are in ARP cache. Check that NetXMS server has SNMP access to your core switch and that it can read ARP table from that switch.

Best regards,
Victor

Hi,

Do you have any service checks below node link? They are needed to do actual service status calculation. If you have at least one, check it's status. If it's unknown most likely you have an error in check script.

Best regards,
Victor

Hi,

response time 10000 means "unreachable". Are you sure that devices will respond to ICMP ping from node with agent?

Best regards,
Victor

Hi,

it should not be version dependent. Could you take screenshot or export your SNMP trap configuration and provide example of actual trap received and incorrectly matched?

Best regards,
Victor

Hi,

what database you are using? Can you check if data in database table event_cfg is correct or also has garbage at the end?

Best regards,
Victor

There is issue registered for incorrect Hyper-V host detection: https://track.radensolutions.com/issue/NX-1472. Possible reason is that we are using CPUID "hypervisor" bit to detect if agent is running within a VM, and I suppose that Hyper-V host OS is in fact privileged VM, so agent runs inside virtual environment anyway. We will add additional checks in 2.2.8 to report host as physical machine.

Best regards,
Victor

This is download link for both minimal and full installers: https://cloud.netxms.org/index.php/s/yWU2wcC3c4WO2Y6

Best regards,
Victor

Would you like to test build with experimental patch that changes some internal synchronization mechanism?

Best regards,
Victor

Hi,

these tasks created as system tasks, and in 2.2.7 system tasks are hidden by default. You can make them visible in view menu (top right corner of scheduled task list).

Best regards,
Victor

Проще сделать не через condition, а как DCI на каждом узле.

return $1 - time();

идет в trаnsformation script. Тогда значением DCI будет расхождение времени. Затем на закладке "Thresholds" добавляются нужные пороговые значения.

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

I doubt it's Windows bug, more likely just lucky timing. I checked provided process dump - it is deadlocked in a code related to applying templates and sending events. There were execution errors for template auto apply scripts - in that case server generates event - and this event generation from within auto apply code somehow caused deadlock. I will investigate it further. As a workaround I suggest to check auto-apply scripts for possible errors.

Best regards,
Victor

Yes, my mistake - method is correct. Still seems to be a typo in list name: it is "Phonelisa.Processes" in script and "Phonalisa.Processes" in DCI configuration.

Best regards,
Victor