NetXMS Support Forum

You can silence these alarms by disabling rules for events SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED.

I've reopened issue, so devs will look into it.

1. Topology.DefaultDiscoveryRadius

After checking the code, the ad-hoc Topology maps → Layer 2 topology action does send the "use server default" sentinel from the client, and the server is supposed to substitute Topology.DefaultDiscoveryRadius for it. However, we have found a likely bug in how that sentinel survives the trip from client to server (signed/unsigned conversion of the radius field) that can cause the server to use a huge depth instead of the configured one — which matches what you are seeing.

We are opening an internal ticket for the developers to verify and fix. To confirm whether your installation is affected, could you share:

• Server build number and desktop client build number (full version strings).
• A short server log captured during one click on the menu, with these debug tags enabled:
  
  Code Select Expand
  DebugTags = topo.*:7,poll.topology:7,topology.*:7We are interested in the nDepth= value the topology builder receives. If it is something like 4294967295 (or any value other than 5), that is the bug confirmed for your environment.

2. MSTP links via ISP-side intermediate devices

This part is expected behavior, not a bug. NetXMS builds L2 topology by reading FDB, LLDP, CDP and STP tables from each managed device. If the intermediate ISP devices are not managed in NetXMS, there are no neighbor records on the path between your two end nodes, so the server cannot infer the connection. The requirement that all network equipment be registered in the system is documented here: Network topology.

Two ways forward:

• Add the ISP intermediate devices as managed nodes (needs SNMP access from your monitoring zone). Once they participate, LLDP/CDP/STP from each side will let NetXMS stitch the path.
• If you cannot manage them, automatic end-to-end discovery across them will not work — you can add the link manually as a connection on a Network Map.

Useful diagnostic regardless: on each end node's Interfaces tab, the Peer Discovery Protocol column shows how (or whether) each neighbor was discovered — that confirms which protocol is or isn't reaching across the ISP segment.

We will update this thread once the developers confirm the fix for #1.

The "keeps retrying" is by design, and the reason "Hide" is the only menu option on a Failed row is intentional too. Here's what's actually happening:

When a package deployment attempt fails with a transient error (e.g. "Unable to connect to agent"), the server marks the current job as Failed and creates a new job in Scheduled state, 10 minutes later. So you're not looking at one stuck job — you're looking at a chain of new jobs being added every ~10 min.

Consequences:

• You can't cancel a Failed job. The cancel action is only valid against jobs in Scheduled state. That's why "Hide" is the only thing the right-click gives you on a failed row — it's a view filter, not a state change.
• To break the loop, cancel the next Scheduled job in the chain, not the failed ones. Look for the row whose status is Scheduled (timestamped ~10 min after the most recent failure) and right-click → Cancel. After that, no new job will be created and the chain stops.
• Failed rows are cleaned up automatically by the housekeeper based on the server config PackageDeployment.JobRetentionTime (in days, default 7). Drop it temporarily (e.g. to 1) if you want them gone faster, then restore.

Worth checking the errorMessage on the failed rows too — if it's connectivity-related, cancelling alone is just a workaround; fixing agent reachability will stop new failures from being created.

For an SNMP table with a multi-part index, use SNMP Walk - OIDs as the instance discovery method. NetXMS walks the chosen column and uses the OID suffix — the entire composite index (e.g. 1.2, 2.1, ...) — as the instance name (docs). You then reference that suffix in the DCI's OID via {instance}.

Setup on the prototype DCI:

• Instance Discovery → Method: SNMP Walk - OIDs
• Base OID: a column that exists for every PSU — column 3 (name) works well: .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.3
• Metric OID (the DCI itself): .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.{instance}

{instance} is replaced with the composite suffix (e.g. 1.2) for each row, producing the correct per-PSU power OID.

For nice DCI display names, attach an Instance Discovery Filter Script that fetches the PSU name from column 3 at the same index and returns [instance, name] — first element keeps the composite suffix for OID substitution, second populates {instance-name} for the description (docs).

Side note: the power-consumption OID in your message has an extra .1 (...11.2.1.1.7.x.y). If columns 1, 2, 3 are group/slot/name as you describe, the power column is .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.x.y — worth double-checking with nxsnmpwalk before building the DCI.

Try escaping $ in the query

Начиная с 5.x, для веба нужна 17 джава

Hi cold,

Thanks for the report. This has been fixed in commit 4e26775.

The dbinit.sh script now auto-detects the database driver from the DBDriver setting in netxmsd.conf instead of hardcoding pgsql. If you set DBDriver=mariadb (or mysql) in your netxmsd.conf, the initialization will work automatically.

For the second issue — the missing dbinit_mariadb.sql — this is expected behavior. NetXMS uses "mysql" as the umbrella driver name for both MySQL and MariaDB SQL templates. So you should use DBDriver=mariadb in your config (the driver itself handles the connection correctly), but the schema initialization template is shared. With this fix, nxdbmgr init auto-selects the correct template, so you don't need to worry about it.

As a bonus, the fix also adds support for TimescaleDB initialization via the NETXMS_PG_TYPE environment variable (set NETXMS_PG_TYPE=tsdb on the init service).

The fix will be included in the next Docker image release (already in :latest).

Hi, 6.1.0 is live, 6.1.1 is merged, but still waiting for CI. Usually it's become available in matter of hours.

Quote from: dneil on April 16, 2026, 03:03:20 PMWhen will the 6.1 Client be released to Flathub?  I've updated my server today and now I don't have a working client on my Linux boxes.

Thanks, link was incorrect. Site now updated.

You can delete is directly from the database, it's stored in the table idata_N, where N is node id (e.g. idata_100).

Item ID can be found in table items (filter by node_id and name / description)

$node.ipAddr (string)

or $node.ipAddress (instance of InetAddress): https://netxms.org/documentation/nxsl-latest/#class-inetaddress

Can you check memory consumption during these days? Feels like a memory / resource leak.

That's rather interesting -- there are no similar reports.

Are you on 6.0.4? If not -- please give it a try. If it will not help -- temporary rollback to 5.2.8.

In 6.x we upgraded OpenSSL to mitigate CVE (we are not affected by it, but version scanners still getting triggered), and it might break something.

This screenshot looks like an output of the OpenSSH client (https://www.openssh.org), started without parameters.

What have you configured and what are you trying to achieve?

it's known issue, I'll publish app update soon