NetXMS Support Forum

Hi Filipp,

I checked the audit log and found no failed login attempts. It appears that the grafana user (Used by Grafana over the API) logs in successfully and then 5-10mins later logs out. I believe this would be normal behavior?

I have also attached a screenshot should this help (Was unable to attach the image, received entity to large error from nginx so instead i have uploaded to imgur https://imgur.com/a/aHEaSMp)

A little more information should that help as well.

• When this max session problem happens, NetXMS seems to stop collecting metrics as once we restart it there is missing data in our graphs
• If i enter "nxadm -i" and try to kill the dead sessions with "kill %SESSION_ID%" it says the sessions was killed yet "show sessions" shows that the session is still there, so it appears these sessions can't be killed either the only way around is to restart the server

Hi Team,

Sorry for the delay, as this problem only happens every couple of days-weeks it is annoying to reproduce. I did some testing and was able to narrow it down to netxms-websvc.war web service. I use this integration to build Grafana dashboards. I test with no war files and then with the root only and with netxms-websvc only and it was when the netxms-websvc was re-introduced that the problem came back. Has this been experienced by anyone else? as we would really like to continue using our Grafana dashboards.

Hi Filipp,

Thank you for your reply and advice, I will update the debug level now and will have to wait a bit for those logs to come through as it can sometimes happen randomly when the queue fills.

I will post back here in the coming days when I find something, and currently no it is only the Grafana integration and the WebUI

Hi,

Currently every couple of days we have to restart our NetXMS-Server as we will not be able to connect to it through any method (desktop client, web client). When i check the logs in /var/log/netxmsd i see the following line repeated numerous times
" 2022.04.13 10:00:44.397 *W* [client.session     ] Too many client sessions open - unable to accept new client connection"

When i run the nxadm command "show sessions" i see 240 sessions defined as "DESKTOP <not logged in> [n/a]" this would sometimes be 255 however usually Grafana will occupy around 15 sessions (and still not be able to get data).

I have attached the output from the show session command and the netxmsd log file from when the server was started.

Versions
Desktop Client - 4.0.2227
NetXMS Server (Linux/Ubuntu) - 4.0.2227
radensolutions-netxms-datasource - 1.2.3
Grafana - 8.3.0
Java Version:
    openjdk 11.0.14.1 2022-02-08
    OpenJDK Runtime Environment (build 11.0.14.1+1-Ubuntu-0ubuntu1.18.04)
    OpenJDK 64-Bit Server VM (build 11.0.14.1+1-Ubuntu-0ubuntu1.18.04, mixed mode, sharing)

Hi,

We have recently build a topology map of our sites. To get it up on our monitoring TVs we put it in a dashboard to use the auto open feature.
However we noticed that alert icons and link status's do not update at all where as if you have the map open itself it will update almost instantly.
Is there a fix for this?

Please note this is the same issue as https://www.netxms.org/forum/general-support/problem-with-network-l2-map/msg26186/#msg26186 and similar to https://www.netxms.org/forum/general-support/l2-map-save-layout/msg23165/#msg23165. however these are rather old posts so I wanted to open a new one.

such that after generating a layer 2 topology map with automatic layout, I then disable automatic layout and place all the nodes neatly into logical positions for the team, however after a certain amount of time they loose their location and re-appear at the top left hand corner. I understand this is due to the server loosing topology information however the devices do not change after they are picked back up so I would like them to go back to the same spots.

This wold save me either having to re-move around 10-20 nodes on around 20 maps every couple of days, or re-making every map statically and having to update it manually (Which is prone to human error).

Is there a way around this or should I move it to Feature Requests?
Thanks in Advance