<![CDATA[NXLS state and runtimeFlags in v3.0]]>Hi

After upgrading from 2.2.17 to 3.0.2292 runtimeFlags and state in NXLS does not show correct values.

Debugging with a Dummy dci on nodes and return $node->runtimeFlags + $node->state gives this results:

Node with active alarm, not responding to ICMP (dead) and only ICMP poll:
$node->runtimeFlags = 4
$node->state = 5

Node with no active alarm, responding to ICMP and only ICMP poll :
$node->runtimeFlags = 4
$node->state = 4

Node with no active alarm, responding to ICMP and nxagent+ICMP poll:
$node->runtimeFlags = 4
$node->state = 0

How can i stable check whetever Node is dead or not within NXLS?
We are using this on dummy/external+proxy DCI's to prevent them raising alarms when node is dead(not responding to ICMP or Agent)

We used this before:

if ($node->runtimeFlags & 0x0004) {
    return true;
}

]]>https://forum.netxms.org/topic/6195/nxls-state-and-runtimeflags-in-v3.0RSS for NodeFri, 13 Nov 2026 20:02:34 GMTSat, 28 Sep 2019 07:32:39 GMT60<![CDATA[Reply to NXLS state and runtimeFlags in v3.0 on Mon, 30 Sep 2019 06:46:39 GMT]]>Thanks for the clarifications, this helped me alot 🙂

]]>https://forum.netxms.org/post/26642https://forum.netxms.org/post/26642Mon, 30 Sep 2019 06:46:39 GMT<![CDATA[Reply to NXLS state and runtimeFlags in v3.0 on Sat, 28 Sep 2019 13:17:02 GMT]]>Hi,

now you should use state attribute to determine node state. For convenience server version 3.0 defines constants for each state:

NodeState::Unreachable
NodeState::NetworkPathProblem
NodeState::AgentUnreachable
NodeState::SNMPUnreachable
NodeState::CacheModeNotSupported

ClusterState::Unreachable
ClusterState::NetworkPathProblem
ClusterState::Down

SensorState::Unreachable
SensorState::NetworkPathProblem
SensorState::Provisioned
SensorState::Registered
SensorState::Active
SensorState::PendingConfigUpdate

So equivalent of 2.2.x

if ($node->runtimeFlags & 0x0004)

will be

if ($node->state & NodeState::Unreachable)

State bit 4 is not used and it's presence is a bit of a mystery. Probably something goes wrong during DB upgrade. You can left it as is - it will not affect anything, or clean it up in database while server is stopped using the following queries:

UPDATED object_properties SET state=0 WHERE state=4;
UPDATED object_properties SET state=1 WHERE state=5;

This will clean it up for most common flag combinations.

If you are using PostgreSQL you should be able to do this in one query using bitwise AND:

UPDATED object_properties SET state=state & ~4;

Best regards,
Victor

]]>https://forum.netxms.org/post/26637https://forum.netxms.org/post/26637Sat, 28 Sep 2019 13:17:02 GMT