NetXMS Support Forum

A v kakom meste ispol'zuetsja skript? V event processing policy? Esli da, to on dolzen vozvraschat' 0 ili 1 - 0 oznachaet chto sobitie pod pravilo ne podhodit - 1 - chto podhodit. Custom message nado zadavat' cherez peremennuju CUSTOM_MESSAGE, bez znaka dollara, i potom mozete ispol'zovat' eto znachenie v alarmah i action'ah cherez macros %M. Naprimer:

sub main()
{
   if ($1==770)
      CUSTOM_MESSAGE="FastEthernet 0/3";
   return 1;
}

I ja podumaju kak sdelat', chtobi ne pisat' if dlja kazdogo interfejsa.

That means that for nodes with id 84 and 86 collected data will not be stored. I suggest to recreate these tables by the following queries:

CREATE TABLE idata_84 (item_id integer not null,idata_timestamp integer not null,idata_value varchar(255) not null);
CREATE INDEX idx_idata_84_item_id ON idata_84(item_id);
CREATE INDEX idx_idata_84_id_timestamp ON idata_84(item_id,idata_timestamp);

CREATE TABLE idata_86 (item_id integer not null,idata_timestamp integer not null,idata_value varchar(255) not null);
CREATE INDEX idx_idata_86_item_id ON idata_86(item_id);
CREATE INDEX idx_idata_86_id_timestamp ON idata_86(item_id,idata_timestamp);

Best regards,
Victor

Also, there are a bug registered in MySQL bugtracker - http://bugs.mysql.com/bug.php?id=15667 which seems similar to your problem. One of possible solutions mentioned in comments is to increase value of server variable innodb_buffer_pool_size (may be useful if you use InnoDB database, not MyISAM).

Also, if manual DELETE FROM statements will not work, try to clear tables with

TRUNCATE TABLE syslog;
TRUNCATE TABLE event_log;
TRUNCATE TABLE snmp_trap_log;
TRUNCATE TABLE audit_log;

Best regards,
Victor

Hi!

Try to connect to your database with mysql client and clear log tables manually by executing the following queries:

DELETE FROM syslog;
DELETE FROM event_log;
DELETE FROM snmp_trap_log;
DELETE FROM audit_log;

Then run upgrade process again.

Best regards,
Victor

I have fixed it. Agent now will correctly handle rename of monitored file (which usually happens during log rotation). I plan to release version 0.2.31 in a few days, it will contain this fix.

Best regards,
Victor

Спасибо за trace, решил проблему. В течении нескольких дней выложу версию 0.2.31, которая будет корректно работать с трапами версии 3.

Я в ближайшие дни выложу версию 0.2.31 с исправлениями последних багов. Эта проблема тоже должна быть решена.

Yes, it's looks like a bug. I'll check it in a few days.

Best regards,
Victor

Hello!

This may happen when communication session that was inactive for long period (controlled by agent's parameter SessionIdleTimeout) forcibly closed by watchdog thread. You can safely ignore these messages.

Best regards,
Victor

Hi!

Looks like sockets opened by agent closing slower than agent restarts. You can try to add agent startup delay by adding parameter to configuration file:


StartupDelay = <seconds>


and try different delay values. However, it will still be possible that NetXMS server will detect non-responding agent and generate appropriate event.

But why you are need to restart agent after log rotation? Is it stop working, or prevents log rotation? It is supposed to detect log rotation and handle it, and if it doesn't, then it's a bug which needs to be fixed.

Best regards,
Victor

I was able to reproduce this problem on my machine. Please replace file src/server/core/userdb_objects.cpp and recompile server - problem should be fixed.

Best regards,
Victor

Just tested on my Ubuntu machine with PostgreSQL - I got failed SQL query, but no crash. Could you please run netxmsd under gdb and when it crashes get stack trace with bt command?

To run under gdb:

# gdb netxmsd
(gdb) run

when crashes
(gdb) bt

Best regards,
Victor

Hi!

Yes, it's a bug - there should be

DELETE FROM user_groups WHERE id=%d

However, failed SQL query should not cause server to crash anyway. Could you try to replace groups to user_groups in this query, recompile server and try delete group again?

Best regards,
Victor

Vilozil obnovlennij User Manual, tam dobavleno opisanie monitoringa sysloga.

Dlja sysloga znavhenija severity sledujuschie:

1   Emergency
2   Alert
4   Critical
8   Error
16 Warning
32 Notice
64 Informational
128 Debug

T.e. dlja fil'tracii informational, notice, and warning nado pisat' <level>112</level>