NetXMS Support Forum

Fixes were made to Fortinet driver. If you are on Linux, you can build current netxms server from master branch to test it on your devices - compilation docs are here: https://github.com/netxms/netxms/blob/master/CONTRIBUTING.md#%EF%B8%8F-development-setup

Or just wait for the release of v. 6.2

Основные события это SYS_NODE_DOWN / SYS_NODE_UNREACHABLE, а когда нода поднимается обратно то SYS_NODE_UP. Попробуйте на них настроить нотификации.

This is internal mechanism used for delayed action execution from a EPP rule. You can configure action in EPP with a delay, e.g. in Maintenance Start rule and you'll see what params this scheduled task gets. Nothing strictly forbids from scheduling your own action executions, but since this is internal mechanism, params or anything may change in the future.
Minimal set of params looks like this:
action=1;event=51385
so you need to know ID of action (it's not visible in the GUI) and you need to specify some event.

More recommended way is to use Execute.Script, in this case param field is just script name from script library (and script parameters in bracket if these are needed).

Перечитал внимательно изначальное сообщение с логами событий - там на ноде не возникало события SYS_AGENT_UNREACHABLE, a было только SYS_NODE_UNREACHABLE - сервер понимает что из-за отсутствия прокси нода недоступна и не генерит отдельные события про агента.
Поэтому таймер не заводился и поэтому ничто не ограничивало отправку нотификации когда пришло SYS_AGENT_OK

1. установить пакеты netxms-dbg и gdb
2. распаковать креш дамп:
apport-unpack /var/crash/YOUR_CRASH_FILE TARGET_DIRECTORY
3. перейти в эту директорию
cd TARGET_DIRECTORY
4. запустить gdb
gdb /usr/bin/netxmsd CoreDump
5. в gdb дать команду
bt

и покажите вывод

Hi,

Is it possible that you could provide remote access to some lab fortiswitch so our developers could talk to it to improve the drivers?

Or at least please share output of
  snmpwalk -v2c -c <community> <switch_ip> 1.0.8802.1.1.2.1.3.7.1
  snmpwalk -v2c -c <community> <switch_ip> 1.3.6.1.2.1.17.1.4.1.2
  snmpwalk -v2c -c <community> <switch_ip> 1.3.6.1.2.1.2.2.1.2
  snmpget -v2c -c <community> <switch_ip> 1.3.6.1.2.1.1.2.0

What NetXMS version are you using?

Pls show screenshot of properties of a specific subnet in network discovery.

Do you use proxies in these zones or server has direct connectivity to nodes in these zones?

I've created tickets covering above-mentioned issues:


https://github.com/netxms/netxms/issues/3278
https://github.com/netxms/netxms/issues/3277
https://github.com/netxms/netxms/issues/3276

После такого завершения с ошибкой посмотрите в /var/log/netxmsd - если там видно что сервер рестартовал, то он вероятно крешится. Тогда нужно посмотреть, создался ли core файл (crash dump). Если ubuntu, то они обычно создаются в /var/crash

Уведомление здесь с задержкой, я бы посмотрел в Configuration -> Scheduled tasks (там есть галочка show system tasks) живет ли этот таймер и не пропадает ли раньше времени.

В русском канале https://t.me/netxms_ru есть @me_is_nem0, он занимался драйверами для девайсов специфичных для РФ, попробуйте с ним пообщаться.

Даб там в логе Cannot compile report /var/lib/netxms/nxreportd/definitions/WAN-int-1.0.1/main.jrxml
 net.sf.jasperreports.engine.JRException: org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 232; cvc-complex-type.3.2.2: Attribute 'uuid' is not allowed to appear in element 'jasperReport'.

Так что да, директория создалась, но скомпилироваться он не смог и поэтому его и в списке нет.

Я забыл упомянть выше, что нужна версия Jasper Studio 6.20.5 или младше. Тут похоже что версия более новая.

Я в принципе у claude такие вещи спрашиваю, вот его ответ по этой ошбике:
The error is a JRXML schema validation failure: the bundled JasperReports library in nxreportd is validating against an XSD that does
   not allow uuid on the root <jasperReport> element. This usually means the JRXML was produced by a Jaspersoft Studio newer than the
  JR runtime on the reporting server.

  A couple of options to unblock the deploy:

  1. Quick fix — open main.jrxml and delete the uuid="..." attribute from the <jasperReport ...> root tag, then rebuild. If validation then
   complains about uuid on a nested element (e.g. <band>, <textField>), strip those too. A one-shot scrub:
  sed -i 's/ uuid="[^"]*"//g' src/main/resources/main.jrxml
  2. Real fix — design the report in a Jaspersoft Studio version aligned with the JR library shipped with this NetXMS server. The two
  sample JRXMLs in this repo are produced with Jaspersoft Studio 6.16/6.19 (JasperReports Library 6.x), and they're known to deploy.
  Anything noticeably newer (7.x / 9.x) will emit XML features the server's older XSD rejects.

  For context: the samples in this repo (users/src/main/resources/main.jrxml and user-input/src/main/resources/main.jrxml) do carry
  uuid on <jasperReport> and deploy fine, so the user's server is matched to a stricter/older XSD than the one the samples were
  validated against — confirming the version-mismatch diagnosis. Designing with Studio 6.16–6.19 is the safest path.

Same happens on Ubuntu 26, created issue: https://github.com/netxms/netxms/issues/3250

Are you running Qwen locally? Under what tool?

The "XML tool call" output is what Qwen models emit at the raw model layer. Almost all production inference servers convert that into standard OpenAI JSON tool_calls before returning the response — so Qwen normally works fine with NetXMS if the inference server is configured to parse tool calls. For example:

- Ollama — works out of the box for Qwen models that ship with a tool-call template in their Modelfile. Point NetXMS at the Ollama provider and it will receive normal JSON tool_calls.
- vLLM — requires starting the server with --enable-auto-tool-choice --tool-call-parser hermes (or qwen3_coder for the newer parser). Then the OpenAI-compatible endpoint returns JSON tool_calls.
- SGLang / llama.cpp server — similar flags exist.

Which exactly is your NetXMS version?