NetXMS Support Forum

sh st - только при запущенном сервере, но в принципе оттуда только количество нод нужно было.

cache mode тут в доке описан: https://netxms.org/documentation/adminguide/data-collection.html#offline-data-collection

Yes, these messages are 251-related. I've created ticket for this issue: https://github.com/netxms/netxms/issues/3322

Quote from: lhpaladin on June 12, 2026, 03:58:29 AMAnother question: can the password be entered using `nxencpasswd`?

Ups, that was forgotten in the implementation. Hopefully will be fixed in 6.2, created a ticket for it: https://github.com/netxms/netxms/issues/3321

For 2-hour window for a server action in an EPP rule set the following:
- Snooze time: 7200
- Snooze/blocking timer key: NODE_DOWN_%i

What this does - on the first time when action is executed is starts a timer with given key, on next executions it will run the action only if such timer is not running.

You can watch these timers in Configuration->Scheduled tasks if you enable "Show system tasks" there.

Is the problem is node-wide, e.g. node down you can use timer key with just %i macro - this will expand into node's id. If problem is related to a DCI use a %i_%<dciId> macro combination - this will be both node ID and DCI ID to ensure uniqueness of the timer key.

Могли быть недавние изменения в работе с прокси

что дальше в этих строчках в логе, "synchronized" или "not synchronized", каких строчек больше?

насколько большая система, покажите вывод sh st в debug console

сколько нод с агентами, работают ли они напрямую или через прокси, есть ли такое что на зонах указано больше одного прокси?

включен ли cache mode на агентах?

I don't see anything wrong in the configuration (the only thing to check if RAIDCONTROLLER_LSA_CRITICAL had "write to log" checkbox).

You can try right-clicking on the template and performing "Force deployment of agent policies".

Next step is to check that policy file is really present on this machine - they should be in C:\Windows\System32\ config\systemprofile\AppData\Local\nxagentd\logparser_ap (that's home folder of System user).

And next is to enable debug in agent config:
DebugTags = logwatch.*:7
agent log should have detailed information about logparser operations

XML parser error is not really an error - this happens in some places, e.g. if configuration of a notification channel is empty (or contains only comments).

/var/lib/netxms/netxms.cmib is more interesting. Is your server running under root user or some other user? Does this file change it's modification time when you compile MIBs from the GUI? You can just move this file to some other folder and then check if it's recreated by mib compilation.

Can you give some examples of the issues for which you want to send notifications? How it can be determined that it's the same issue?

NX-2437 only adds option to change MAC address for interfaces that were created manually, so guess this won't work in your case.

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