NetXMS Support Forum

nxagentd.service is the file name for systemd scripts, not the name of actual process. The process name is visible in command like top, ps, for netxms agent it's nxagentd.

In your log the error usually happens 1s after the connection is created, but there is one place, where it happens just few ms afterwards:
2020.04.09 13:34:04.722 *D* [                   ] SSH: created new session [email protected]:22/1
2020.04.09 13:34:05.828 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:12.345 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:13.366 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:19.436 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:19.456 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:30.496 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:31.517 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)


Do you see anything that would correspond to these events in  /var/log/auth.log  on the Raspberry?
Can you take a tcpdump to see, if the connection is established at all when this happens?

Изображения загружаются через Configuration -> Image library. Там в контекстном меню есть пункт загрузки изображений, там же будут видны поддерживаемые форматы. Сейчас на карте используется размер 48х48, изображения большего размера могут отрисовываться некорректно.

Hi,

there has not been any changes since 2.2.2 that could make such dramatic change in launch time.
I would suggest to try running nxshell on a different system, preferrably clean installed to see if it makes any difference.

I believe it should be possible to make jython program that starts, connects to the api and has some sort of interprocess communication to know what commands to run.

There's a new release available not that fixes one memory leak. Please try it.

AgentTunnels.UnboundTunnelTimeoutAction defines what happens when unbound tunnel connects to the server. When it connects, server puts it into a list and does nothing. This allows to perform a manual action. Then, after a timeout (it's configurable, I think it's 1 hour by default) server performs an action
- bind to existing node - if there is an appropriate node, tunnel will be bond to it. If not, the tunnel will stay unbound.
- bind to existing or create - if no appropriate node, it will be created
- there's also option to drop tunnel - in that case agent will reconnect and after mentioned timeout process will repeat.

It depends on what you want to achieve.

If you are not interested in these interfaces at all, you can prevent them from creating - modify script "Hook::CreateInterface" in scripting library. Script is executed on configuration poll for each new interface (accessible as $1, https://www.netxms.org/documentation/nxsl-latest/#class-interface) and should return true or false. If return value is false - interface will not be created.

It's possible to use $1->ifType (interface type as defined by IANA, list of interface types available here: https://github.com/netxms/netxms/blob/master/include/nms_common.h#L908, or can be seen on the object overview tab when interface is selected).
Or you can query node via SNMP to get some data.

If you want to keep interfaces in the system, but ignore status change - simplest way is to set "Expected Interface State" to IGNORE. You can do it in configuration poll hook (Hook::ConfigurationPoll).
Sample:

for (i : $node->interfaces) {
    if (i->ifType == 131) { // tunnel
        i->setExpectedState("IGNORE");
    }
}

If you want to block events in the EPP, add rule before any alarms or notifications:
Script:
    i = $node->getInterface($5);
    if (i->ifType == 131) { // or any other filter
        return true;
    }
    return false;
Action:
    stop processing

Alternatively, add script to your alarm / notification rules and return true only if it's not dynamic interface:
    i = $node->getInterface($5);
    if (i->ifType == 131) { // or any other filter
        return true;
    }
    return false;

There could be better options, but one I can think of would be to create 2 DCIs:
- one with "Push" origin - that would be the actual DCI.
- another on that receives data via SNMP polls. You can put Retention time = 0, in that case it will not store anything to DB. In transformations script you can PushDCIData into the first DCI.

Even 5GB is way too high for installation of that size. Can you please run this script and share the results:
https://github.com/netxms/netxms/blob/master/src/server/tools/scripts/nx-collect-server-diag.cmd

There are a few things, like process list or ip addresses, that you might not want to publish, you can either send me the output in PM, or modify the .cmd file so they are not collected.

Please check "NetXMS server: physical memory used by process" DCI on NetXMS server node. How it's graph looks for a couple of days - is it stable or growing?

Memory usage depends on number of objects, number of data collection threads, etc.
Please show the output of "sh st" command executed in server console.

Hi!

One day in a future version behaviour regarding certificate expiry might change. As of 3.2 it still the same.

Normally discovered DCIs should not get lost - after rebinding server continues to perform discovery and if it gets all instances, all stays as it was. The problem could be with particular discovery method that is used.

Does it affect only some of the DCIs, not all of them? What method of instance discovery is used for these?

In server configuration there is setting InstanceRetentionTime. It defines, how long instances are retained, if they stop to get discovered. Setting this to some value will keep discovered DCIs for some time, allowing to fix problems with their discovery.

Can you give more details on what are you trying to achieve?
Do you have a node which has SNMP data for these OIDs?
Do you have any DCIs on that node?
What result of the filtering do you expect?

I believe PushDCIData will update only DCIs that have origin "Push".

A "locked" way of map viewing was discussed, but it not yet implemented. Current situation is that all elements are movable, but when user closes the map, no question about saving changes is asked. When opening the map again all items will be on positions when the map was last saved.

Portcheck subagent does not support authentication. There's another subagent - netsvc - that is based on libcurl and supports authentication by specifying address like: proto://user:pass@host
The difference is that it's not possible to use netsvc as data source for "Network service". The only way to access netsvc is to create a DCI.