NetXMS Support Forum

Hi!

Try to change DCI data type to string - will it show correct history then?

Best regards,
Victor

Hi!

Yes, it's possible. You can create "situation" object and in event processing policy set situation's attribute. Then you can create DCI with source "Internal" and parameter "Dummy" and in transformation script read value from situation's attribute. Sample script to access situation can be found here: https://www.netxms.org/documentation/adminguide/event-processing.html#situations.

Best regards,
Victor

Hi!

Is trap sender added as a node object in NetXMS?

Best regards,
Victor

Quote from: AnRkey on May 23, 2014, 11:19:46 AM
I used the netxms repo for the installation. Is the repo still being maintained?

The line in my /etc/apt/sources.list is as follows,

# netxms repo
deb https://www.netxms.org/apt squeeze main

Yes, this repo is maintained, but it' for Debian 6. For Debian 7 please use

deb https://www.netxms.org/apt wheezy main

Best regards,
Victor

Hi!

This is strange. This is how control file for netxms-base for Debian 7 looks like:


Package: netxms-base
Version: @version@
Section: net
Priority: optional
Architecture: @arch@
Essential: no
Depends: libssl1.0.0, libexpat1, zlib1g
Maintainer: Victor Kirhenshtein <[email protected]>
Description: NetXMS base libraries


Are you sure you took right deb files?

Best regards,
Victor

Hi!

try to run netxmsd in foreground:

netxmsd -D9

and check output.

Best regards,
Victor

Quote from: Dani@M3T on May 20, 2014, 11:43:07 AM
1. Configuration:
The VPN connectors are still not configurable in Java console (1.2.14), whether changes nor creation.

Yes, I forgot to add create VPN action in Java UI. Will fix it in next release.

Quote from: Dani@M3T on May 20, 2014, 11:43:07 AM
2. Event Correlation:
When a VPN tunnel goes down, we recieve from NetXMS one 'Node down' for the remote VPN gateway (=ok). But when the VPN tunnel goes up again, we allways get 'Node up' for every node on this remote site (=not ok). It seems the event correlation on 'down' is ok but not on 'up'.

currently node can have 3 states regarding connectivity (and so there are 3 events): down (event SYS_NODE_DOWN) - when server cannot contact the node and has no topology information for event correlation or it is really problem with that node; unreachable (SYS_NODE_UNREACHABLE) - when server knows that node cannot be contacted due to intermediate router/interface failure; and up (SYS_NODE_UP) - when node is reachable. So when node becomes unreachable, either SYS_NODE_DOWN or SYS_NODE_UNREACHABLE event is generated, depending on root cause. But when node became reachable again, SYS_NODE_UP being generated. I see two possible solutions - either add previous state indicator to SYS_NODE_UP event or create separate event for node returning from unreachable state - then you'll be able to distinguish between those two types of node up events.

Best regards,
Victor

Hi!

It should see as long as you have all devices in NetXMS and information about MAC addresses is there. It's hard to tell more without more detailed information (MAC address tables, topology poll results, etc.).

Best regards,
Victor

Hi!

Storage discovery connector is part of not finished feature and can be safely ignored. Push connector used by nxapush command line tool to push DCI values through agent's connection with server. Both are using UNIX sockets, with file names /tmp/.nxagentd.push and /tmp/.nxagentd.sd. Most likely they was left on file system and owned by root - this is why agent cannot open them as non-root user.

Line

if (g_dwFlags & AF_SUBAGENT_LOADER)

determines two execution paths depending on agent mode - is it master agent (the default one) or external subagent loader. NetXMS agent can be divided into multiple processes usually run under different accounts - in that case one is a master and others are external subagent loaders. External loaders communicates with master using UNIX sockets.

Best regards,
Victor

Насколько я понимаю, отправить сообщение в Hangouts через XMPP нельзя. Скорее всего поэтому он и дает "service unavailable". Или с других XMPP клиентов отсылка работает?

По идее все должно происходить автоматически. Попробуйте запустить сервер с дебаг уровнем 6 - должен появится дебаг XMPP (строки с префиксом XMPP:).

Hi!

As a workaround, run the following queries before DB upgrade:

ALTER TABLE object_tools MODIFY tool_data null;
ALTER TABLE object_tools MODIFY description null;
ALTER TABLE object_tools MODIFY confirmation_text null;
ALTER TABLE object_tools MODIFY matching_oid null;
ALTER TABLE object_tools_table_columns MODIFY col_name null;

Best regards,
Victor

Hi!

Changing database while server is running will not help, because most configuration information is cached and server do not expect outside modifications in DB. You can use nxshell scripts to change node parameters as needed. Also, if you are building server from sources, you'll be able to apply patch when we solve #566.

Best regards,
Victor

IMPORTANT NOTICE

We just fixed server crash mentioned earlier. I repack all distribution files on web site. If your installation is affected, you should download updated NetXMS server from web site. Files names was not changed, however build number in the version string was. Build with patch applied has number 7874.

Best regards,
Victor

Quote from: Dani@M3T on May 19, 2014, 03:11:48 PM
Alex

Here the output:
netxmsd: [New Thread 0x7fffabafa700 (LWP 2678)]
[New Thread 0x7fffab9f9700 (LWP 2682)]
[New Thread 0x7fffab8f8700 (LWP 2685)]
[New Thread 0x7fffab7f7700 (LWP 2689)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeefa5700 (LWP 2559)]
0x00007ffff4404a4f in gconv () from /usr/lib64/gconv/ISO8859-1.so
(gdb) bt
#0  0x00007ffff4404a4f in gconv () from /usr/lib64/gconv/ISO8859-1.so
#1  0x00007ffff4c81eda in __gconv () from /lib64/libc.so.6
#2  0x00007ffff4c81419 in iconv () from /lib64/libc.so.6
#3  0x00007ffff6b4b264 in MultiByteToWideCharIconv (cchWideChar=<optimized out>, pWideCharStr=0x7fffeefa2340 L"", cchByteChar=48, pByteStr=<optimized out>,
    dwFlags=<optimized out>, iCodePage=<optimized out>) at unicode.cpp:319
#4  MultiByteToWideChar (iCodePage=<optimized out>, dwFlags=<optimized out>, pByteStr=<optimized out>, cchByteChar=48, pWideCharStr=0x7fffeefa2340 L"",
    cchWideChar=<optimized out>) at unicode.cpp:365
#5  0x00007ffff75ee409 in SNMP_Variable::getValueAsString (this=this@entry=0x7fffac00ae40, buffer=buffer@entry=0x7fffeefa2340 L"", bufferSize=bufferSize@entry=1024)
    at variable.cpp:269
#6  0x00007ffff7abf7da in NXSL_SNMPVarBindClass::getAttr (this=<optimized out>, object=<optimized out>, attr=0x8b1df0 L"value") at nxsl_classes.cpp:690
#7  0x00007ffff73b3b9b in NXSL_VM::execute (this=this@entry=0x8b49f0) at vm.cpp:1001
#8  0x00007ffff73b4888 in NXSL_VM::run (this=0x8b49f0, argc=argc@entry=1, argv=argv@entry=0x7fffeefa38a8, pUserLocals=pUserLocals@entry=0x0,
    ppGlobals=ppGlobals@entry=0x0, pConstants=pConstants@entry=0x0, entryPoint=entryPoint@entry=0x0) at vm.cpp:271
#9  0x00007ffff7a79d35 in DCItem::transform (this=this@entry=0x8a8ba0, value=..., nElapsedTime=<optimized out>) at dcitem.cpp:869
#10 0x00007ffff7a7a1e8 in DCItem::processNewValue (this=0x8a8ba0, tmTimeStamp=1400500863, originalValue=0x7fffac0008c0) at dcitem.cpp:680
#11 0x00007ffff7a87837 in DataCollectionTarget::processNewDCValue (this=0x829670, dco=dco@entry=0x8a8ba0, currTime=currTime@entry=1400500863, value=0x7fffac0008c0)
    at dctarget.cpp:371
#12 0x00007ffff7a77113 in DataCollector (pArg=<optimized out>) at datacoll.cpp:254
#13 0x00007ffff5c230db in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff4d4690d in clone () from /lib64/libc.so.6

Hi!

Crash is very strange - I cannot understand how this could happen. Could you try to rebuild server with --disable-iconv configuration option? Also, is it possible to provide me remote access so I could debug this crash in place?

Best regards,
Victor