NetXMS Support Forum

Some additional clarifications:

All configs delivered by policies are merged on agent startup. That means that each policy can bring it's own piece of total configuration, and those can be from same sections. For example, you have PING subagent loaded, and if two policies will have Target parameter in *PING section, agent will have two ping targets.
It is not mandatory to use XML format for configs delivered via policies, key=value format can be used as well.
It is possible to use comments in XML (with standard XML syntax <-- comment here -->).
"Description" tab is a left-over from old versions where there was no common comment field for objects. It should be removed.

Best regards,
Victor

It makes sense. Theoretically it is possible that main process terminates before watchdog process completely stopped, and so files are still locked when installer start copying new files. I've changed agent so main process waits until watchdog process terminates and only then exits.

Was watchdog enabled in all cases of failed upgrades?

Best regards,
Victor

There are error in configuration, but it should not prevent alarm generation.

Can it be that you define threshold for DCI and only after define rule in event processing policy? In that case threshold violation event might be created before you define handling rule. You can check this by setting repeat interval in threshold - then it will repeat threshold violation event.

As for error I mention - you probably want to resolve existing alarm by "normal" event? If yes, then it will not work that way Problem is with alarm keys - resolve find alarm to resolve by key, but you specify different key in resolve rule than in alarm creation rule. This could be reduced to two rules:

1. Generate alarm from events CPU_LOAD_WARNING or CPU_LOAD_CRITICAL, with severity "from event" and key "CPU_LOAD_%i_%5".

2. Resolve alarm from event CPU_LOAD_NORMAL by key "CPU_LOAD_%i_%3".

Notice difference in key - %5 vs %3 - for historical reasons DCI ID is parameter number 3 for threshold rearm events and number 5 for threshold violation event.

Best regards,
Victor

According to trace, installer was unable to rewrite some files because of sharing violation - system didn't allow rewriting them as they was already open (presumably by some process). Looks like nxagentd.exe didn't exit before upgrade. I'll try to simulate this in my network.

Best regards,
Victor

Hi!

"Command generates output" option is not handler correctly yet for agent actions. Will fix this for next release.

Best regards,
Victor

Hi!

Likely some sobtle error in configuration. By description everything looks correct. Can you share screenshot of exact configuration - maybe I'll spot the problem.

Best regards,
Victor

You have to select .1.3.6.1.4.1.9.9.13.1.3.1.2 (or any other working OID inside .1.3.6.1.4.1.9.9.13.1.3.1) as table's base OID, and use .1.3.6.1.4.1.9.9.13.1.3.1.2, .1.3.6.1.4.1.9.9.13.1.3.1.3, etc. for column OIDs. I've created short document with working SNMP table example: http://wiki.netxms.org/wiki/Creating_SNMP_table_DCI.

Best regards,
Victor

Hi,

I probably found the bug. Try to patch src/server/tools/nxdbmgr/upgrade.cpp as following:

Find line 492 - it should be

         TCHAR *config = DBGetField(hResult, i, 3, NULL, 0);

insert after it the following code:

         if (config == NULL)
            config = _tcsdup(_T(""));

Rebuild nxdbmgr - it should work.

Best regards,
Victor

Hi!

You can execute object tool via Java API or using nxshell (which is a Python wrapper around Java API). Approximate sequence will be following:

1. find cluster object (by name or ID)
2. for each child node object call NXCSession.executeAction

Here you can find more information about API:

http://wiki.netxms.org/wiki/Using_nxshell_to_automate_bulk_operations
https://www.netxms.org/documentation/javadoc/latest/

Best regards,
Victor

Actually, this bug is already fixed (I think it was in 1.2.14 or 1.2.15) - service installer no longer adds -D option to service command line unless it was explicitly specified. But if service was created by previous version -D 0option remains because agent installer do not change service definition. Existing services can be re-created by running script like this:


nxagentd -S
nxagentd -R
nxagentd -c C:\NetXMS\etc\nxagentd.conf -I
nxagentd -s


(stop agent, remove service, install service, start agent).

Best regards,
Victor

Hi!

Agent configs on server requires that agent can connect to server - this could be problematic in some environments. On the other hand, agent will receive full config and can be started without config at all.

Agent policies cannot be used to bootstrap agent - you still need local master config with at least master server address set. But they can be used over existing agent connection, via proxy, etc.

We plan to keep both options for foreseeable future. If new agent deployment is not happen very often, I probably would recommend agent policies. They are somewhat easier to manage, and we plan to improve them.

Best regards,
Victor

Hi!

Do you have something in server log regarding LDAP? Also, try to set connection string as ldap://10.192.30.23

Best regards,
Victor

Quite strange. Seems that crash occurs in process initialization, even before our code is called. That usually means that something is wrong with the libraries.

Best regards,
Victor

Hi,

can you please run it under gdb and post backtrace after crash?

Best regards,
Victor

Hi!

No, it is not possible. This is intentional limitation - NXSL scripts executed within a sandbox and cannot communicate with external world directly. However, you can define external parameter on an agent, and use AgentReadParameter function to get it's value.

Best regards,
Victor