I think we should remove this code as suggested. I am working on it.

Fixed in dev branch branches/dev/ZBX-4564, ready to test.

<zalex> Agent and Server of dev branch tested. All is fine. Seems ready to code review and merge.

Great! Tested successfully!

Implemented in revision 25024.

Note: Fixed in pre-1.8.11 r25022, pre-1.9.9 r25023

Ubuntu Dev Precise (12.04)

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4535

Just for record: as I see this dev branch already includes fix from ZBX-3475. Great!
So ZBX-3475 can be closed after this one.

Great fix! Even more order in our autoconfiguration process! Just tiny formatting change in r25079.

<Sasha> CLOSED

Fixed in versions pre-1.8.11 r25085 and pre-1.9.9 r25087.

Tested on Linux.

might be another items.lastvalue manifestation (although i can't find the previous issues on this right now)

what database are you using?

Cannot reproduce with PostgreSQL.

Check a structure of a 'items' table. Size of fields 'lastvalue' and 'prevvalue' should be 255.

Mysql.
Yes, lastvalue and prevvalue columns of items table have type "varchar(255)".

Is it possible that it depends of 8-bit value?
In my case, triggers "

<1" and "

<1" returns problem, but "

<1" returns OK.
I can open my zabbix_agentd for your server if it can help.

Please attach screenshot of "web.page.get[fidonet.org.ua]" item configuration.

web.page.get[fidonet.org.ua] item configuration

Confirmed: The given problem happens if in the first 255 characters is present the CR (0х13) character.

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4526

The priority is changed to the "Critical".

Successfully tested. Please fix ChangeLog message, it contains typo.

Fixed in version pre-1.8.11, revision 24752.

Linux, Debian

Discovery can work very slow for big IP addresses range with so big count of checks and many of unavailable hosts.
Maybe need to wait day or two ?

I'm aware of that, but I have this configuration for about 6 months now. So I think that is more than enough waiting.

If you have a better way of configuring the discovery, please tell me.

Confirmed: We always add discovered host to group "Discovered hosts".

That is a good thing. But I'd like to remove it again.

Because it also shows up as a host group with errors on the dashboard for example.

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4507

It's interesting how I finally managed to reproduce the problem only when I split "add host" and "remove from discovered hosts" operations into 2 different actions. Within one action I wasn't able to reproduce it. Yes, but it's true that server was adding the host back to group every time "add host" operation was executed.

Tested. Please review my changes in r24932, r24933.

<Sasha> CLOSED

Fixed in version pre-1.8.11, revision 24989.

Just a note: Fixed in version pre-1.9.9, revision 24993 too.

(1) rev 24503 did :
+ for ($i = 1; $i <=2; $i++) {

is suspect this might not match the coding stye
<Slava> RESOLVED r 24511

• for ($i = 1; $i <=2; $i++) {
  + for ($i = 1; $i <= 2; $i++) {

<richlv> CLOSED

Server side TESTED.

for the record, this is supposed to allow template triggers to depend on host triggers and should also fulfill ZBXNEXT-835

(2) this should be documented in the trigger dependency docs

http://www.zabbix.com/documentation/2.0/manual/config/triggers/dependencies

<Sasha> Rich, thanks! CLOSED

Tested, somebody should review my changes in r24536 and r24547 and then it can be merged into upstream.

<Sasha> CLOSED

Available in version pre-1.9.9, rev. 24570.

Reopened to remove 2.0 from "Fix version"

Closed again.

RHEL CentOS 5.6, 6.0 Postgresql-8.4.7

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4424

Please review my changes in r23928.

<Sasha> Great! CLOSED

Fixed in version pre-1.8.10, revision 23950.

FreeBSD srv-zabbix01.trendeiras 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #5: Mon Dec 5 07:57:08 BRST 2011 [email protected]:/usr/obj/usr/src/sys/TREND amd64

FreeBSD inside vmware, typical instalation.

(root@srv-zabbix01 - ~ @14:29:40)
1: pkg_info |grep mysql
mysql-client-5.5.17 Multithreaded SQL database (client)
mysql-server-5.5.17 Multithreaded SQL database (server)
php5-mysql-5.3.8 The mysql shared extension for php

./configure --prefix=/usr/local --sysconfdir=/usr/local/etc/zabbix --enable-server --enable-agent --with-mysql --with-libcurl --with-net-snmp --with-ssh2 --with-ldap --with-openipmi

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4418

Tested.

Fixed in version pre-1.9.9, revision 23920.

Centos

Thanks for reporting this. It should be fixed.

Fixed the default zabbix_server.conf in version pre-1.8.11, r24572.

It's normal. All low level discovery data is stored and processed in JSON format. Slashes (/) in JSON strings should be escaped. (www.json.org)

Please attach a screenshot, if you have a problem with LLD.

screenshots

What database you are using on server and proxy side?

Confirmed, when using mysql on proxy side.

Could repeat only once. After setting additional debug-information in the code and compilation of a proxy the problem hasn't repeated.

Try to recompile a proxy too using these commands:

./bootstrap.sh
./configure -enable-proxy --with<db> ...
make clean
make dbschema
make install

problem remains with last trunk proxy on PostgreSQL.

on debian with mysql the problem hasn't repeated.
problem on gentoo with postgresql only.

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4376

working. Thanks

Do we really want to "set standard_conforming_strings to off;" ?

You are right! It is the bad idea. In version PostgreSQL 8.1 this variable only for reading. I re-open this problem for finishing.

Has been fixed by another way. Please retest r23707.

I like it!

Fixed in version pre-1.9.9, revision 23728. Backported to pre-1.8.10, revision 23729.

note that json standard does not require escaping of slashes (only doublequotes and backslashes). from http://www.ietf.org/rfc/rfc4627.txt :

"All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F)."

ZBX-5116 talks about similar topic in the frontend/api

DebugLevel=3

(1) By the way, the name of function "housekeeping_process_log()" seems is not optimal.

I suggest to change it to "housekeeping_process_deleted_items()" or similar.

<dimir> I chose housekeeping_cleanup(), RESOLVED in r23553

<zalex> Excellent ! CLOSED

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-4298

I've chosen "housekeeping_cleanup()", if nobody minds. So the report will look like this:

11921:20111125:180134.824 housekeeper deleted 0 records from history and trends, 28561 records of deleted items, 0 events, 0 alerts and 0 sessions

This will be logged on every housekeeper step even if nothing was removed. Agreed with sasha that this way there will will be no questions whether it actually was or not an attempt to delete the data.

Dev branch tested. Works as expected. Single line for report is very-very good.

(2) I would suggest to write that line as:
housekeeper deleted: 0 records from history and trends, 28561 records of deleted items, 0 events, 0 alerts, 0 sessions
It seems for me it will be in more readable form.

<dimir> RESOLVED in r23560

<zalex> Many thanks. CLOSED.

Fixed in pre-1.8.10 r23632, pre-1.9.9 r23633.

(1) Broken compilation of the latest trunk.

housekeeper.c: In function ‘housekeeping_cleanup’:
housekeeper.c:135: error: ‘ids_alloc’ undeclared (first use in this function)
housekeeper.c:135: error: (Each undeclared identifier is reported only once
housekeeper.c:135: error: for each function it appears in.)
housekeeper.c:135: error: ‘ids_num’ undeclared (first use in this function)
housekeeper.c: In function ‘housekeeping_alerts’:
housekeeper.c:186: warning: ‘return’ with a value, in function returning void
housekeeper.c: In function ‘housekeeping_events’:
housekeeper.c:213: warning: ‘return’ with a value, in function returning void
housekeeper.c: In function ‘main_housekeeper_loop’:
housekeeper.c:328: error: void value not ignored as it ought to be
housekeeper.c:331: error: void value not ignored as it ought to be

<dimir> sorry for the broken trunk, RESOLVED in r23663 directly in trunk

<zalex> tested. trunk r23663 compiled ok and it works.

<sasha> CLOSED with small change in r23688.

(2) also :
what's the difference between "history and trends" and "records of deleted items" ? i assume the latter is not the amount of items, but the amount of history and trends values for those items ?

<dimir> "Old history and trends" is the outdated information (as configured in the item keep this and that), "records of deleted items" is all the data (basically what's in "housekeeper" table) related to removed item.

<zalex> maybe would be better to replace all words "records" to the "values"? It will be more clear.

<dimir> For me "deleted 2 values from history and trends" is not more clear than "deleted 2 records from hostory and trends". What I'd add is singular value support.

<dimir> if there are no objections, RESOLVED in r23681

<zalex> dev branch r23681 tested. it works (see 1 event):
"housekeeper deleted: 7056 records from history and trends, 0 records of deleted items, 1 event, 0 alerts, 0 sessions"
he-he, it's some "alternative" to gettext

<dimir> We decided to discard these changes as we don't have anything like it anywhere. CLOSED

Oleksiy, thank you for testing!

Fixed in trunk r23663.

(3) i suspect "d_clenup" is a typo

<dimir> Right, RESOLVED in pre-1.8.10 r23732, pre-1.9.9 r23733.
<sasha> CLOSED

Closing resolved issue

Reopening to assign to myself.

Closed.

48 deleted events reported as 1 in 1.8.10rc1

strace output :

event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=11", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=18", 40) = 40
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=5", 39) = 39
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=9", 39) = 39
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=1", 39) = 39
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=47", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=38", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=44", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=43", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=36", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=42", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=34", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=35", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=31", 40) = 40
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=8", 39) = 39
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=30", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=40", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=37", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=13", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=39", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=33", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=46", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=29", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=48", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=41", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=14", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=32", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=10", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=27", 40) = 40
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=6", 39) = 39
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=7", 39) = 39
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=12", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=26", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=45", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=24", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=25", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=17", 40) = 40
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=2", 39) = 39
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=3", 39) = 39
event_strace.13938:write(6, "#\0\0\0\3delete from events where eventid=4", 39) = 39
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=15", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=16", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=20", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=21", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=22", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=23", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=19", 40) = 40
event_strace.13938:write(6, "$\0\0\0\3delete from events where eventid=28", 40) = 40
event_strace.13938:write(7, " 13938:20111217:175347.261 housekeeper deleted: 0 records from history and trends, 0 records of deleted items, 1 events, 0 alerts, 0 sessions\n", 142) = 142

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4298

Tested successfully.

Available in version pre-1.8.11, r24309.

lastest rev 22669

please, attach a screenshot of item configuration. also, you could try snmpget for the oid exactly as it's specified in the item configuration

time snmpget -v2c -c public c2r3ups01.88.ru .1.3.6.1.4.1.318.1.1.1.2.2.2.0
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 21

real 0m0.051s
user 0m0.028s
sys 0m0.000s
dotneft ~ $ time snmpget -v2c -c public c2r3ups01.88.ru .1.3.6.1.4.1.318.1.1.1.2.2.2.0
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 21

real 0m0.050s
user 0m0.024s
sys 0m0.000s
dotneft ~ $ time snmpget -v2c -c public c2r3ups01.88.ru .1.3.6.1.4.1.318.1.1.1.2.2.2.0
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 21

real 0m0.051s
user 0m0.020s
sys 0m0.000s
dotneft ~ $ time snmpget -v2c -c public c2r3ups01.88.ru .1.3.6.1.4.1.318.1.1.1.2.2.2.0
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 21

real 0m0.050s
user 0m0.020s
sys 0m0.004s

item settings

we checking then the problem and found following relationships:
1. often troubles with snmp was with hosts (checking by ip) without/incorrect A or PTR DNS records.
2. after we resolve A and PTR DNS records, another and first errors disappeared from logs

But the problem remains, how affected by the availability of DNS records for hosts with check by ip?

Perhaps SNMP device relies on availability of DNS somehow, say for security checks, audits, something else?

maybe. I think net-snmp have internal checks,audit... etc.
messages about errors missing from zabbix log after DNS records ordering.

I think we can close the issue.

GUI RESOLVED.

(2) Crash in unreachable poller when processing discovery rule. Attached files:

r23752-mysqldump.txt
r23752-objdump.txt
r23752-zabbix-server.log

Steps to reproduce:
1) create template "lld" in a new group "lld"
2) create discovery rule "vfs.fs.discovery" in that template
3) create 2 item prototypes for the rule:
vfs.fs.size[

,total]
4) create a graph prototype for the rule:

• use "free" prototype as an item for the graph
• use "total" prototype as "Y axis MAX value"
  5) link enabled host to "lld" template
  6) restart zabbix server and agent
  7) observe zabbix_server.log file for a crash

Frequency: 2/2 (the second time from clean database).

<sasha> Thanks for objdump! RESLOVED

<dimir> Perfect! CLOSED

Tested successfully.

Available in version pre 1.9.9, revision 23781.

Debian GNU/Linux "testing". Linux kernel 2.6.38. 64 bit (aka "amd64"). SQLite version 3.7.7. Laptop with Core i7 system with 4 GB of RAM and 128 GB SSD.

The problem is basically Oracle. It doesn't have "BEGIN" thing. So if we want a transactioned data import in SQLite we would have to maintain separate data.sql files and we don't want that. Basically we see the only solution as to note somewhere in the instructions that SQLite users must wrap the data.sql around "BEGIN/COMMIT" manually.

<dimir> Here is our suggestion (thanks for an idea to sasha):

Here is the debian/rules section to create SQLite db:

cat create/schema/sqlite.sql create/data/data.sql create/data/images_sqlite3.sql > $(TMP_SERVER_SQLITE3)/usr/share/dbconfig-common/data/$(PKG_SERVER_SQLITE3)/install/sqlite3

How about just modifying it to:

(cat create/schema/sqlite.sql; echo 'BEGIN;'; cat create/data/data.sql create/data/images_sqlite3.sql; echo 'COMMIT;') > $(TMP_SERVER_SQLITE3)/usr/share/dbconfig-common/data/$(PKG_SERVER_SQLITE3)/install/sqlite3

?

<richlv> this will work, but you will probably see higher load from shell (should be ok in this case, but with larger datasets it can be a huge problem)

Your call. That would mean I'd have to permanently ship a patch with Debian packages. Without that fix an installation time of up to an hour will probably not be considered acceptable for the SQLite3 packages.

Fixed in development branch for Zabbix 2.0. Ready to test.

(1) Directory "database" is missing proper svn:ignore settings.

<alexei> RESOLVED.

<asaveljevs> CLOSED

(2) File "do" in the root directory is hopelessly outdated. Shall we remove it?

<asaveljevs> Let's clean up "go" script, too.

<alexei> removed both files. RESOLVED.

<asaveljevs> CLOSED

(3) Script gen_php.php does not work anymore:

$ php gen_php.php
File does not exist: "/home/asaveljevs/zabbix-svn/branches/dev/ZBX-4024/create/bin/schema.tmpl"

<alexei> RESOLVED

<asaveljevs> CLOSED

(4) Please review r22787 and r22791. The commits are mostly about fixing typos and style inconsistencies.

<asaveljevs> In particular, it fixes a typo in ChangeLog: "db data file uses transations now". However, I did not understand what kind of translations are meant. Could you please explain that? Perhaps it is something worth documenting.

<richlv> i'd guess it was supposed to be "transactions"... unless this was a clever sarcasm that i fell for, it shows the importance of (not having) typos

<alexei> it shows importance of having spell checker built-in vi editor. RESOLVED.

<asaveljevs> CLOSED

(5) Script export_data.sh can only be run from create/src, but it would be nice to be able to run it from any directory. Property svn:ignore would then have to be set up to ignore data.tmpl.new, wherever that is generated.

<alexei> Now data.tmpl.new is ignored under create/bin. RESOLVED

<asaveljevs> It is still not possible to run export_data.sh from any directory.

<asaveljevs> Also, if data.tmpl is located in create/src, why not place data.tmpl.new in that directory, too?

<alexei> The file will write data to stdout like other utilities do. Also added help string, proper exit code. It is possible to run it from any directory. RESOLVED

<asaveljevs> Still not possible to run from any directory:

$ create/bin/export_data.sh issue_zbx_4024 > /dev/null
grep: ../src/schema.tmpl: No such file or directory

<alexei> I wrongly tested it running from src, bad test. RESOLVED

<asaveljevs> Still not possible. For instance, from a directory that contains spaces:

$ ZBX\ 4024/create/bin/export_data.sh issue_zbx_4024 | head -10
dirname: extra operand `4024/create/bin/export_data.sh'
Try `dirname --help' for more information.
basedir: ''
schema: '/../src/schema.tmpl'

<alexei> now it works with spaces and hopefully with other special characters as well. RESOLVED

<asaveljevs> No, it does not:

$ ZBX\ 4024/create/bin/export_data.sh issue_zbx_4024 | head -10
dirname: extra operand `4024/create/bin/export_data.sh'
Try `dirname --help' for more information.
...
grep: /../src/schema.tmpl: No such file or directory

You have not fixed all the places.

<alexei> it's a shame! RESOLVED

<asaveljevs> Hurray! CLOSED.

(6) Pipe-delimited approach for data may fail if data itself contains pipes. For instance, this can happen with triggers that use OR in expressions or item keys that use regular expressions. Maybe not now, but in future we will have to take that into account.

<richlv> appliance templates already use this (to detect various possible apache or syslog process names) - i'd say that's pretty critical

<alexei> RESOLVED

<asaveljevs> The following code is wrong:

local $line = $_[0];
+ $line =~ s/&pipe;/|/;
@array = split(/|/, $line);
$first = 1;

Replacing of "&pipe;" should be done after splitting $line by pipe characters.

<alexei> :-0 RESOLVED

<asaveljevs> Looks good. Please review additional changes in r22883.

<asaveljevs> Please also take a look at r22893 - it fixes start of transactions in SQLite3. Statements for transactions in IBM DB2 and Oracle will remain empty.

<alexei> I like changes in the Perl code, SQLite3 fix is also great. CLOSED.

Fixed issues found during code review and testing. Ready to retest.

(7) I have updated instructions for Oracle at http://www.zabbix.com/documentation/2.0/manual/installation/install?&#zabbix_database . Since I do not know the current state of ZBXNEXT-675, I used "old_images" in the example. Please review.

<alexei> I found no issues, Oracle instructions look good to me. CLOSED

(8) Please review the list of tables that should be included by export_data.sh in data.tmpl.

<alexei> RESOLVED

<asaveljevs> After these changes (actually, before these changes, too), empty tables might appear in data.tmpl. Do we want that?

<asaveljevs> I have exported a database with a slide show in it. When trying to import it into a new database, I get the following error:

$ mysql -uroot issue_zbx_4024 < database/mysql/data.sql
ERROR 1452 (23000) at line 11: Cannot add or update a child row: a foreign key constraint fails (`issue_zbx_4024`.`slides`, CONSTRAINT `c_slides_2` FOREIGN KEY (`screenid`) REFERENCES `screens` (`screenid`) ON DELETE CASCADE)

<asaveljevs> Please also review changes in r23222 and r23223.

<alexei> The changes are ok to me. I ordered all tables so they match referential integrity constraints. Note that no handling of loop constraints (table1->table2->table1) and self-references (table1->table1) is implemented currently. Now empty tables do not appear in both data.tmpl and schema.tmpl. RESOLVED.

<asaveljevs> It would be nice to group tables in schema.tmpl more logically, so that semantically similar table are closer together. For instance, there is no need to keep "trigger_depends" table so far from "triggers" table and "maintenances_*" tables" are very far from "maintenances" table.

<alexei> Fixed trigger_depends & triggers. I am afraid of reviewing and moving other tables (look at maintenances*, there are so many constraints attached!), it may break something if not done very carefully. I would leave it as it is, it's really hard to come up with a single "placement principle", who is coming first, etc.

<asaveljevs> We have a comment in schema.tmpl that says "-- History tables". Tables "dhosts" and "dservices" are not in that section, although they might be considered history tables. Same for "autoreg_host" and "proxy_autoreg_host".

<alexei> RESOLVED

<asaveljevs> Also, table "ids" references table "nodes", but comes before it. Same for tables that reference "images" table.

<alexei> RESOLVED

<asaveljevs> OK, CLOSED for all.

<asaveljevs> Please review my changes in r23329.

<alexei> I like it. CLOSED.

Resolved in 23584.

reopen to set more precise "fix for" version

see ZBX-4408 for some issues with export_data.sh script

SQLite FAQ has a high-level explanation for the reason it took so long without transactions: http://www.sqlite.org/faq.html#q19 .

It has been decided to remove aggregate graph items whatsoever.

Please review the update for the trunk GUI in /branches/dev/ZBX-3832. RESOLVED.

(1) doesn't server also need some updates for graphs it creates from network discovery, active agent auto-registration and low level discovery ?
edit: it must. server still refers to periods_cnt

<pavels> Ah, of course it does, sorry.
<sasha> RESOLVED

<dimir> CLOSED

(4) documentation must be updated :
http://www.zabbix.com/documentation/2.0/manual/appendix/api/graphitem
http://www.zabbix.com/documentation/2.0/manual/appendix/api/graph/create
http://www.zabbix.com/documentation/2.0/manual/appendix/api/graphitem/get
anywhere else ?

it should also be noted that this change will have to be reflected when transferring xml docs and possibly others

<pavels> RESOLVED.
<sasha> REOPENED http://www.zabbix.com/documentation/2.0/manual/config/visualisation/graphs/custom
<sasha> RESOLVED

<pavels> CLOSED.

Available in version pre1.9.9, r23639.

FreeBSD8.1
pkg_info | grep sqlite
php5-pdo_sqlite-5.3.5 The pdo_sqlite shared extension for php
php5-sqlite-5.3.5 The sqlite shared extension for php
py26-pysqlite-2.3.5 A DB-API v2 Python library for the SQLite 3 embedded SQL en
sqlite3-3.7.4 An SQL database engine in a C library

Sorry, but I do not see any issues here. Why blocker?

Check for the SQLite3 library is done in exactly the same way as, for example, check for PostgreSQL library. We do not look at any OS specific directories.

I am closing it.

he-he, the game is NOT over.
why blocker - because of compilation error .
Probably my knowledge is not great as your Alexei, but I'm single-minded and partially crazy .

I'm not agree that "/usr/local" is a specific directory. It's prefix-path, where installed all software under FreeBSD and maybe not only - i don't know.
And for example you're not right about <We do not look at any OS specific directories> - see to the "libssh2.m4". This macro try to check several paths and it authors are two Zabbix developers.

Okay enough talk, take my very simple patch "ax_lib_sqlite3.m4.diff"

A source info here:
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=cf19f0cc2e2b52c025063354c9cfd91ea0bf8fdf;hp=05f057531dfd0308c9892df4913c92101196ad18

Well, after figure out of the source code and manuals of auto**** stuff I see that static linking is not provided - and really I can't compile with --enable-static flag. Check it out and apparently it also should to be fixed.

All right, I agree that it shouldn't be closed. Let's keep it open, priority was changed to Minor.

Fixed in versions pre-1.8.11 r25085 and pre-1.9.9 r25087. See ZBX-4535 for more details.

latest trunk

Having the same issue with 1.9.3.

I think the current logic of keeping auto-generated resources around after they disappear from discovery is the way to go.

However, these items must be able to be removed manually and not auto-removed.

It would be great if there was an option to choose what to do when discovered item is no longer present.

I can think of two possible scenarios: delete that item automatically or disable it and allow for manual removal. That would certainly decrease resources usage on rapidly changing monitoring environment.

I'd really like to see an option to auto remove discovered items. For things like file system or net interfaces this might not be critical, and we might want to continue seeing these items after we remove them. But other use cases like for monitoring instances of a process on a system that spawn new processes based on some external input (rapidly changing system) there should be an option to automatically delete the discovered items after they disappear.

A new global (Administration->General->???) configuration parameter will define life time of lost items. If an item exceeds the period, it will be removed and a new record for housekeeper will be added as well.

maybe do better not global? host level or discovery?

lld rule level would seem to be most appropriate. for example, we might have a host which has network interfaces quite rapidly changed, thus we know that interface going down would allow us to mostly safely remove it after 3 days. on the other hand, disk volumes going away would be less frequent, and data would be more important in the long term, thus we would like to have those items only removed after 2 weeks have passed

Sure, it's better to keep it on lld level with support of user macros (template, host, global).

New field "lifetime varchar(64)" is added to "items" table. Allows usermacro or number in days.
New input field is added to discovery rule form before "status".

(1) GUI
I think we should replace the maximum (and, maybe, minimum) lifetime with constants in the CDiscoveryRule::checkSpecificFields() and CDiscoveryRule::validateLifetime() methods and try to avoid using literal constants in the future.

Same for validatePortNumber()

<Vedmak> RESOLVED

<pavels> CLOSED.

(2) GUI
Shouldn't the clearValues() method in CItemGeneral::checkInput() and CHostInterface::checkInput() be called before the validation is performed? What's the point of cleaning up values, if they are already OK?

<Vedmak> RESOLVED

<pavels> CLOSED.

(3) GUI
Please review my changes in r23788 and r23789.

<Vedmak> CLOSED

(4) DOC
The docs should also be udpated
http://www.zabbix.com/documentation/internal/database_2.0/items
http://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery

<Vedmak> I'll update db and api docs, and put separate paper on the board for it.

<pavels> Db and API docs are ok. CLOSED.

(5) [DB] DB patches
upgrades/dbpatches/2.0/postgresql/patch/hosts.sql:64 - incorrect SQL statement delimiter
upgrades/dbpatches/2.0/oracle/patch/hosts.sql:64 - useless constraint 'NOT NULL'

<Vedmak> RESOLVED
<sasha> CLOSED

(6) GUI
When cloning a discovery rule or full cloning a host an error occurs:
"Discovery rule "lld22-2:lld2" has incorrect lifetime: "". (min: 0, max: 3650, user macro allowed)"

<Vedmak> RESOLVED

<pavels> CLOSED.

(7) [GUI] when creating/updating a discovery rule with 'Keep lost resources period (in days)' = 0 an error occurs:
Discovery rule "vfs.fs.discovery:vfs.fs.discovery" has incorrect lifetime: "". (min: 0, max: 3650, user macro allowed)

<Vedmak> RESOLVED

<pavels> CLOSED.

(8) api docs (to avoid overloading (4))
a) having http://www.zabbix.com/documentation/2.0/manual/appendix/api/discoveryrule is great, but to be consistent i guess there shouldn't be space in the page title (not sure about capitalisation)

b) also should be listed at http://www.zabbix.com/documentation/2.0/manual/appendix/api/changes_1.8_-_2.0

<Vedmak> RESOLVED

<richlv> do we have a rule on class naming ? because now we have "TemplateScreen" and "Discoveryrule" - would be nice to settle on either camelcase or something.
hmm, changes page actually says "DiscoveryRule" - which one is correct then ?

<zalex> last question moved to ZBXNEXT-1058
CLOSED

GUI is TESTED.

A server side is ready to test!

<dimir> Great! Please review my changes that allow it to work without graph prototypes in r23965 .

I could not to not test the dev branch ASAP
Server side tested. Seems it works.
A part of the debuglog attached.

>>> 15557:20111208:010525.923 poller #1 spent 2.178640 seconds while updating 1 values
it's ok because tested SNMP device is partially slow:

1. time snmpwalk -c scarysecret -v 1 10.20.0.5 IF-MIB::ifAlias
   .....~40 result records ....

real 0m1.965s
user 0m0.344s
sys 0m0.016s

(9) An item, has been not passed through the filter but doesn't deleted yet, still continue to be monitored:

mysql> select i.lastclock, d.lastcheck from items i, item_discovery d where i.itemid=25905 and i.itemid=d.itemid;
----------------------+

----------------------+

----------------------+

Is it ok by design?

added:
For instance, how an user can understand that after he changed the Regexp previously discovered and added resources currently are not passing by filter?
So if a gathering the data will be stopped then it could be some "indicator" that the resources are not discovered anymore an they going to be deleted in N days.

How is else the user can understand that some resources are not discovered anymore?

<zalex> some part moved to the ZBXNEXT-1058, some to the ZBX-4475
CLOSED

(11) I would suggest to change default value 0 days for "Keep lost resources period (in days)" to for instance 1 day when an user creates new discovery rule.
Try to imagine the case when the user creates discovery rule and forgot to change 0 to the value>=1.
Later he or someone else wrongly changes Regexp of discovery rule and all historical data can be unexpectedly lost in one moment (when discovery will be performed by the zabbix_server next time).

It's danger behavior. The user has to set 0 day only when he is understanding what he doing.

<zalex> moved to ZBXNEXT-1058
CLOSED

Hi.
the method I suggested in ZBXNEXT-925 could be an answer :
you could add a 'layer' between discovery and actual item creation, where user could see with some kind of status

• the currently discovered ressources
• the previously discovered ressources no longuer present, both with the date of last discovery
• and eventualy the manualy added ressources.( wich was the main request for the ZBXNEXT-925)

That way the user can choose between automatic and manual creation / deletion,
see what's going on with the discovery, manage the ressources by disabling / removing ressources.

That could allow some nw use cases like :
deactivate after an initial run the discovery and keep it's ressources ,
use the lld structure with manualy entered ressources etc.

Note, until ZBX-4425 is merged into trunk the server side will not work in this development branch. Meanwhile you can apply this patch:

svn diff svn://svn.zabbix.com/branches/dev/ZBX-4425 -c r23945

in order to test it.

merged: svn://svn.zabbix.com/trunk 24129

Additional improvements will be implemented in ZBXNEXT-1058

Reopened to close (move) some comments;
to remove 2.0 from Fixversion.

Closed again.

I've been looking around on the forums and whatnot and it seems like there is still no way to manually delete discovered resources, it would be great to see that added.

At least in my case, many (nearly 30) unnecessary network interfaces are added via the discovery rule and even though it is possible to disable the new items as a whole, I find this rather "polluting" to my setting.

I see no reason to leave those items there and I can't just recreate the host since I want to keep its historical data. Besides, those items won't get scheduled for auto cleanup because they're still discovered, I simply don't want them around anymore.

last trunk revision 13781

Sorry, further to the Russian, because a lot of logic and I can make a mistake with the translation

Теперь мне удается воспроизвести проблему боле четко, почти 100% воспроизведение.
Очень важно чтобы время на сервере и агенте было синхронизировано, тогда легко уверенно воспроизвести проблему.
Порядок действий:
Стартуем сервер где то на 55 секунде так чтобы он начал работать ровно на начале минуты!!! То есть чтобы процедура "DCsync_configuration" возникала ровно в начале минуты и мы на это будем ориентироваться.
Ждем ~57-58 секунды на заббикс агенте, стартуем скрипт, который быстро генерирует 100 событий в журнал событий. Агент настроен так что сразу же начинает отсылать события (буфер 1 сек.).
Сервер обрабатывает эскалации в интервале ~0-10 секунд в начале минуты. Где то в это период происходит "DCsync_configuration" или может быть другая процедура вызывает проблему - я точно не уверен.
В журнале аудита видим не 100, а 101 сообщение.

Предварительный итог таков: когда процедура "process_escalations" заканчивает свою работу после окончания процедуры "DCsync_configuration" тогда на последнее уже обработанное событие повторно ошибочно генерируется Алерт при следующем вызове процедуры "process_escalations". Извините если звучит сумбурно, но где то так.

Я подготовил куски лога где видно последовательность как возникает проблема. Там же даны описания между абзацев.
В примере лога (я подготовил его еще вчера) сервер стартовал НЕ начале минуты !!!, поэтому не обращайте внимание на штампы времени.

could this issue also apply to zabbix 1.8.5?
we have seen double activated actions and also double generated events (so far always 3s between those events). The last time it happened with a trigger that had 8 conditions (8 items, 4 host 2 items each) connected with a logical OR
As far as i understood the google translation of the first comment, it looks like the same issue

Yes, i managed to reproduce it in the latest trunk rev:
Zabbix Server v1.9.7 (revision 22419) (9 September 2011)
Compilation time: Oct 14 2011 18:05:51

And I'm almost sure that this problem connected to the call of function DCsync_configuration()
New feature of "-R config_cache_reload" helps me a lot to reproduce this problem at the new much faster server than I used early.
I.e. I'm almost lost the hope to reproduce it, but "-R config_cache_reload" finally helped me

Let me some time to figure out some detail in the debuglog.

How to reproduce:
When zabbix_server massively sends the alerts (values received by Active agent, but maybe it's nor so important), need to execute the configuration cache reloading.

1. Agent bulk sends 50 values to server (one item as "zabbix agent active")
2. I wait ~ 8-10 seconds and server starts to massively send alerts (50 mail).
3. I execute "config_cache_reload" many-many times (interval 200-400 miliseconds) in short time period of time (3-5 seconds)
4. Problem is reproduced -> i have 51 mails in the box.

Which database?

> Which database?
My SQL 5.5.8 (FreeBSD), My SQL 5.1.49 (Debian).

This happens when alerts are created and put to DB, before they are handled. When we receive 50 values 51 alerts are spawned and 51 alert entries are put to DB. So step 2 and 3 can be skipped. I continue working on it.

This happens when escalations are handled. The conflict is between "escalator" and "history syncer" processes when they access "escalations" table. Continue investigating.

I have added some logging and here's the difference (both examples of handling escalation ID 2):

NO DUPLICATE EVENTS:
escalator#1:20111103:154956.268 process_escalations() escalid:2 eventid:8451 escstatus:0
escalator#1:20111103:154956.268 process_escalations() escalid:2 status:ACTIVE send mail
escalator#1:20111103:154956.275 process_escalations() escalid:2 status:0 FAILED, set nextcheck
histsyncr#1:20111103:154956.297 process_actions(eventid:8452) add escalation
histsyncr#1:20111103:154956.297 DBstart_escalation(remove older active escalations) actionid:3 and status not in (1,4,5)

DUPLICATE EVENTS:
escalator#1:20111103:123153.535 process_escalations() escalid:2 eventid:8195 escstatus:0
escalator#1:20111103:123153.535 process_escalations() escalid:2 status:ACTIVE send mail
histsyncr#3:20111103:123153.558 process_actions(eventid:8196) add escalation
histsyncr#3:20111103:123153.558 DBstart_escalation(remove older active escalations) actionid:3 and status not in (1,4,5)
escalator#1:20111103:123153.558 process_escalations() escalid:2 status:0 FAILED, set nextcheck

The problem happens when history syncer "intrudes" in while escalator is processing escalation.

So, the problem is that when escalator is selecting 51 escalations to process, from table containing 50 records. Here is how it happens:

• [history syncer] is adding 50 escalations one by one, using steps:
  • change current ACTIVE escalations to SUPERSEDED_ACTIVE
  • insert new escalation with status ACTIVE
• [escalator] selects escalations to process while history syncer is adding escalations, 51 rows are selected:
  • two records are returned with the same escalation ID and event ID:
    • one with status ACTIVE
    • another with status SUPERSEDED_ACTIVE

For the information, this happens also with just 1 dbsyncer, so no dbsyncers conflict.

From MySQL manual:

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read

The default isolation level of a transaction is REPEATABLE READ which causes the behavior. If I add the code to set transaction level to READ COMMITTED to only read what is commited:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

the problem goes away.

We decided to make our transactions more isolated, by disabling reading uncommitted data explicitly. Related documentation:

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
http://www.postgresql.org/docs/9.0/static/transaction-iso.html
http://www.sqlite.org/sharedcache.html (Section "2.2.1 Read-Uncommitted Isolation Mode")

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-2806 .

How I tested it:

• create Zabbix trapper item "test.garbage" (default values)
• create a trigger that will fire when that item receives non-zero with event generation Normal + Multiple PROBLEM events
• create action that will send e-mail when trigger value is PROBLEM

From console, feed the item with values (you can increase 50 to something bigger):

$ for ((i=0; i<50; i++)); do rnd=$[ $RANDOM % 100 + 1 ]; bin/zabbix_sender -z 127.0.0.1 -s "Zabbix server" -k test.garbage -o $rnd; done

You should be getting exactly 50 e-mails.

Patch for current trunk (r23016).

Oleksiy,

I have attached the patch for current trunk, would it be possible for you to test that and confirm that it fixes the problem?

Vladimir,
unfortunately I have reproduced the bug even for patched version.
Please, let me some time to prepare detailed answer and attach debuglog.

Currently I must to note that seems it's easier to reproduce the bug with DebugLevel=4 but not 3.
I recall this issue originally was reported and several times reproduced in the past with DebugLevel=4 only.

I tried patched version of latest trunk.
I used the command suggested by Vladimir (50 values sent).
I managed to reproduce the problem for ~30-60% attempts.
When I sent 200 values I was managed to reproduce for 99%.

But right now I tried my "old" method. And it works "even better"
I have little impression that it's easier to reproduce the bug using my method of send bulk values by active agent but not using zabbix_sender in the loop.

When I sent 200 values, I managed to reproduce the problem seems for 100% attempts (sometimes I have 202 alerts).

Huh, sorry for possible not clear comment, but I write it during last day and after several touches this issue.

See attached debuglog.
Duplicated alerts - eventID 671109.

Vladimir, why the issue is resolved?

Reopening based on comment https://support.zabbix.com/browse/ZBX-2806?focusedCommentId=50012&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50012

Move escalations handling to escalator process.

RESOLVED in r23283

This is a fix for 1.8 so Oleksiy, please wait till it's reviewed, then I'll create a patch for trunk. Merging a fix into trunk produces conflicts, I don't want to resolve them multiple times.

<zalex> I can test any version, trunk or 1.8 branch. Currently I do not need the patch for trunk namely. If it makes sense to test 1.8 branch before code review, please let me know.

<dimir> It would be great if you could try reproducing the bug with current 1.8 branch. Because I couldn't do it. Despite I was hitting the bug in 90% of cases when I used trunk. It's weird, considering that I could not find any differences in escalations handling code in 1.8 and trunk.

<zalex>
trunk branch:
Zabbix server v1.9.8 (revision 23322) (27 October 2011)
Compilation time: Nov 21 2011 02:56:07
Reproducible as usually.

--->>>> 1.8 branch:
Zabbix Server v1.8.9rc2 (revision 23324) (15 November 2011)
Compilation time: Nov 21 2011 01:36:57
Cannot reproduce for 2000 alerts.

Dev (this) branch:
Zabbix Server v1.8.9rc1 (revision 23283) (11 November 2011)
Compilation time: Nov 21 2011 01:01:30
Cannot reproduce for 2000 alerts.

Vladimir, as you see I cannot reproduce even for 1.8 branch.

(5) Fix triggerid and r_evnetid fields handling in process_escalations(). These fields are NULL by default in trunk.

<dimir> RESOLVED in r23428, r23431, please check
<sasha> CLOSED

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-2806-trunk

Because the fix requires changes in database and it's not reproducible in 1.8 anyway the fix will be only provided for trunk.

Oleksiy, it would be great if you could test svn://svn.zabbix.com/branches/dev/ZBX-2806-trunk .

<zalex>
Dev branch tested.
Debuglog:
21893:20111122:231849.864 In process_escalations()
21893:20111122:231849.864 query [txnlev:0] [select escalationid,actionid,triggerid,eventid,r_eventid,esc_step,status from escalations where (status=0 and nextcheck<=1321996729 or status=2 and r_eventid<>0) ·‡ order by actionid,triggerid,escalationid]
21893:20111122:231849.865 [Z3005] query failed: [1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '·‡ order by actionid,triggerid,escalationid' at line 1 [select escalationid,actionid,triggerid,eventid,r_eventid,esc_step,status from escalations where (status=0 and nextcheck<=1321996729 or status=2 and r_eventid<>0) ·‡ order by actionid,triggerid,escalationid]
21893:20111122:231849.865 End of process_escalations()

Yes, some characters seems are not UTF8. I don't know what is that.
A part in HEX:
00000100 30 29 20 B7 │ 87 8F 15 7F │ 20 6F 72 64 │ 65 72 20 62 0) .. order b

Need to fix and then I'll retest it again.

(6) As zalex noted, there was a bug in SQL query.

<dimir> RESOLVED in r23450, please retest.

<zalex> r 23450, still error:
1017:20111123:095534.861 In process_escalations()
1017:20111123:095534.861 query [txnlev:0] [select escalationid,actionid,triggerid,eventid,r_eventid,esc_step,status from escalations where (status=0 and nextcheck<=1322034934 or status=2 and r_eventid not null) and escalationid between 000000000000000 and 099999999999999 order by actionid,triggerid,escalationid]
1017:20111123:095534.861 [Z3005] query failed: [1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'null) and escalationid between 000000000000000 and 099999999999999 order by acti' at line 1 [select escalationid,actionid,triggerid,eventid,r_eventid,esc_step,status from escalations where (status=0 and nextcheck<=1322034934 or status=2 and r_eventid not null) and escalationid between 000000000000000 and 099999999999999 order by actionid,triggerid,escalationid]
1017:20111123:095534.862 End of process_escalations()
1017:20111123:095534.862 escalator #1 spent 0.000156 seconds while processing escalations

<dimir> RESOLVED in r23455, sorry, my bad, I should have tested it better.

<zalex> r23455. after 10 000 events the problem is NOT reproducible. Seems it's ready to test|review by developers.

<dimir> Thank you, zalex.
<sasha> CLOSED

(7) Escalation always is deleted after first step. Following steps will never be executed.

<dimir> That's right, fixed delete escalation condition. RESOLVED in r23813.
<sasha> CLOSED

(8) Please review my changes in rev 23773.

<dimir> Perfect! CLOSED.

(9) src/zabbix_server/escalator/escalator.c:1243
I don't like this SQL statement. When I have generated 950 events, notifications have appeared only at 511 of them.

<dimir> RESOLVED in r23905
<Sasha> CLOSED

(10) Statement "SET DEFINE OFF" doesn't need the line-terminator ';' or '/'. Please remove it from gen_data.pl and help_items.sql.

<dimir> RESOLVED in r24018
<Sasha> CLOSED

Just a summary of what was done.

Previously escalations were processed by both dbsyncer and escalator. The same records in escalations table were modified by both processes. This was causing a mess and this was not possible to fix without a locking mechanism which we don't have/use (in cases like these). So instead, now dbsyncer only inserts records, which are later modified/removed by escalator process.

This also reduces the workload of dbsyncer which was also an issue.

<richlv> thanks for the description. does http://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew200?&#improved_history_db_syncer_performance summarise it correctly ?
this is something i'd love to test empirically...

<Sasha> Excellent! Thanks!

<zalex> See to the attached picture "rev24046_improvement.png". I suppose the mentioned documentation note has to be reviewed (it seems escalator's work (load) noticeable decreased but not increased) -> REOPENED

<richlv> updated manual according to the testing results (which imply that both escalator & history syncers are more efficient now)

<zalex> Reviewed. I like it, thanks. CLOSED

Available in version pre-1.9.9, r24046.

Just for case the last revision of trunk has been tested with big count of alerts (40 000). ALL IS FINE with the server.

Reopened to remove 2.0 from Fix versions and add some interesting results of my experiments.
<zalex> CLOSED

Reopened to add additional statistic requested by Sasha.
See attached "rev24046_improvement+DB_usage.png"