NetXMS Support Forum

Found the issue, docker ran with POSIX had to add

ENV LANG=C.UTF-8
ENV LC_ALL=C.UTF-8

Now it works with åäö

Tested with agent running on full debian 12 VM and no issue with åäö in action making this something with my docker setup it seems like.

it is the official docker setup from github though, will see if i have messed something up.

#!/bin/sh
# /agent/script/ping.sh
LOG=/agent/script/logs
mkdir -p "$LOG"

TS="$(date -u +%Y%m%dT%H%M%SZ)"
{
  echo "----- $TS -----"
  echo "PWD: $(pwd)"
  echo "USER: $(id)"
  echo "ARGV_STR: $*"
} >> "$LOG/ping.txt"

printf '%s\n' "$@" | od -An -t x1 >> "$LOG/ping-bytes.hex" 2>/dev/null || true

i tried Action=debug:echo "$1" >> /agent/script/a.txt also to have it as simple as possible and
$node.executeAgentCommand("debug","test") creates a.txt containing test
$node.executeAgentCommand("debug","testå") does not create a.txt, not error in agent log just "Execution of external action debug (echo "testå" >> /agent/script/a.txt) started"

If i run echo "testå" >> /agent/script/a.txt manually in same docker agent is running a.txt is created as utf8 and containing testå

Trying to create an action that runs a script but as soon as i have char åäö in parameter it seems like it fails to run the process, have agent in debuglevel 6 and no error shows up it runs process and it shows PID for it.

I have verified that everything i can think of is utf8

made debug script that logs to file if run Action=debug:/agent/script/ping.sh --message "$1"

$node.executeAgentCommand("debug","test") runs fine and log files are created
$node.executeAgentCommand("debug","testå") is executed according to agent log and gets PID but no logs are created and i can't figure any more deeper way to debug

Running agent 5.2.6 on Debian 12 in docker

if i run script in docker cli it works with åäö only fails when agent runs the script.

Any tips or known issues?

I did that but after server restart everything got 401 unauthorized and i had to reissue token.
I see now that log states "New persistent authentication token issued for user grafana [10]" i guess something might be wrong with token save then.

Is it possible to create permanent auth token for new API server?

Actually when i think about it would be great if there is a parameter for objects history that just returns latest value regardless of time. That would solve a lot of time related challenges we have in Grafana for dashboards with lots of values with first calculation option.

Edit:

found it maxRows=1

Hi,

Started migrating our Grafana to Infinity and new server api.
Saw the techtalk video on youtube and the blog post nice work.

One thing i noticed was that you use $__from/1000 and $__to/1000 for seconds and was having issue it not working, found that Grafana has these variables i guess they are cleaner to use ${__from:date:seconds} and ${__to:date:seconds}

Also trying to get relative time to work, i have dashboard on last 30min beacuse they are used on TV screens but some DCI just collects once a day and i have 12h relative on them, tried ${__from:date:seconds}-43200 but does not seem to work i get all 3 days that are in history.

is it supposed to calc before query or send it to api? URL is ?timeFrom=1760509472-43200&timeTo=1760511272

Running 5.2.6 and latest Inifinity

Hi,

Any news on new NetXMS connector for Grafana?

Hi,

Time to renew this?

Tried clean test server install with just the node that do not work and it works on test server.
Tried renaming and then recreate the node that does not work and now snmp v3 works on the new node on production server.
Odd issue that only snmp v3 is not working on some old nodes.

I will recreate all nodes to be safe.

Hi,

Any known issues with connecting to snmp v3 agents?
Have odd issue where some nodes work and some don't with the exact same auth configuration.

The node that netxms can't connect to agent with v3 is verified that the agent is running and v3 auth information works in other snmp explorer software.

The node can connect with v2c if enabled, just v3 having issues.

Tried debug logs but since it is the server very hard with spammed debug log, set snmp.discovery to level 6 and it shows SnmpCheckV3CommSettings trying then fail.

When i do full config poll on a node that V3 works on there is no SnmpCheckV3CommSettings in logs it just connects and polls.

The nodes that V3 work on and the nodes that does not have exact same config no question since the snmp is set with nxshell script on all nodes in the container.

To send mail with authenticated SMTP with 365 user the account has to have that function enabled.
Since it is big security issue for bigger organisations that function is most likely disabled. 

Moved SQL queries to use ExternalMetric instead more control over connections and errors that way so in general better way so far.

Also looking forward to new grafana connector.
It is normal for current one to eat up sessions, every panel and query you have that has some DCI reference will create session on page load. when page has loaded the sesssions slowly die and if you leave the page with only panel refreshes it keeps sessions low but as soon as you do side refresh in browser it start all sessions again.

Been strugling for a long time with grafana eating up over 128 sessions making server unconnectable until sessions die off.