NetXMS Support Forum

It's ok with /etc/netxmsd.conf - it's just printing what config file it's using. The error is "FATAL ERROR: Cannot open log file".

I can think of two reasons for that:
- you are starting it as regular user, but the log file was previously opened by netxms running under root (because systemd lauches it this way). So under regular user you don't have rights to write to same log file. Try running under root user.
- check log file configuration in /etc/netxmsd.conf. Does it point to non-existing folder?

try starting netxmsd process from command prompt in foregroud mode:

netxmsd -D 6

This will start it with 6-th level or debug and will put all messages that are written to log file to the console. After it terminates, share the output.

You can check the list of published packages in package repository, e.g. for Ubuntu Focal Fossa: https://packages.netxms.org/ubuntu/pool/focal/main/n/netxms/
Currently it's 3.6.300

Make sure you run
apt update
prior to
apt upgrade

On startup netxms management console downloads netxms.mib file from server (or if it's already downloaded, checks, if it needs downloading again).
As a workaround you can set "Connection over slow network" checkbox on console's login screen - it will omit mib file downloading. Or you can try to copy /var/lib/netxms/netxms.mib
file from server and putting it in ~/.nxmc/data folder, but I am not sure it that will work.

How fast is your network connection from your desktop to NetXMS server? What are OSes on the server and your desktop? Is your netxms console the most recent version?

Hi!

If you installed on Ubuntu from package, you just need to do the standard upgrade with apt or apt-get, no special procedures required.

NetXMS keeps separate tables for each nodes to keep DCI history. idata is for single value DCIs and tdata for table DCIs.
This could happen, if some nodes were deleted prior to netxms shutdown or crash, the correspnding tables won't be deleted from the database. Then, when new node is created, it used same IDs and tries to create tables that already exist.
22092 and 22093 should be IDs or recently created nodes (you can search in object tree by #22092).
So this error message is not really a problem and should not cause any issues.

It could be related to connectivity problems that were introduced in 3.6. Today 3.6.300 that hopefully fixes that issue, please try upgrading to that.

Service check is performing the checks via NetXMS agent that is installed on NetXMS server. The agent should have portcheck subagent enabled.

But overall service check functionality is old and is not being developed. It's recommended to use netsvc subagent, which is based on curl. It provides Service.Check(URL[, regex]) agent parameter. Here's some information: https://www.netxms.org/documentation/adminguide/service-monitoring.html#netsvc-configuration

Ah, the same problem with desktop client also. So it's a different problem, then initially in this topic.

Is netxmsd process actually running at the moment, when you are trying to connect?
On what OS netxms server is running?

If it's linux, try to capture threads at the moment, when you are unable to connect. To do this, run this script: https://raw.githubusercontent.com/netxms/netxms/master/tools/capture_netxmsd_threads.sh
This script requires gdb to be installed on the system. Run the script 3 times with 10-20 seconds interval. It will produce files in /tmp. Please share these files.

Clearing cookies in your browser should help. Or you can incognito mode or another browser.

К примеру, мысобираем агентскую таблицу по параметру Agent.SubAgents. Сам этот табличный DCI назван "Loaded subagents". И там какие-то такие данные:
| NAME                | VERSION             | FILE                |
+---------------------+---------------------+---------------------+
| Linux               | 4.0.484             | linux.nsm           |
| PORTCHECK           | 4.0.484             | portcheck.nsm       |
| DBQUERY             | 4.0.484             | dbquery.nsm         |
| FILEMGR             | 4.0.484             | filemgr.nsm         |
| PING                | 4.0.484             | ping.nsm            |
| SSH                 | 4.0.484             | ssh.nsm             |
| VMGR                | 4.0.484             | vmgr.nsm            |

И мы хотим иметь DCI, в котором будет версия субагента PING. Делаем в script library скрипт:
table=GetDCIValueByDescription($node, "Loaded subagents");
if (table!=NULL)
{
  col=1;
  for (i=0; i < table->rowCount; i++)
  {
    if (table->get(i, 0) == "PING")
    {
      return table->get(i, 1);
    }
  }
}
return null;

Делаем на ноде новый DCI, выбираем тип Script, в поле parameter пишем имя под которым мы сохранили скрипт. Этот скрипт будет доставать из нашего табличного DCI значение из 1-й колонки (колонки считаются от 0) из той строки, где в 0-й колонке написано "PING".
Но сейчас у нас прямо в скрипте прописано, что именно брать, а хотелось бы, чтоб скрипт был универсальным, а мы бы ему сообщали параметрами. что именно нам нужно.

//  $1 - Table name
//  $2 - Column name from where to return the value
//  $3 - Column name where to search
//  $4 - Value to search

table=GetDCIValueByDescription($node, $1);

if (table!=NULL)
{
  col_return = table->getColumnIndex($2);
  col_search = table->getColumnIndex($3);
  if (col_search >=0 and col_return >= 0)
  {
    for (i=0; i < table->rowCount; i++)
    {
      if (table->get(i, col_search) == $4)
      {
        return table->get(i, col_return);
      }
    }
  }
}
return null;
Параметр нашего скриптового DCI теперь должне быть таким: GetTableCell(Loaded subagents, VERSION, NAME, PING).

.metadata is hidden folder, so it wont be shown by ls command. One of the options is to run:
cat ~/.nxmc/data/.metadata/.log

As for the server log file, it's necessary to increase debug level for  client.* and userdb debug tags. You can do this with the help of nxadm command:
nxadm -c "debug client.* 6"
nxadm -c "debug userdb 6"
and you can check current debug levels with
nxadm -c "debug"

after setting debug levels, wait until you get console disconnect and share complete server log file.

On what operating system do you run the management console?

Upgrade both, just to be on the safe side.

Try clearing cookies in your browser