NetXMS Forum

I've set all Nodes behind the proxy as unmanaged  and disabled all DCIs od the proxy to avoid false results. Then I've captured the lsof output of the  nxagentd process to a file before the action few seconds after the action and the diff output of the two files is following (server name is changed to xxxxx): 55a56 > nxagentd 100 root 16u IPv4 1130371273 0t0 TCP xxxxx:netxms-agent->192.168.201.1:51656 (CLOSE_WAIT) 58a60,61 > nxagentd 100 root 20r FIFO 0,12 0t0 1130371274 pipe > nxagentd 100 root 21w FIFO 0,12 0t0 1130371274 pipe Then I captured the output 1 minute after the action and the lines were still there. 2 minutes after the action all 3 lines have disappeared from the lsof output. This means that closing the pipes takes some time even if the process on the other side of the pipe is no longer running (checked with ps). I did the test multiple times, each time with the same result. The question is whether if a large number of requests come, closing pipes does not take longer a therefore the average number of open pipes is increasing. Another question is how to modify the configuration to avoid this. CPU and free memory on the server and proxy are OK all the time and the actions DCIs are started every 15 minutes.

It is not possible to configure server to use only SNMP sysName for resolving node name. However, you can synchronize node name with SNMP sysName by adding the following code to configuration poll hook script: if (($node != null) && $node->isSNMP && ($node->name != $node->snmpSysName)) { $node->rename($node->snmpSysName); } It will update node name according to SNMP sysName on each configuration poll. Best regards, Victor

Thank you. I know this workaround.

Hi Victor, the systemd setting was the problem. Thank you.

Hi Victor, thank you for the confirmation that it is an error and for the workaround.

Thank you. I was probably blind that I didn't find it.

I use zones. If the proxy node for a zone is down the nodes monitored via SNMP are in Unknown Staus, which is correct state, but the nodes monitored by ping only are reported as down and they have Critical Status. What is worst that the down state of the node monitored by ping sometimes reported before the down state of the proxy, which suggests that the node is really down. Is it possible to have Unknown Status for all nodes behind a proxy and not report the nodes as down in case the proxy node is down?

I need more complex condition for e-mail notification than simple send same email to the same recipients when the same alarm is generated. The easiest way to achieve this is to use a NXSL script as the Event Processing Policy action. The only problem is that there is no possibility to send an e-mail from a NSXL script therefore I've added the NSXL function SendMail which allows this. Please add the changes to the original repositories. Code: https://github.com/netxms/netxms/pull/39 Documentation: https://github.com/netxms/nxsl-doc/pull/5

OK. Technically is it what is monitored. From the human perspective is more logical to know how many Stanby servers are receiving the WALs therefore I've chosen the name PostgreSQL.Replication.Stanby. But it is name only the number is always the same.

Yes, this should solve the issue. Duplicate records are definitely a bug, but keeping them will not help in debugging it anyway. Best regards, Victor

Yes, it's so for some historical reasons. Will stay so in 3.x versions, but hopefully will be reworked in 4.0

Working with VMWare API in in future plans only. It's not implemented yet.

Looks like coincidence - we didn't make any specific changes in graphs. But let's hope it will stay fixed. Best regards, Victor

Thank you. Similar problem is with some other parameters of the the graph. For example Time period and Y Axis Range, but this is not so confusing.

Just checked - there was a fix in DB init script between 3.2.400 and 3.2.472 for exactly this issue. Completely forgot about it. Best regards, Victor

I did a new test with different waiting times (0, 1, 2, 5, 10, 0 and 1s) only the last try was successful and the call has returned the value 5. I've attached the captured ssh communication which was done localy only (from agent on the same RPi) therefore the network cannot be the source of the problem. I've attached the source of my test program, but it is very simple.   Here is the filtered agent log (the full log is attached): 2020.04.15 09:03:24.435 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 0 5")" 2020.04.15 09:03:24.736 *D* [ ] SSH: created new session [email protected]:22/1 2020.04.15 09:03:24.841 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:34.496 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 1 5")" 2020.04.15 09:03:34.496 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:35.517 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:42.637 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 2 5")" 2020.04.15 09:03:42.637 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:44.657 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:52.416 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 5 5")" 2020.04.15 09:03:52.416 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:57.436 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:03.635 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 10 5")" 2020.04.15 09:04:03.635 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:03.917 *D* [comm.cs.1 ] Received message CMD_KEEPALIVE (146) 2020.04.15 09:04:13.656 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:20.165 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 0 5")" 2020.04.15 09:04:20.165 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:20.185 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:29.965 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 1 5")" 2020.04.15 09:04:29.966 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:30.986 *D* [comm.cs.1 ] GetListValue(): result is 0 (SUCCESS)   ssh.pcap mon_c.c nxagentd

On CentOS the libssh can be installed as a package. Compiling form sources works fine. It even works with ssh.nsm copied from Debian package but libpcre.so.3.13.3, libpcre32.so.3.13.3 are missing on CentOS and cannot be installed as packages therefore these libraries must be copied too.

I'm a stupid newbie. I've tested the output from  executeSSHCommand with println and it cannot write an array. This works fine: ret = $node->executeSSHCommand("/opt/test/test.sh"); println ArrayToString(ret, "\n");  // prints all lines println ret[0];  // prints first line only