NetXMS Support Forum

qtech-olt is an old driver module, now it is called qtech. So what happened is that server attempted to load driver module built for old version, which had now incorrect references to other libraries.
If you are building server from source, make sure that before doing "make install" (or copying binaries to target machine) you removed everything from <install_prefix>/lib/netxms (/usr/local/lib/netxms in your case).

Best regards,
Victor

We just published NetXMS version 4.5.4. It is minor patch release that fixes few important issues found in 4.5.3. Full change log:

- Improved Juniper driver
- Improved integration with ticketing system Redmine
- Fixed build errors on Solaris 11.4 with Solaris Studio 12.6
- Fixed memory leak in web UI (server side)
- Fixed some server performance issues
- Fixed issues:
-  NX-2492 (Custom attribute inheritance conflict not detected)
-  NX-2515 (Inherited object custom attributes not deleted from children)

Hi,

on what operating system and what client (standalone jar, from installer)? Also, Do you have dark theme in the OS?

Best regards,
Victor

This is quite strange. Do you have alarms with huge repeat counts?

Best regards,
Victor

Yes, it's better to stop it.

Best regards,
Victor

Hello!

It will use server time.

Just fixed typo, thank you!

Best regards,
Victor

That usually means that server is not running.

Best regards,
Victor

Seems to be MariaDB specific issue. I'm not an expert on it unfortunately, but seems that they have all sort of strange limits on tables. One thing you may want to look at is big_tables configuration option. Maybe you should turn it on. Or consider migration to PostgreSQL
How many records do you have in this table? And how many active alarms? It is a bit unexpected that event_log for example works fine, but alarm_events is full. This table should contain event records for active alarms only.

Best regards,
Victor

P.S. Primary key on that table is alarm_id,event_id - those are two integers, so should not be an issue as such.

It works as following. First of all, you have to enable TCP proxy on a proxy agent. By default it will be agent running on NetXMS server, or if zoning is enabled, agent running on zone proxy. When you run object tool with TCP proxy option, client will open random local port for listening, then establish tunnel to proxy agent, and when you open TCP connection to this random local port, proxy agent will establish TCP connection to target node on port set in object tool configuration.

So, for example, let's say you have Synology device reachable at 192.168.1.10 by the server. You will do the following steps:
1. You Synology device to NetXMS as a node, and specify 192.168.1.10 as primary IP address.
2. Enable TCP proxy on server's agent.
3. Enable TCP port forwarding option in object tool, and use URL http://${local-address}:${local-port}

When running on Synology node, this tool should open browser on local host which will be forwarded to Synology device.

Best regards,
Victor

Hi,

it looks to be disk space issue. You probably can truncate biggest tables (possible candidates are event_log and top idata_ tables). 
If you are ok with losing all alarms and event history, you can truncate tables event_log, alarms, alarm_events, and alarm_notes.

What database you are using?

Best regards,
Victor

Sure, we can add it, question is how agent can detect that it is running on Nutanix VM. Can we rely on BIOS vendor information for that? If yes, then change is quite easy.

Best regards,
Victor

We just published NetXMS version 4.5.3. It is purely bug fix release that fixes few important issues. Full change log since 4.5.2:

- Fixed server crash during passive network discovery
- Fixed bug in dashboard chart data source editor
- Fixed bug in TCP proxy session setup
- Fixed issues:
   - NX-2509 (productVersion does not display value correctly with Ethernet-IP)

I just fixed that. We will publish patch release with the fix shortly.

Best regards,
Victor

We just published patch release 2 for version 4.5. It contains few important fixes and some small improvements. Full change log is following:

- Fixed server crash on client session disconnect
- Fixed updated issues in new web UI
- Cosmetic fixes in UI
- Fixed issues:
   - NX-2490 (Server tries to read from tdata_xxxx table when TimescaleDB is used as backend)
   - NX-2502 (nxagentd uses UDP port 4700 to exchange hearthbeat messages and listens on address 0.0.0.0)

You can create scheduled task that will run NXSL script on any top level object ("entire network" or "infrastructure services"). In that script you can do something like this:

for(a : $object->alarms)
{
   a->terminate();
}

Alternatively you can use FindObejct(2) to refer to "infrastructure services" instead of $object - then you can run script in any context.

You can add additional logic to terminate only old alarms, etc.

Best regards,
Victor