Frontend errors with pre-1.8.2.x rev. 10923

[simix]

I have two errors in the web frontend which are not present in 1.8.1.

Note: Both errors show up only when logged in as Admin, but not as other user or guest.

In the dashboard below "Last 20 issues" I see those errors:

* Invalid argument supplied for foreach()[/usr/share/zabbix/frontend-php/include/blocks.inc.php:719]
* Undefined index: [/usr/share/zabbix/frontend-php/include/blocks.inc.php:742]

I ws unable to figure out why it fails because it shows the last 20 issues fine.

The second problem is in when I show the triggers for group all / host all. I get the correct list of triggers but on the first line I can see a trigger which doesn't exist:

Average PROBLEM Never 40y 2m 3w Acknowledged *ERROR* Show

It seems that it tries to show a trigger which does not exist.

Both errors don't show up with 1.8.1 so it must have happened in the pre-1.8.2 series.

Regards,
Simon

[Aly]

For some unknown reason, this trigger is left out without an item (thats impossible situation in normal processing). The simplest way is just remove it manually from DB by triggerid.

[simix]

Sorry but I don't know how to delete the trigger in the DB.

I can see the triggerid in the link like this:

/zabbix/events.php?triggerid=12201&nav_time=0&sid=2427e2fd cb8f1aa5

So I expected we are talking about the triggers table where triggerid=12201
Unfortunately that seems to be wrong.

Where exactly is the bad trigger?

Thanks,
Simon

[Aly]

Yep we are talking about table triggers:

SELECT * FROM triggers WHERE triggerid=12201;

It should be there. Make shore that this is the trigger with wrong expression and then type:

DELETE FROM triggers WHERE triggerid=12201;

[simix]

I have checked this before but I don't see anything wrong with 12201:

12198,{11198}>1000,icmpOutTimeExcds on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12199,{11199}>0,icmpOutParmProbs on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12200,{11200}>0,icmpOutSrcQuenchs on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12201,{11201}>150000,icmpOutRedirects on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12202,{11202}>100,icmpOutEchos on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12203,{11203}>100,icmpOutEchoReps on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0
12204,{11204}>100,icmpOutTimestamps on {HOSTNAME} is too High,,0,1,3,0,0,20,,0,0

If something is wrong with 12201 why not with the others?

[simix]

OK, I have just deleted the row and now it seems to work.

Thanks,
Simon

[simix]

I have just checked data.sql and it looke like the trigger mentioned has been added by the initial database creation process:

INSERT INTO triggers VALUES (12201,'{11201}>150000','icmpOutRedirects on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12202,'{11202}>100','icmpOutEchos on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12203,'{11203}>100','icmpOutEchoReps on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12204,'{11204}>100','icmpOutTimestamps on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12205,'{11205}>100','icmpOutTimestampReps on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12206,'{11206}>100','icmpOutAddrMasks on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12207,'{11207}>100','icmpOutAddrMaskReps on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);
INSERT INTO triggers VALUES (12208,'{11208}>1000','icmpOutRedirects on {HOSTNAME} is too High','',0,1,3,0,0,' ','',0,0);


triggerid 12201 and 12208 look very similar. Is there an error in data.sql which should also be fixed when 1.8.2 gets released?

[dotelpenguin]

..adding this because it also solved my problem.

I had this same problem, tho I never noticed the weird trigger in the "recent triggers" (however it was there when I restored the db and tested).

I had the problem with viewing all triggers in the configuration screen. It would crash the front end with

Unsupported operand type in ...../include/triggers.inc.php on line 1537

Deleting the trigger from the database was also the solution.