NetXMS Support Forum

Hi,

nxmc is already jakarta — it's built against jakarta.servlet-api 6.0 and its web.xml declares Jakarta EE 10, so ee10 in your setup is correct. What's failing is that the file you deployed as nxmc-6.2.4.war is not the web UI, it's the Legacy Web API war (netxms-websvc). That one is still javax/EE8 and under ee10 it fails exactly like this.

Two things in your log point at it: the missing class is javax/servlet/http/HttpServlet, which nxmc has no reference to at all, and the context starts as "NetXMS REST API" — that display name comes from the API war's web.xml, the web UI war has no display name.

Check with:

unzip -p /usr/share/jetty-base/webapps/nxmc-6.2.4.war WEB-INF/web.xml | head -8
The web UI war has xmlns="https://jakarta.ee/xml/ns/jakartaee" and version="6.0". What you have will show <display-name>NetXMS REST API</display-name> and version="2.4".

Re-download nxmc-6.2.4.war from the Web Interface Binaries section — the two files sit next to each other there — and it deploys into your existing ee10 setup unchanged.

Many thanks Alex,

found images and working on them now...

+--------------------------------------+-----------------------------------------------------------------+----------+--------------------+
| guid                                 | name                                                            | category | LENGTH(image_data) |
+--------------------------------------+-----------------------------------------------------------------+----------+--------------------+
| 81652d15-df62-44ca-9f6b-55c68c6d8670 | schema sinottico REALE alimentazione Palma Piani DRAWIO-NOAVV   | Default  |            1824040 |
| 2ffbcbdb-a04e-488b-91ec-54c48de952e6 | mappa_sfondo                                                    | Default  |            1603868 |
| f5440229-8d66-4f32-a12c-1d984a2479bd | schema sinottico REALE alimentazione Trieste DRAWIO-NOAVV       | Default  |            1581020 |
| 9e5a6fdf-cc27-4440-bc3b-364912304f34 | schema sinottico REALE alimentazione CED Palmanova DRAWIO-NOAVV | Default  |            1093976 |
| 4da68704-046f-4a78-afad-cd3ecf417687 | bw_mappa_sfondo                                                 | Default  |             934132 |
| 94249c03-ba41-4fa8-bb61-ec9441bab325 | schema sinottico REALE alimentazione UD-Fiera DRAWIO-NOAVV      | Default  |             805556 |

The backtrace pins it exactly: it's a bug in our MariaDB driver, triggered by an oversized entry in the image library.

Since 6.2 images are stored in the database instead of as files, and the driver allocates the buffer for a field on the stack, sized by the length of that field. Server worker threads get a 1 MB stack by default, so an image over roughly 780 KB overflows it and the process dies the moment anything asks for that image - which is what opening the dashboard does. The upgrade migrates existing image files into the database, so an image that had been fine for years starts crashing the server right after.

Two steps to get you running again.

1) Add to netxmsd.conf and restart the server:

DefaultThreadStackSize=8M
That raises the worker stacks and stops the crash right away.

2) Find the image and replace it with a smaller one:

SELECT guid, name, category, LENGTH(image_data) FROM images ORDER BY LENGTH(image_data) DESC LIMIT 5;
Anything near or above 1000000 is the one. Re-upload a downscaled version through the image library - listing and re-uploading are safe, only fetching the image bytes crashes.

Ticket is https://github.com/netxms/netxms/issues/3637 - the driver should allocate large fields on the heap, not the stack.

Thanks Alex,

here it is:

#0  0x00007ffff74b7b77 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff4fedebf in ?? () from /lib/x86_64-linux-gnu/libmariadb.so.3
#2  0x00007ffff4fef2b0 in ?? () from /lib/x86_64-linux-gnu/libmariadb.so.3
#3  0x00007ffff4fea43e in mysql_stmt_fetch_column () from /lib/x86_64-linux-gnu/libmariadb.so.3
#4  0x00007ffff6050ebe in GetFieldInternal (result=0x7ffff4442920, iRow=<optimized out>, iColumn=4, buffer=0x7fffd8e1a800,
    bufferSize=2187953, utf8=<optimized out>) at mariadb/mariadb.cpp:693
#5  0x00007ffff783cf6e in DBGetFieldUTF8 (hResult=0x7fffde414cc0, row=0, column=4, buffer=<optimized out>, bufferSize=0) at session.cpp:561
#6  0x00007ffff783d87c in DBGetFieldBinary (hResult=hResult@entry=0x7fffde414cc0, row=row@entry=0, column=column@entry=4,
    length=length@entry=0x7fffdf5f9538) at session.cpp:846
#7  0x00007ffff7c618d6 in ClientSession::sendLibraryImage (this=this@entry=0x7ffff4a34000, request=...) at session.cpp:13810
#8  0x00007ffff7c827f9 in ClientSession::processRequest (this=0x7ffff4a34000, request=0x7fffe9141f30) at session.cpp:1651
#9  0x00007ffff7c2cde2 in __ThreadPoolExecute_Wrapper_1<ClientSession, NXCPMessage*> (arg=0x7fffe912aca0)
    at ../../../include/nms_threads.h:1046
#10 0x00007ffff77e41f5 in WorkerThread (threadInfo=0x7fffefc77af0) at tp.cpp:228
#11 0x00007ffff77e532b in ThreadCreate_Wrapper_1<WorkerThreadInfo*> (context=0x7fffefc77a00) at ../../include/nms_threads.h:354
#12 0x00007ffff770dea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x00007ffff7444aef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Hi,

Fastest way to pin this down is to run the server under gdb and let it stop at the crash - the backtrace names the code path directly.

apt install netxms-dbg
systemctl stop netxms-server
gdb /usr/bin/netxmsd
run -D3
# open the dashboard in the client, wait for the crash
bt

Post the bt output here.

netxms-dbg is required - without it the backtrace is just hex addresses and tells us nothing. Without -d or -S netxmsd stays in foreground, which is what we want; it also starts interactive console there, so add -q if that gets in the way of gdb.

Note: Scripts.RestrictWriteAccess has no effect here. Dashboard element scripts run under user security context, not the read-only one that parameter controls, so toggling it changes nothing either way.

Hello,

after updating to version 6.2.4 (server, agent, client...), opening one of our custom dashboards causes the server to crash; how can we identify the cause of the problem?

We tried disabling "Scripts.RestrictWriteAccess", but without success.

Thanks in advance,

Alessio.

Hello,

I'm running NetXMS 6.2.4.

Network discovery does not use the SNMP community string (stonewell2000) configured in SNMP credentials. It always uses the default "public" instead.

Every discovered device needs manual correction of the SNMP community string before it can get SNMP data properly.

Please help check this issue. Thanks so much.

Hi,

I'm trying to upgrade from 6.2.1 to 6.2.4
While the upgrade of the applications seems to ok, the webserver can't deploy the war-file.

Shouldn't jakarta be referenced instead of javax?

java -jar /opt/jetty-home-12.0.39/start.jar --list-module
Enabled Modules:
----------------
  0) alpn-java                 transitive provider of alpn-impl for alpn
  1) resources                 transitive provider of resources for logging-logback
  2) logging/slf4j             dynamic dependency of logging-logback
                               transitive provider of logging/slf4j for logging-logback
  3) logging-logback           ${jetty.base}/start.d/logging-logback.ini
  4) bytebufferpool            transitive provider of bytebufferpool for server
                               ini template available with --add-modules=bytebufferpool
  5) threadpool                transitive provider of threadpool for server
                               ini template available with --add-modules=threadpool
  6) server                    ${jetty.base}/start.d/server.ini
  7) ssl                       ${jetty.base}/start.d/ssl.ini
  8) alpn                      transitive provider of alpn for http2
                               ini template available with --add-modules=alpn
  9) client                    transitive provider of client for websocket-core-client
 10) deploy                    transitive provider of deploy for ee10-deploy
 11) sessions                  transitive provider of sessions for ee10-servlet
                               ini template available with --add-modules=sessions
 12) ee10-servlet              transitive provider of ee10-servlet for ee10-webapp
                               transitive provider of ee10-servlet for ee10-security
 13) security                  transitive provider of security for ee10-security
 14) ee10-security             transitive provider of ee10-security for ee10-webapp
                               transitive provider of ee10-security for ee10-plus
 15) ee-webapp                 transitive provider of ee-webapp for ee10-webapp
                               ini template available with --add-modules=ee-webapp
 16) ee10-webapp               transitive provider of ee10-webapp for ee10-plus
                               transitive provider of ee10-webapp for ee10-deploy
                               ini template available with --add-modules=ee10-webapp
 17) plus                      ${jetty.base}/start.d/plus.ini
 18) jndi                      transitive provider of jndi for ee10-plus
 19) ee10-plus                 transitive provider of ee10-plus for ee10-annotations
 20) ee10-annotations          transitive provider of ee10-annotations for ee10-websocket-jetty
                               transitive provider of ee10-annotations for ee10-websocket-jakarta
 21) ee10-deploy               ${jetty.base}/start.d/ee10-deploy.ini
 22) websocket-core-client     transitive provider of websocket-core-client for ee10-websocket-jakarta
 23) websocket-core-server     transitive provider of websocket-core-server for websocket-jetty
                               transitive provider of websocket-core-server for ee10-websocket-jakarta
 24) ee10-websocket-jakarta    ${jetty.base}/start.d/ee10-websocket-jakarta.ini
 25) websocket-jetty           transitive provider of websocket-jetty for ee10-websocket-jetty
 26) ee10-websocket-jetty      ${jetty.base}/start.d/ee10-websocket-jetty.ini
 27) gzip                      ${jetty.base}/start.d/gzip.ini
 28) http                      ${jetty.base}/start.d/http.ini
 29) http2                     ${jetty.base}/start.d/http2.ini
 30) https                     ${jetty.base}/start.d/https.ini
 31) work                      ${jetty.base}/start.d/work.ini
journalctl jetty.service:
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.348:INFO :oejs.Server:main: jetty-12.0.39; built: 2026-09-04T08:12:14.620Z; git: 23f845b712e7ab5aa7cee1bdec31fadd308b0fd8; jvm 19.0.2+7-Ubuntu-0ubuntu322.04
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.369:INFO :oejdp.ScanningAppProvider:main: Deployment monitor ee10 in [file:///usr/share/jetty-base/webapps/] at intervals 0s
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.374:INFO :oejd.DeploymentManager:main: addApp: App@4ef37659[ee10,null,/usr/share/jetty-base/webapps/nxmc-6.2.4.war]
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.547:INFO :oejew.StandardDescriptorProcessor:main: NO JSP Support for /nxmc-6.2.4, did not find org.eclipse.jetty.ee10.jsp.JettyJspServlet
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.559:INFO :oejsh.ContextHandler:main: Started oeje10w.WebAppContext@3e44f2a5{NetXMS REST API,/nxmc-6.2.4,b=file:///tmp/jetty-0_0_0_0-8080-nxmc-6_2_4_war-_nxmc-6_2_4-any
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.570:WARN :oejew.WebAppContext:main: Failed startup of context oeje10w.WebAppContext@3e44f2a5{NetXMS REST API,/nxmc-6.2.4,b=file:///tmp/jetty-0_0_0_0-8080-nxmc-6_2_4_war-_nxmc-6_2_4-any-4-4077838918963996153/webapp/,a=AVAILABLE,h=oeje10s.SessionHandler@295cf707{STARTED}}{/usr/share/jetty-base/webapps/nxmc-6.2.4.war}
Sep 08 12:27:23 <servername> java[259854]: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet
<- content cut due to character limit ->
Sep 08 12:27:23 <servername> java[259854]:    at org.eclipse.jetty.start.Main.main(Main.java:82)
Sep 08 12:27:23 <servername> java[259854]: Caused by:
Sep 08 12:27:23 <servername> java[259854]: java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet
<- content cut due to character limit ->
Sep 08 12:27:23 <servername> java[259854]:    at org.eclipse.jetty.start.Main.main(Main.java:82)
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.572:INFO :oejdp.ScanningAppProvider:main: Deployment monitor ee8 in [file:///usr/share/jetty-base/webapps/] at intervals 0s
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.573:INFO :oejs.DefaultSessionIdManager:main: Session workerName=node0
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.580:INFO :oejs.AbstractConnector:main: Started ServerConnector@400fd762{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
Sep 08 12:27:23 <servername> java[259854]: 2026-09-08 12:27:23.587:INFO :oejs.Server:main: Started oejs.Server@23348b5d{STARTING}[12.0.39,sto=0] @934ms

Thank you for pointing me in the right direction, I had not created the webhook correctly.

Hi,

Not fixed - I've reopened https://github.com/netxms/netxms/issues/3137. It was closed against a different fix (#3240) that only covered part of the problem.

Your combination is not the version mismatch Filipp mentioned - agent 6.2.3 and server 6.2.2 both contain everything from that work, so the "server must also be 6.2" note does not apply to you.

What is left: the agent can still change the reported user name, and sometimes the display name, for the same Store package between two polls, without signalling that the data is incomplete. Since 6.1 the server treats package name plus user as the package identity, so any such change comes out as a remove plus an install. Most likely triggers are a user profile whose registry hive is not on disk while the user is logged off (roaming profiles, FSLogix, UPD), and a failed SID-to-username lookup.

To tell which one you are hitting, please post:

• nxagentd log with debug level 6 for tag "winnt", covering a full logon and logoff
• System.InstalledProducts table taken twice - once with a user logged on, once without
• whether these are RDS/terminal servers, and whether profiles are roaming, FSLogix or UPD

Workaround is poor. There is no way to exclude Store packages from the inventory, and the inventory is collected on every configuration poll. Since 6.1 SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED carry the user name as an event parameter, but filtering on it only removes half of each pair - the other half is reported as a system-wide package with empty user.