Zabbix 2.2.4 on CentOS 6.4

confirming in trunk r47042.
this happens because all checks are deleted and re-added whenever discovery rule is edited,

RESOLVED in development branch svn://svn.zabbix.com/branches/dev/ZBX-8430 r47297.

Thanks a lot for the quick solution !!!
I never installed patches in Zabbix, could you send me the details what should I do in order to implement this fix on my Zabbix 2.2.4 (CentOS 6.4)?

I defined SVN to update from svn://svn.zabbix.com/branches/dev/ZBX-8430, but it bring all the sources and not only the fix.
Should I compile all the sources and replace my zabbix exe files ?

Thanks for the help!

first, the fix has not been fully tested and reviewed yet;
second, this does not involve any windows exe files, it's purely zabbix frontend side - you can just check out frontend only, place it in a separate directory and test it without touching your existing frontend

(1) Such string comparison with 'new' shouldn't be on API level, but in frontend. Frontend should unset 'dcheckid' if it is new, but in API we should check not 'druleid', like it was before, but 'dcheckid'.

andrewtch Right, RESOLVED in r47357.

iivs Good, but let's fix coding style.

• CDrule.php: 541 "else" should be on new line;
• discoveryconf.php: 122 let's use strict string comparison there.

REOPENED.

andrewtch RESOLVED in r47400.

iivs CLOSED.

(2) We discussed this and decided to fix another problem in this issue.
Deleting a discovery check removes it from action condition, which is correct. But deleting a whole discovery rule, action condition remains with value "unknown".

andrewtch RESOLVED in r47402.

iivs

1. It's better to do update actions and delete conditions only once. Now if I have both drules and dchecks, update and delete will happen twice. We sould do this once;
2. Having an interger type DB column, we should use dbConditionInt();
3. Please add table aliases in queries;
4. The 'ORDER BY actionid' parts don't play any role and can be removed;
5. Coding style -> CDrule.php: 619 indentation is missing before ' AND '.dbConditionString('value', $checkIds).

REOPENED.

andrewtch

1. WONTFIX. In this case we should support three situations: 1) only "Discovery rule" actions are matched, 2) only "Discovery check" items are matched and 3) both "Discovery rule" and "Discovery checks" are matched. This would result in complex logic building SQL query (since we do not use any query builder).
2. RESOLVED
3. RESOLVED
4. RESOLVED
5. RESOLVED

RESOLVED in r47498, r47534.

iivs Few more things:

1. Let's add "ORDER BY c.conditionid" to prevent possible deadlocks;

2. DB::delete('conditions', array(
   	'conditionid' => $conditionIds
   )); 

   Let's write this in one line, since there are not too many parameters and it fits.

REOPENED.

iivs Would be better if comment was added why nothing has been changed here since last reopening of this subissue.

CLOSED.

andrewtch Generally, we should not do such tricks while calling Db::update / Db:delete since these functions are sorting id's internally.

Hi,

I find another problem in 2.2.4,

doesn't work if you define in CONFIGURATION->Actions->Discovery conditions:

Received value like test1
and
Received value like test2

work only if you define "OR" or using different type,for example "Received value" and "Discovery check"

Could you check this as well ?

Thanks

Natalia, how do you expect two "Received value like %something%" to work with "AND"? This is the same as asserting that X = 1 AND X = 10, which is a bit impossible.

my "Received value" is text,

for example, the output : centos,jboss,qa

so I create action :

Received value like jboss,
and
Received value like qa

the operation : Add to "QA Jboss" host group

please report that as a separate issue, thanks

done, ZBX-8480

Thanks !

TESTED

CLOSED. Fixed in pre-2.3.3 r47634.

(6) Please note this in the API changelog.

andrewtch RESOLVED, please see https://www.zabbix.com/documentation/2.4/manual/api/changes_2.2_-_2.4#drule

sasha REOPENED

"and/or drules" should be removed. We didn't fix it under the issue.

andrewtch RESOLVED, please check now.

sasha Thanks. CLOSED

Fixed in pre-2.3.4 (trunk) r47901.