NetXMS Support Forum

nxdbmgr actually do this migration for all images - but stock images (there are 9) are deleted by the upgrade process before the actual migration. Current build of both debs and rpms have workaround for that, and it's completely fixed in upcoming 6.2.1.

Hi,

The problem is the servlet container version, not Java.

The NetXMS 6.2 web client (nxmc-6.2.0.war) is built against the Jakarta Servlet API (jakarta.servlet.* namespace) and requires a container that supports it. You are running Tomcat 9.0.58, which still uses the older javax.servlet.* namespace. Because of that, Tomcat 9 cannot load the application's context listeners, which is exactly the "One or more listeners failed to start" / "Context startup failed" error you see.

The ClassCastException about ObjectStreamClass$Caches is a harmless secondary warning. It comes from Tomcat's cleanup routine running on a newer JDK while it tears down the already-failed context - it is not the cause. That is also why switching from JDK 17 to 21 made no difference; the JDK was never the issue.

To fix it, deploy the WAR on a container that supports the Jakarta Servlet API:

- Tomcat 10.1 or later - on Ubuntu use the tomcat10 package, webapps directory /var/lib/tomcat10/webapps.
- Jetty 11 or later is also fine (Jetty 11/12 support the Jakarta Servlet API).

Java 17 or 21 works with either. Do not run it under Tomcat 9 - the javax vs jakarta namespace difference cannot be bridged by a config change or a different JDK.

It's a know issue, we are working on that right now. Should be improved in next patch release.

It's just png tiles, yes.

But according to our monitoring and my manual check - it's just fine (e.g. https://tile.netxms.org/osm/0/0/0.png, https://tile.netxms.org/osm/14/9288/5023.png)

What kind of error you got?

I've pushed 6.2.0-2, which have workaround for this issue.
Note: workaround only handles stock images, if any custom was uploaded and then deleted directly on the filesystem - upgrade will fail.

List of stock files:
092e4b35-4e7c-42df-b9b7-d5805bfac64e
1ddb76a3-a05f-4a42-acda-22021768feaf
7cd999e9-fbe0-45c3-a695-f84523b3a50c
904e7291-ee3f-41b7-8132-2bd29288ecc8
b314cf44-b2aa-478e-b23a-73bc5bb9a624
ba6ab507-f62d-4b8f-824c-ca9d46f22375
bacde727-b183-4e6c-8dca-ab024c88b999
f5214d16-1ab1-4577-bb21-063cfd45d7af
f9105c54-8dcf-483a-b387-b4587dfd3cba


Simplest approach for missing custom images - create empty file, e.g. "touch /var/lib/netxms/images/...".

Hi,

Those messages are warnings, not errors. Upgrade did not fail. This is normal PostgreSQL collation mismatch. Has nothing to do with 15→17 — comes only from Debian 12→13, because Trixie has glibc 2.41 instead of 2.36, and PostgreSQL remembers glibc version used to build indexes.

For in-place upgrade use pg_upgradecluster. Stop NetXMS, make dump for safety, drop empty PG17 cluster that was auto-created, then upgrade:

systemctl stop netxms-server
sudo -u postgres pg_dump -Fc netxms > /backup/netxms.dump   # safety net
pg_dropcluster 17 main --stop        # remove empty auto-created PG17 cluster
pg_upgradecluster 15 main
nxdbmgr check
systemctl start netxms-server
# when verified:  pg_dropcluster 15 main

Important detail: pg_upgradecluster without --method=upgrade uses dump method inside. It rebuilds all indexes under new glibc, so you get no collation warnings and no reindex needed. Only -m upgrade / -m link (fast file-reuse mode) makes the warnings. If you use that mode, fix it correct way — reindex first, then refresh — for each database (netxms, postgres, template1):

REINDEX DATABASE netxms;
ALTER DATABASE netxms REFRESH COLLATION VERSION;

Do not run only REFRESH. It hides warning but leaves bad-sorted indexes. Reindex is mandatory.

Comments are available in open testing track (https://play.google.com/apps/testing/org.netxms.android); 1.0.6 / build 27.

Quote from: hellium on June 10, 2026, 03:39:56 PMBut the mobile client is incredibly limited in what data it shows.

well, that's why I'm asking for feedback

I've added comments section on object details, will be included in next update.

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).