NetXMS Support Forum

Just RPi

Yes, this seems to be a lock without the actual upgrade. Pls run nxdbmgr background-upgrade and force unlock.

Quote from: twparker on February 10, 2026, 04:52:14 PMI can see that the database upgrade is happening in the background, but the netxms-server service won't start.
"Your database has format version 60.7, but server is compiled for version 60.32"

Are you still in upgrade to 6.0.0, or you've restarted upgrade to 6.0.1?

...happening in the background - is it nxdbmgr background-upgrade running? If so, you need for it to finish and then run nxdbmgr upgrade again - it will upgrade schema further. This step could be a background one in 5.2, but when upgrading to 6.0 we need it to complete prior to subsequent db upgrade steps.

yes, that's background migration, server reads collected data both from non-migrated and migrated tables, so everything should work even during migration.
Would be interesting to know how long it takes on your system and how big it is (sh st output - number of nodes, dci count, size of the DB)

Command line should contain nxdbmgr

Yes, that's the idea of background upgrade that it runs while server is running. This way we minimize server downtime.

Yes, RPi is a bit low priority, needs fixing. Pls try if agent from this binary archive will run: https://netxms.org/download/releases/6.0/nxagent-6.0.1-linux-arm.tar.gz

Quote from: dreamscape on February 10, 2026, 10:55:09 AMC:\NetXMS\bin>nxdbmgr check
NetXMS Database Manager Version 6.0.1 Build 6.0-469-g5e68d5db1d

Error loading configuration file

Make sure you run this in cmd session started with administrator rights - looks like there's access right issue to the server config file.

Message Your database has format version 52.23, but server is compiled for version 60.32 means that nxdbmgr upgraded did not happen (first part of format version is basically netxms version, so 52.23 means that database format is for 5.2.x).

nxdbmgr check will tell that db version is old, so try running nxdbmgr upgrade

Yes, that's some background upgrade that was needed when upgrading to 5.2.8. When packages are upgraded by apt, background upgrade is initiated automatically. Could be that you stopped the server soon after upgrading to 5.2.8 and background upgrade did not complete. It's locking mechanism was introduced recently, so there might be some issues with it.

Recommended way is to check with ps fax or similar to see that there's no other nxdbmgr background-upgrade running on your system.

Since you've started nxdbmgr background-upgrade, once it completes system should be able to upgrade to 6.0 (note that there's 6.0.1 with some bugfixes, should be available already)

NetXMS 6.0 uses newer version of GUI framework which requires newer version of servlet API. Please try tomcat10

Да, по ссылке актуальная документация.
Можно на любой ноде сделать Execute script, там packageName задать вручную, а не из ивента и посмотреть что будет, у меня вот это выдает false:

sub main() {
  packageName = "2026-01 Обновление для системы безопасности";
  if (packageName == null) return false;
  packageName = packageName.toLowerCase();
  if ((packageName.contains("для системы безопасности")) ||
      (packageName.contains("adobe reader")) ||
      (packageName.contains("средства проверки правописания microsoft")))
  {
    return false;
  }
  return true;
}
И, кстати, в Configuration есть такая штука как Mapping tables, там можно вести табличку с названиями ненужного софта, в колонке Key, Value можно не заполнять, из NXSL это будет доступно в виде массива через функцию GetMappingTableKeys()

На первом этапе дискавери сервер высылает пачку ICMP запросов на много адресов сразу (NetworkDiscovery.ActiveDiscovery.BlockSize - по умолчанию 1024), ждет ответов и рассылает следующую пачку. Так что список ответивших адресов он собирает достаточно быстро.
Дальше там два этапа - первоначальный сбор данных о каждом адресе - это делают паралельные треды (в количестве ThreadPool.Discovery.MaxSize) и потом есть один тред, который анализирует эти данные и решает что делать (один, потому что у одного девайса может быть несколько адресов, а мы не хотим насоздавать несколько нод).
В Debug Console по команде show queues показывается Node discovery poller, но это сумма очередей каждого из этих этапов. В 6.0 размер этих очередей скорее всего будет виден по-отдельности, когда-нибудь в будущем этот тикет может будет сделан: https://track.radensolutions.com/issue/NX-2616

Highlighters need to be implemented in code to be present in this list. Currently not a single one is present.
What's you file format that you'd want to highlight, how complicated it is?

Since the node works with snmp v2 I'd suggest to use that now to avoid encryption stuff.

For comparison we still need two captures - one from nxsnmpget, the other - when NetXMS is doing  configuration poll of that node.

А скрипт которые параметр subnets прикрепляет к событию - он откуда запускается?

Ну и там нет такого, что в filter script в этих правилах EPP могут попадать события, у которых нет этого параметра?

Eсли параметра нет, то при обращении к $event.subnets скрипт завалится с ошибкой Unknown object's attribute. Безопаснее использовать метод:

$event.getParameter("subnets")
если параметра нет, он вернет null, но скрипт не завалится.

subnet_dc = $event.getParameter("subnets");
trace(0, "From EPP rule " .. typeof(subnet_dc) .. " " .. subnet_dc); // можно логить в серверный лог чтоб разобраться что происходит
if (subnet_dc == null) return false;

subnet_dc = subnet_dc.toLowerCase();
 
if (subnet_dc.contains("dc") || subnet_dc.contains("ts"))
{ 
    return true;
}
return false;
sub main() для EPP скриптов можно не писать, это актуально когда определяется функция, которую вызывают другие скрипты. И вместо sub теперь используется function.

В дебаг информации не видно, чтоб дискавери прямо завис, он там что-то продолжает делать, во всех тредах он на разном месте в коде.

Есть шанс что настройки DBWriter чересчур накручены и ему мешают. DBWriter.DataQueues в случае таймскейла нет смысла поднимать больше 1, т.к. по сути там все данные DCI пишутся в одну таблицу - idata_sc_default. DBWriter.BackgroundWorkers тоже следует поднимать осторожно, т.к. когда их много, то они начинают мешать друг другу, по нашему опыту больше 4 их не нужно.