So the value is set to 63 (The default).  . We can't run nxmc on the Netxms server, or remote Unless we disable FIPs.  We are using java-11.0.9-openjdk, which works fine on previous versions of netxms. The error in the logfile is: UnsatisfieLinkError: no swt-pi4-gtk-4940r23 in java.library.path Could not Open SWP library.

Thanks, that's got it sorted out now!

So far NetXMS manages to have backward compatibility, so server can work with previous version agents.

Are you able to poll other SNMP nodes through the same agent/proxy? Have you done a "tcpdump port 161" on the agent while attempting the poll to ensure there is expected traffic? If you're running selinux or something equivalent on the agent/proxy?  You might want to disable it and try again to see if this is the cause. -Zeb

Thanks Victor & johnnyva. It works

of course like 99% of the time when you post question you find the answer. I read the doumentation wrong "(not used by ODBC driver)." is only DBName not DBPassword like i first thought, moved password from odbc to netxmsd.conf and now it works.

This is now fixed in 3.8.382

Hi, this is bug NX-1964: https://track.radensolutions.com/issue/NX-1964. It is fixed in development branch, but not in version 3.8. In the meantime, create user and database manually and choose to initialize existing database in installation wizard. Best regards, Victor

Thanks Filipp!

Thanks, that looks to have sorted it. Strange that script has been running for a year and only broke after the last update.

Hi Victor, thanks for the info... Will test this again after next patch relase... Greetings Marco

It looks like file is actually transferred, but sender just don't wait enough for final confirmation, which is probably take more time due to target system load. I have increased wait time for confirmation on file upload, hopefully it will help. Change will be included into next patch release. Best regards, Victor

Awesome, thank you!  I will try this.

If osquery supports ODBC, then it could be accessed that was as dbquery sybagent supports ODBC. Otherwise it could be technically possible to develop netxms database driver that would support osquery.

Hello! You can turn on TLS in driver by adding DBDrvParams = enforceTLS=true to netxmsd.conf. User authentication with X.509 certificates is not supported. Best regards, Victor

Did you install from packager or compiled? Can you set DebugLevel=6 in server configuration file, start the server, wait for it to crash and share last few lines of the log?

The below reply I received from Jira support. Kindly help here This can be caused by one (or several of three broad things) The connector is not compatible with your Jira The connector has been compiled with a different version of Java, and is not compatible with the Java underneath your Jira The connector has a bug I would check the release compatibility with the vendor's docs (ideally, don't install a jar, use the marketplace for apps), and then raise a support request with them if they tell you the version you have is compatible with your Jira

oh! I've got it: oldestAlarmTime = min(oldestAlarmTime, a->creationTime); println n->id . "\t" . n->name . "\t" . a->message . "\t" . strftime("%Y-%m-%d %H:%M", a->creationTime); Thanks to all. BB

If DCI has node name in "Template" column this means that this DCI was created by instance discovery. Somewhere on the node there should be prototype DCI, which defines how instance discovery is happening. e.g. in the attache image DCI with ID 4957 is instance prototype. It's coming from Generic UNIX template. Other DCI are created with instance discovery based on this DCI. [image: Screenshot at 2021-05-10 15-10-37.png]

Values in Server Configuration are   StatusPropagationAlgorithm: Unchanged   StatusCalculationAlgorithm: Most critical I'll try to describe the 'issue' in other words: The 'port down' event (minor) leads into 'port status' critical > minor ≠ critical The 'port unexpected up' event (major) leads into 'port status' critical > major ≠ critical A change within StatusPropagationAlgorithm and StatusCalculationAlgorithm won't fix it. It's a decision of development or a bug. Greetings