NetXMS Support Forum

Это не регрессия сборки 6.2.3. Линковщик берёт libnxdb не из дерева сборки, а из /usr/local/lib — ту, что осталась от установленной 6.2.2. Путь в самой ошибке это и показывает: /usr/local/lib/libnxdb.so.62, а не /home/admin/netxms-6.2.3/src/db/libnxdb/.libs/.

Самое простое — запустить make install вместо make. Установка рекурсивная: каждый каталог сначала собирается и тут же устанавливается, и src/db проходит задолго до src/server/tools. К моменту линковки nddload в /usr/local/lib лежит уже libnxdb от 6.2.3, и подстановка срабатывает правильно. Отдельный make ломается именно потому, что ничего не устанавливает и файл от 6.2.2 остаётся на месте до самого конца.

Что происходит:

В 6.2.3 бэкпортнут фикс https://github.com/netxms/netxms/issues/3483 — case folding для Unicode стал locale-independent и считается по таблицам Unicode, а не через towupper/towlower из libc. Вместе с этим из libnetxms убраны собственные wcsupr/wcslwr, вместо них nx_wcsupr/nx_wcslwr. Сами wcsupr/wcslwr — расширения MSVC, ни в C, ни в POSIX их нет и в glibc не было никогда, поэтому NetXMS всегда собирал свои реализации, а libnxdb на них ссылалась. В 6.2.3 libnetxms их больше не экспортирует.

soname у всей ветки 6.2.x один — .so.62, он считается из major.minor и от patch-версии не зависит. Поэтому файл от 6.2.2 называется ровно так же, как собираемый сейчас, и подменяет его молча. При сборке 6.1.2 и 6.2.2 набор экспортируемых символов совпадал, и подмена ни на что не влияла — поэтому вы её не видели. В 6.2.3 символы исчезли, и старая libnxdb перестала линковаться.

Откуда в поиске берётся /usr/local/lib: configure добавляет -L/usr/local/lib, если такой каталог существует. Он существует, потому что там установлена 6.2.2.

Почему упало именно на nddload, хотя netxmsd собрался: netxmsd передаёт libnxdb явным путём в дереве сборки. У nddload и остальных утилит из src/server/tools libnxdb в списке нет — она приходит только как зависимость libnxsrv, и её приходится искать, а поиск попадает в /usr/local/lib. nddload — первая программа в этом каталоге по порядку сборки. Сами библиотеки собрались нормально потому, что shared library линкуется с неразрешёнными символами, а программа — нет.

Порядок:

systemctl stop netxmsd                 # имя юнита зависит от сборки
cd /home/admin/netxms-6.2.3
make install
ldconfig
nxdbmgr upgrade                        # 6.2.3 это схема 62.38, сейчас база на 62.35
systemctl start netxmsd

Важная деталь: make install перезаписывает установленную 6.2.2 по ходу дела, а не одним шагом в конце. Поэтому сервер лучше остановить заранее, и если сборка упадёт где-то дальше, установка останется наполовину обновлённой. Если хочется сначала довести до конца обычный make, старые библиотеки придётся убрать из /usr/local/lib руками — libnetxms.*, libnx*.*, libethernetip.*, libipfix.*

Проверить, что дело именно в этом, если понадобится:

nm -D -u /usr/local/lib/libnxdb.so.62 | c++filt | grep -E 'wcsupr|wcslwr'
nm -D -u /home/admin/netxms-6.2.3/src/db/libnxdb/.libs/libnxdb.so.62 | c++filt | grep -E 'wcsupr|wcslwr'

У установленной сейчас должно быть __wcsupr(wchar_t*) и wcslwr(wchar_t*), у свежесобранной — nx_wcsupr(wchar_t*) и nx_wcslwr(wchar_t*).

Каталог /usr/local/lib/netxms (dbdrv, ndd, субагенты) трогать не нужно, make install перезапишет его содержимое. Если в нём остались модули от версий старше 6.2.2, которых в 6.2.3 уже нет, они там и останутся, и при загрузке будут падать с такой же ошибкой про неразрешённый символ — уже в рантайме, в лог сервера.

На то, что утилиты из src/server/tools линкуются с установленной библиотекой вместо собранной, завёл тикет: https://github.com/netxms/netxms/issues/3548

1. I've added support for long-living tokens in build 36. Optionally you can enable Face ID, if you want to. You need server 6.2.2. or newer for that to work properly.
2. What do you mean by network view?
3. Yes, since webapi itself is purely http-only, you need any kind of reverse proxy (reproxy, nginx, etc.), which will do SSL offloading.

Добрый день!

Спасибо за помощь, помогло! Выкладываю ниже вывод.

1. Upgrade до 6.2.2

[root@AltTEST data]# psql -U postgres -X -d netxms_db -c "SELECT extname, extversion FROM pg_extension WHERE extname='timescaledb'"
Password for user postgres:
ERROR:  could not access file "timescaledb-2.26.3": No such file or directory


[root@AltTEST data]# ls $(pg_config --pkglibdir)/timescaledb*
/usr/lib64/pgsql/timescaledb-2.27.2.so  /usr/lib64/pgsql/timescaledb.so  /usr/lib64/pgsql/timescaledb-tsl-2.27.2.so


[root@AltTEST data]# systemctl restart postgresql
[root@AltTEST data]# psql -X -d netxms_db -U postgres
Password for user postgres:
psql (18.4)
Type "help" for help.

netxms_db=# ALTER EXTENSION timescaledb UPDATE;
ALTER EXTENSION
netxms_db=# \dx timescaledb
                                                       List of installed extensions
    Name     | Version | Default version | Schema |                                      Description
-------------+---------+-----------------+--------+---------------------------------------------------------------------------------------
 timescaledb | 2.27.2  | 2.27.2          | public | Enables scalable inserts and complex queries for time-series data (Community Edition)
(1 row)

netxms_db=#


[root@AltTEST data]# nxdbmgr upgrade
NetXMS Database Manager Version 6.2.2 Build 6.2-614-gfd28d43d5e

INFO: Server module WEBAPI skipped
Upgrading database...
Upgrading from version 62.1 to 62.2
Upgrading from version 62.2 to 62.3
Upgrading from version 62.3 to 62.4
Upgrading from version 62.4 to 62.5
Upgrading from version 62.5 to 62.6
Upgrading from version 62.6 to 62.7
Upgrading from version 62.7 to 62.8
Upgrading from version 62.8 to 62.9
Upgrading from version 62.9 to 62.10
Upgrading from version 62.10 to 62.11
Upgrading from version 62.11 to 62.12
Upgrading from version 62.12 to 62.13
Upgrading from version 62.13 to 62.14
Upgrading from version 62.14 to 62.15
Upgrading from version 62.15 to 62.16
Upgrading from version 62.16 to 62.17
Upgrading from version 62.17 to 62.18
Upgrading from version 62.18 to 62.19
Upgrading from version 62.19 to 62.20
WARNING:  column type "character varying" used for "service_name" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "scope_name" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "severity_text" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "trace_id" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "span_id" does not follow best practices
HINT:  Use datatype TEXT instead.
Upgrading from version 62.20 to 62.21
Upgrading from version 62.21 to 62.22
Upgrading from version 62.22 to 62.23
Upgrading from version 62.23 to 62.24
Upgrading from version 62.24 to 62.25
Upgrading from version 62.25 to 62.26
Upgrading from version 62.26 to 62.27
Upgrading from version 62.27 to 62.28
Upgrading from version 62.28 to 62.29
Upgrading from version 62.29 to 62.30
Upgrading from version 62.30 to 62.31
Upgrading from version 62.31 to 62.32
Upgrading from version 62.32 to 62.33
Upgrading from version 62.33 to 62.34
Upgrading from version 62.34 to 62.35
Database upgrade succeeded

После чего всё запустилось и работает! Ещё раз спасибо!

2. Обновление до 6.2.3

Собрать не удалось, в какой то момент при сборке появляется ошибка. Вывод консольный ниже:

make[5]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools/scripts'
make[5]: Entering directory '/home/admin/netxms-6.2.3/src/server/tools'
  CXX      nddload/nddload-nddload.o
  CXXLD    nddload/nddload
ld: /usr/local/lib/libnxdb.so.62: undefined reference to `__wcsupr(wchar_t*)'
ld: /usr/local/lib/libnxdb.so.62: undefined reference to `wcslwr(wchar_t*)'
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:691: nddload/nddload] Error 1
make[5]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools'
make[4]: *** [Makefile:1010: all-recursive] Error 1
make[4]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools'
make[3]: *** [Makefile:491: all-recursive] Error 1
make[3]: Leaving directory '/home/admin/netxms-6.2.3/src/server'
make[2]: *** [Makefile:494: all-recursive] Error 1
make[2]: Leaving directory '/home/admin/netxms-6.2.3/src'
make[1]: *** [Makefile:546: all-recursive] Error 1
make[1]: Leaving directory '/home/admin/netxms-6.2.3'
make: *** [Makefile:478: all] Error 2


До этого на том же сервере собирал 6.1.2 и 6.2.2 - не было проблем. 6.2.2 собралось, успешно обновилось и работает.

На первый взгляд работает. Еще проверяю. Вчера обновлял сервер до 6.2.3
Пришло только 1 уведомление в режиме обслуживания:

⌛ 09.Aug.2026 17:01:58
❗ ❗ Service is still unreachable for 1 day
Severity Critical 🟡
***** компьютер архивов
👉 Node unreachable because of network failure

ну это не страшно

Hi Alex,

Thanks for posting the update including MFA this is working well a couple of observations / Questions.

1. Once authenticated could the app save the login and then use Face ID on the phone to unlock?
2. Are there plans to include the Network view?
3. Currently I am only using it internally but I want to expose it externally I was going to use a reverse proxy to handle SSL is this the best way ?

Добрый день,

6.2.2 не требует TimescaleDB 2.26.3 — апгрейд вообще не привязан ни к какой конкретной версии расширения. Единственное требование во всей ветке 62.x — TimescaleDB не ниже 2.10, оно проверяется на более позднем шаге, где создаются continuous aggregates, и 2.27.2 его закрывает. Ошибка приходит не из NetXMS: PostgreSQL пытается загрузить библиотеку расширения timescaledb версии 2.26.3, потому что именно эта версия записана в каталоге базы, а на диске после обновления пакета осталась только 2.27.2. Пакет обновили, а расширение внутри базы — нет.

Почему упало именно здесь: ALTER TABLE object_tools ADD applicable_classes — первый DDL за весь апгрейд. Шаги с 61.36 до 62.1 только пишут строки в metadata и config, а на DDL PostgreSQL обязан загрузить код расширения, потому что timescaledb вешает на DDL свои event triggers. Сам шаг 62.1 → 62.2 к TimescaleDB отношения не имеет, object_tools — обычная таблица, не hypertable.

Сначала стоит убедиться, что картина именно такая:

psql -X -d netxms -c "SELECT extname, extversion FROM pg_extension WHERE extname='timescaledb'"
ls $(pg_config --pkglibdir)/timescaledb*

Если extversion показывает 2.26.3, а на диске лежит только timescaledb-2.27.2.so — причина в этом.

Порядок действий:

systemctl restart postgresql          # имя юнита зависит от сборки пакета
psql -X -d netxms                     # -X обязателен
ALTER EXTENSION timescaledb UPDATE;   # первой же командой в сессии
\dx timescaledb

Два момента, из-за которых это часто не проходит с первого раза: ALTER EXTENSION должен быть первой командой в сессии — после любого другого запроса библиотека старой версии уже пытается загрузиться, и апдейт падает с той же ошибкой (отсюда и -X, чтобы .psqlrc ничего не выполнил до этого). И выполнить его нужно в каждой базе, где установлено расширение, а не только в базе NetXMS.

Если ALTER EXTENSION всё же падает с той же ошибкой — поставить обратно пакет с 2.26.3, выполнить ALTER EXTENSION timescaledb UPDATE при живой старой библиотеке, затем снова обновить пакет до 2.27.2.

После этого повторить nxdbmgr upgrade. По состоянию базы: каждый шаг апгрейда выполняется в отдельной транзакции, DDL в PostgreSQL транзакционный, поэтому откат снял шаг 62.2 целиком — недоприменённых изменений не осталось, база консистентна и стоит на схеме 62.1. Повторный запуск безопасен, но dump перед ним сделать стоит.

Важное следствие: схема уже 62.1, а сервер требует точного совпадения версии схемы, поэтому сейчас не стартует ни 6.2.2 (ждёт 62.35), ни 6.1.2 (ждёт 61.36) — в логе будет "Your database has format version ...". Путь только вперёд, откат назад — это восстановление из бэкапа.

На то, что nxdbmgr показывает это состояние ошибкой, по которой причину не видно, завёл тикет: https://github.com/netxms/netxms/issues/3540. И отдельно на документацию, https://github.com/netxms/netxms-doc/issues/65 — в разделе про апгрейд про обновление расширения не сказано ничего.

И раз апгрейд всё равно не завершён: сегодня вышла 6.2.3, https://www.netxms.org/forum/announcements/netxms-6-2-patch-release-3/ — имеет смысл ставить сразу её. На эту ошибку она не влияет, шаг 62.1 → 62.2 в ней тот же самый, добавлены только шаги после него (схема 62.38 вместо 62.35).

Если extversion в базе окажется уже 2.27.2 — тогда картина другая, покажите вывод запроса и полный вывод nxdbmgr upgrade.

We just published patch release 3 for version 6.2. Changes since previous patch release:

-   Single-use authentication tokens
-   Self-service dialog for managing own authentication tokens
-   Authentication token value is returned only in response to token creation request and is no longer exposed in token listings
-   Microsoft Teams notification driver reworked to send notifications to Workflows (Power Automate) webhook URLs
-   OTLP receiver accepts JSON-encoded OTLP/HTTP payloads
-   Wake-on-LAN packets can be sent to managed nodes via web API and NXSL
-   Option to disable credentials check for incoming SNMP traps
-   Added NXSL methods for setting SNMP trap credentials
-   Number of agent connection retries is now configurable
-   Chart Y axis range and gauge value fields accept K, M, G, and T multiplier suffixes
-   Incidents view can hide closed incidents
-   "Go to object" action added to package deployment jobs, agent tunnels, scheduled tasks, and user support application notification views
-   D-Link driver uses ifDescr as primary source for assigning interface physical location
-   Fixed stack buffer overflows in LLDP topology processing and SNMP OID conversion that could crash the server
-   Fixed access control bypass when reading closed incidents
-   Fixed data collection configuration not being updated on agents working in cache mode
-   Fixed template exclusion groups not being enforced on configuration poll auto-apply and in NXSL applyTemplate
-   Fixed business service status calculation ignoring service's own checks
-   Fixed failed package installation being reported as completed
-   Fixed WMI subagent failing all queries after the first one in agent lifetime
-   Fixed agent hang on shutdown when agent extension is configured
-   Fixed critical events being dropped by wineventsync severity filter
-   Fixed spikes in Windows System.IO.* total metrics when physical disk drops out of collection
-   Fixed user inactivity timeout logging out actively working users in web console
-   Fixed excessive column repacking that slowed down grid views in Windows desktop client
-   NXSL Unicode case folding is now locale-independent

Full list of fixed issues:

-   #1301 / NX-1091 (D-Link stack driver and ports)
-   #3224 (Update Microsoft Teams Notification Driver to Support Workflows/Power Automate)
-   #3252 (Y axis range in chart properties should support K, M, G, T suffixes)
-   #3347 (Agent's data collection elements for cache mode not getting updated)
-   #3389 (Newly created event template is not saved in log parser policy)
-   #3415 (ClassCastException when opening bar/pie chart from DCI editor)
-   #3418 (Grid views repack columns on every refresh, causing constant repaint and slowdown on Windows desktop client)
-   #3428 (Line chart ignores configured time period on first open, shows last hour until refresh)
-   #3432 (Unvalidated netmask from node creation request passed to pseudo-interface (np.cpp:293))
-   #3467 (Allow setting SNMP trap credentials in bulk (NXSL binding))
-   #3472 (Narrow string literals passed to StringBuffer::append() silently become "true" (breaks notification digest and alarm AI prompts))
-   #3474 (Failed package installation can be reported as completed (uninitialized variable in PackageDeploymentJob::execute))
-   #3475 (Node::getMetricFromSmclp() validates wrong variable, returns garbage when value is on last line)
-   #3476 (memset on non-trivially copyable WaitQueueWaiter in MsgWaitQueue)
-   #3482 (OTLP receiver rejects JSON-encoded OTLP/HTTP payloads)
-   #3483 (NXSL Unicode case folding silently degrades to ASCII when process environment has no locale)
-   #3485 (Server crash (SIGSEGV): stack buffer overflow in LLDP topology processing (BinToStr into fixed buffers))
-   #3489 (Option to disable incoming SNMP trap credentials check)
-   #3490 (Agent hangs on shutdown if agent extension is configured)
-   #3492 (Access check bypassed when reading closed incidents via NXCP)
-   #3493 (Single-use authentication tokens)
-   #3495 (Stack buffer overflow in SnmpConvertOIDToText: bufferSize is never enforced, crashes server during instance discovery)
-   #3496 (Self-service UI for managing own authentication tokens)
-   #3497 (Authentication token values exposed in token listings until server restart)
-   #3499 (WebAPI rejects all internal object tools, but none of them need a client)
-   #3500 (Table views lose declared sort direction on first open (restoreTableViewerSettings defaults to SWT.UP))
-   #3501 (WMI subagent: all WMI.Query metrics fail after first query in agent lifetime (CoInitializeSecurity called per query))
-   #3502 (Configurable number of agent connection retries)
-   #3503 (WinNT subagent: System.IO.* total metrics spike when a physical disk drops out of the per-second aggregate)
-   #3504 (AI provider Temperature/TopP parsed as integers, fractional values truncate to 0)
-   #3505 (wineventsync: Critical events dropped by default severity mask (0xFF vs 0x100))
-   #3506 (Stale help texts: nxmibc default output file, nxtool encryption policy default, nxdbmgr reset-system-account)
-   #3507 (ping subagent: Don't Fragment option comparison inverted in target parsing)
-   #3508 (SIGSEGV in NXSL_NetworkPathClass::getAttr during class attribute enumeration)
-   #3509 (Password complexity subsequence check misses last alphabet window (XYZ/xyz not rejected))
-   #3510 (Typo in MIB walk DCI creation action: "Create data collection tiem...")
-   #3511 (DB metadata drift: 2FA config vars missing from setup.in, IntruderLockoutTime units, stale SYS_TABLE_THRESHOLD_DEACTIVATED description)
-   #3512 (oracle subagent: Oracle.ASM.DiskGroups list always empty (tag pattern references nonexistent STATUS column))
-   #3513 (java subagent: JVMOptions config parameter is parsed but never passed to the JVM)
-   #3514 (vmgr subagent: wrong values from several metrics (CPU.Time returns vCPU count, Memory.UsedPrec always 0/100, MaxCount semantics, "Unkonown" literals))
-   #3515 (libnxlp: <logName> in agent-side Windows event log parser rule dereferences null)
-   #3516 (ping subagent: Icmp.MinPingTime and Icmp.Cumulative{Min,Max}PingTime all return last-minute maximum RTT)
-   #3517 (SYS_TEMPLATE_AUTOREMOVE event parameters are swapped (template posted as node, node as template))
-   #3518 (Template exclusion groups not enforced on configuration-poll auto-apply path (or NXSL applyTemplate))
-   #3519 (Console scan command: zone and proxy keywords assign each other's values)
-   #3520 (webapi openapi.yaml: historicalDataType value mapping description is inverted)
-   #3521 (Add option to hide closed incidents in Incidents view)
-   #3523 (Business service parent state recomputed from children only, ignoring its own checks)
-   #3524 (Agent metric registration oddities: System.CPU.Usage5.Idle5(*), Solaris MemoryDevice.MaxSpeed type)
-   #3526 (Web console: inactivity timeout logs out actively working users)
-   #3527 (Add "Go to object" context menu action to Package Deployment Jobs and other configuration views)
-   #3528 (nxdbmgr check cannot create missing object_properties rows - INSERT references dropped is_system column)
-   #3535 (Interface Traffic Agent 32-bit template: system tag says bytes, stored value is bits — utilization 8x too high)

Добрый день

Обновлялся с версии 6.1.2 до версии 6.2.2
Апгрейд базы до конца завершиться не может, возникает ошибка:


Upgrading from version 62.1 to 62.2
SQL query failed (58P01 ERROR:  could not access file "timescaledb-2.26.3": No such file or directory):
ALTER TABLE object_tools ADD applicable_classes integer
Rolling back last stage due to upgrade errors...
Database upgrade failed

Версия postgress при этом:
postgresql18-timescaledb-2.27.2-alt1.x86_64

т.е. версия timescale выше требуемой и проблем бы быть не должно. Или при апгрейде до 6.2.2 требуется именно 2.26.3?

Подскажите где ошибка или как обойти это ограничение?
ОС - Altlinux Server, 11.1
Спасибо!

Perfect, thank you for the explanation.

Нет, скрипт на правиле 31 ничего не изменит — правило 31 в этот раз вообще не срабатывало. Уведомления пришли от правила 32.

В логе уведомлений сервера это видно напрямую: строки 459–463 за 19:01:33–19:01:39, событие SYS_NODE_UP, Rule ID e8f2ab80-3472-4631-a7a6-e501149eb086, описание правила "Terminate mail alarms when node connected by tunnel / proxy node is up in 300 sec" — это правило 32. Пять уведомлений, все "Node up", ни одного "down".

Режим обслуживания ничего не подавляет на этапе генерации событий. События создаются, пишутся в event log и попадают в EPP как обычно; единственное, что делает maintenance — проставляет каждому событию объекта Root ID, равный ID события входа в обслуживание. Дальше решает флаг "Accept correlated events" на правилах.

В вашем логе событий: SYS_MAINTENANCE_MODE_ENTERED в 18:38:27 с Root ID = 0, а всё последующее — SYS_TUNNEL_CLOSED 18:58:20, SYS_AGENT_UNREACHABLE и SYS_NODE_UNREACHABLE 19:00:23, SYS_TUNNEL_OPEN 19:00:45, SYS_NODE_UP и SYS_AGENT_OK 19:01:33 — с Root ID = 11094369. Все коррелированные.

Отсюда цепочка:

• SYS_NODE_UNREACHABLE коррелированное, у правила 31 флаг выключен — правило его пропустило. Ни аларм, ни таймер NODE_BY_TUNNEL_DOWN_%n_%i не создались.
• SYS_NODE_UP тоже коррелированное, но у правила 32 флаг включён — правило сработало.
• У действия Normal MailAlarm в правиле 32 стоит блокировка "Do not run if timer NODE_BY_TUNNEL_DOWN_%n_%i is active". Таймера нет, потому что его никто не создавал — блокировка не сработала, письмо ушло.

Что сделать: выключить "Accept correlated events" на правилах 32 и 34. Скрипт с проверкой maintenance добавлять никуда не нужно — он дал бы тот же результат, но флаг проще.

Здесь нужно поправить то, что я писал 21.07. Флаг на up-правилах рекомендовался ради сценария "нода упала (таймеры заведены) → её перевели в обслуживание → она поднялась в обслуживании → аларм не закрылся, и через 8 часов пришло письмо". Этот сценарий сервер закрывает сам: при выходе из обслуживания состояние ноды восстанавливается на то, каким оно было до входа, и если оно разошлось с фактическим — принудительно запускается status poll. В этом сценарии состояния разойдутся, поллинг отработает и сгенерируется новое, уже некоррелированное SYS_NODE_UP: правило 32 на нём сработает, аларм закроется, таймеры снимутся. Флаг для этого не нужен, а его единственный реальный эффект — ровно то, что вы получили 06.08.

Два соседних случая, чтобы было понятно, чего ждать после выключения флага:

• Нода и упала, и поднялась внутри окна обслуживания (ваш случай 06.08). Состояние на выходе совпадает с исходным, поллинг не форсируется, после выхода из обслуживания ничего не приходит. Аларма и таймеров при этом не создавалось — закрывать нечего.
• Нода упала в обслуживании и осталась лежать. Состояния разойдутся, форсированный поллинг отработает, и SYS_NODE_UNREACHABLE придёт уже некоррелированным — реальную аварию за окном обслуживания вы не потеряете.

Вне обслуживания SYS_NODE_UP не коррелируется никогда, поэтому на обычную работу правил 32/34 выключенный флаг не влияет.

Правила 31 и 33 трогать не нужно. У 31 флаг выключен, у 33 включён вместе со скриптом проверки maintenance — оба во время обслуживания молчат.

Note: одна дырка остаётся. Отложенные действия, заведённые до входа в обслуживание, во время обслуживания не отменяются и не проверяют maintenance при срабатывании — их снимет только SYS_NODE_UP после выхода. У вас Critical MailAlarm стоит с задержкой 5 минут, поэтому сценарий "нода упала, её в течение 5 минут перевели в обслуживание, и там же она поднялась" всё равно даст письмо о недоступности. Задержки 8h/1d/3d сработают только если окно обслуживания окажется длиннее них.

Отдельно: в моём ответе от 28.07 было сказано, что асимметрия между правилами 31 и 32 проявится только если в группу добавить ноду за маршрутизатором или коммутатором, и что для нод без primary IP этого не случится. Это неверно — режим обслуживания коррелирует все события объекта независимо от primary IP и от топологии, поэтому асимметрия проявляется в любое окно обслуживания. Ровно это 06.08 и произошло.

То, что maintenance подавляет события через корреляцию, а не отдельным механизмом, в трекере уже разбиралось: https://github.com/netxms/netxms/issues/2571 — закрыто как expected behavior, с тем же обходным путём через скрипт. В документации раздел про maintenance mode при этом сформулирован неверно: там сказано, что события не генерируются, тогда как они генерируются и коррелируются. Завёл тикет: https://github.com/netxms/netxms-doc/issues/63