No specific environments

This would be very handy for triggers that are triggered by logfiles etc.
At this moment it is very hard to keep an eye on noticed problems because new values tend to clear any triggers eventually, thereby removing these triggers from the dashboard. You have to actively search for related events if you want to keep an eye on this.

I would like the option that a certain trigger (configurable per trigger) can only be cleared from the webgui, preferably via a tick box in the acknowledge screen.

Ability to clear via API would be good as well.

A {TRIGGER.ACK} macro (a bit like the {TRIGGER.VALUE} macro) that could be used in the trigger expression could solve this for us.

It would need the trigger to be ACK before it can go to the OK state.

<normal trigger expression> | ({TRIGGER.VALUE}=1 & {TRIGGER.ACK}#1 )

Also see https://support.zabbix.com/browse/ZBXNEXT-645 and http://www.zabbix.com/forum/showthread.php?t=13088

Very usefull for me too.

I think this is a must-have missing feature, expecially for newcomers like me. Now, the simpler GUI way I've found to reset a log trigger is to disable and re-enable it....

I think it should not be too difficult to implement an optional tick box or a radio button in the acknowledge screen in order to reset a log (or eventlog) trigger.
This will also allow to automatically have a changed status with the related actions. Other feature requests (like ZBXNEXT-18 https://support.zabbix.com/browse/ZBXNEXT-18? Action => Acknowledgement Alerts) could be also related to it.

2011 and still waiting

I agree with the must have comment above. BTW if you google the text in this request it has been floating around for the last 3+ years

Open since October 2009...Can we get a status update on this one?

Очень ждем этого функционала!!!

2013 and still missing this very helpful feature...

The only work around I found so far is to run periodically (every 2 min) a script that update the "value field" of triggers table in zabbix database.

For mysql you can do it with the following query:

update triggers set value=0,error=''
where triggerid in (
select ee.objectid from events ee
inner join
(select objectid,MAX(eventid) as maxid
from events
group by objectid)
ee2 on ee.objectid=ee2.objectid and ee.eventid=ee2.maxid
where
ee.acknowledged=1 )
and value=1

So are we going to solve this anytime soon? I may have to do it myself.

Any solution?

affff feature request in 2011 Jul 13 15:50, and anybody resolve?

Bad suport! :s

Please, more priority to this one

Priority: Minor Minor

Crazy? resolve this problem sun!

please stop adding spammy comments. we will have to remove them.

solve it then!

Five years to be resolved!

i'm not fully sure i have an obligation towards you. if it is so, could you please provide more information on it ? i'd like to know.

richlv, I dont think is a solution to be sarcastic. As well, I dont think you have any obligation to anyone.

My personal feeling (I use Zabbix for about 1 year only) is there are lot of small issues which could be easily fixed but are not for a long time, which could be quite annoying and users are dissapointed waiting years for a fix... Of course, there is the voting for proposals as well...

1) i do believe that rudeness level in certain comments (3 of them) was too high;
2) this is not a proper place for such discussions - please, join us on irc (where there's plenty of such discussions, btw )
3) i agree with your statement about "annoying/disappointing", of course. but if those small issues would be tackled, something else would have to be excluded, and that would make somebody else sad. but... irc

while discussing about solving or not solving, this little solution could be resolved.
This is the big problem, is very discusses and resolves almost nothing. Forty people are following this problem. On the official forum, many people are looking for this solution and nothing is reported.

Paleativas are passed resolutions that simply do not solve all cases (.nodata).
I'm sorry if you think I'm creating spam, but once you begin to look at a problem that this unresolved five years, and that this means resolved (triger.ack).

Cya

(sorry bad inglês)

Hi Richards, I really dont want to spam this issue (feel free to delete this comment afterwords) - and being an open-source project owner myself I really understand how everybody can pressure the feature request yet not everybody wants to give a helping hand or cash I understand why this issue is low prio - as it does not block Zabbix usage and not many people report back then - yet I must say it is very annoying missing feature - which might/or might not be easy to implement (dont know in such details). It would actually improve the user experience a lot - and it feels kind of not so huge change implementation wise - so I hope you will give it another round of evaluation and consideration - if to raise the priority on this issue or not. I must say I have hoped for this feature for years now - yet it is also true that I have not made the patch or ordered the custom development - but still missing this simple feature a lot - and I really think it affects Zabbix user experience in a good way

Kind regards,
Andres from OpenNode

The willingness of people to pay money for a feature is the strongest indicator, that this feature is really needed.
Team up with other users to commonly sponsor implementation of this functionality

i guess i have to give up and we can use this issue for discussions

andres, i have a list of issues that annoy me heavily when using zabbix. HEAVILY. this one is not on that list, yet... so priorities for different users differ a lot
would i want this feature ? sure. it's a nice one. but look at the long lost of open issues and you will see that there are thousands of them.
while it may sound simple, almost all issues have initially unforeseen problems once we start to figure out what such a change would require. let me provide two examples...

a) changing default history period from 90 to 7 days. sounds extremely simple, right ? just change one number... well, first it would require major release, because it is also in the database schema. second, that value also affects for how long web scenarios keep historical data, and it can not be configured by user. so we would have to implement that functionality. see how one number change drags in extra feature ?
b) currently lowest 2 severities are ignored for it services. should be simple to fix, right ? just make them not ignored... turns out, trigger severity is stored as ok/problem state for it services. trigger severities start at 0, but in it services 0 means ok. to make this change we must change the way data is stored, provide database patch for users that upgrade... so this simple change again turns out to pull in unforeseen changes.

as for this specific one, see the link marc posted - this specific feature is now at the top of the list (thanks, sergey)

It is not a simple feature by any means. With all due respect, most of us do not understand all implications of this functionality since it affects core parts of Zabbix: triggers, events, actions, notifications; both server and front-end. That's why it is 4 years old and still not implemented. We need a good solution, which fits well into existing design, scalable and covers most of real-life use cases.

I think we are talking about two feature requests here:

1. Ability to switch a trigger to OK state manually by ACK

2. Ability to have triggers that (all individual problem events) can be switched to OK state only by ACK. Automatic OK events are prohibited.

I guess we have some good news. (1) is scheduled to be implemented in Zabbix 2.4. (2) is to be discussed, I hope it will also be implemented.

I think that the functionality is linked to ZBXNEXT-18, another one of the most requested features.

I'll keep you updated here.

ZBXNEXT-1629 could maybe be implemented along.

Alexei: Ack fully for the reasons behind that we dont see at first glance - but now I can understand these better when explained Actually now everybody can read it here and understand it perhaps - so I think its a positive thing (ie this discussion) and absolutely worth the effort!

Just in the unlikely case this might be achieved by something like 'virtual events', then this could possibly help with ZBXNEXT-97 too.

How can I reset the trigger status right now? Anybody knows?
Thanks

Did this get into 2.4 as I don't recall it mentioned as new feature - we need this, too, and if not in 2.4 our temp solution is to probably try this:

• Add field on trigger table if the trigger is latchable, i.e. can't be auto OKd
• Modify server to not issue an OK event if that field is set
• Thus the trigger will be OK by itself, but the event won't disappear from the dashboard
• Add a manual process to do what normal trigger does, to issue an OK event by either ACK or a separate menu/action
• We prefer a separate action for this, separate from ACK, but can be easily done via ACK
• One issue is how user knows to do this - trigger name has to specify this or has to be a color indication on dashboard that you need to manually clear since we change the dashboard anyway, we'll probably add a column or color to show this - we already have this for ACK and clearing zabbix-sender triggers anyway

Steve, If it would be included to 2.4 - it would be closed already.
So it's still not implemented.

I have version 2.4 and need this ability to reset a trigger to OK for windows events. This is an urgent requirement, please can someone from Zabbix let me know how to do this, we have just signed up to an Enterprise agreement and Im not going to deploy this to prod unless I can reset the windows events to OK as the majority of our monitoring is for our application that utilises the windows event logs.

Well,

i have looked into few comments and i think we are missing the point here.

The trigger is supposed to show the current status of an logical evaluation based on the values collected. If that trigger has been acknowledged, it could not be shown on the trigger list, if the filter is set to do so.. This already exists..

Maybe, the issue #ZBXNEXT-473 makes more sense. If we could force a new check on a resolved but not yet refreshed item, the trigger would return to OK state (depending on data collected, of course). I imagine that forcing a new check over active items would be a little trickier, although could still be done.

fpaternot, from my point of view the main driver is to have an option to somehow "reset" a trigger, or send an virtual OK event, for triggers based on items that don't necessarily get values regularly. That's e.g. often the case for event driven items like log items or traps.

Marc, i see. Items that Zabbix get the 'error state' but they do not notify (or take too long) to send an 'ok state'. I dont see this situation very often on my day-buy-day activity, however after reading every single comment, i think its a great feature if we could somehow use a macro inside that trigger to evaluate the acknowledge status.

I'm not a fan at all if this would become the standard behaviour, but it we could use this inside the trigger, it could turn out to be quite useful for many people.

When using a macro is meant to be used in a way that a trigger expression is only TRUE, if the corresponding event is not acknowledged, then this might not help in every case.
E.g. for triggers having exclusively non time based trigger functions. As long as the referenced items don't get any data, the trigger expression will not be re-evaluated.

Yes you`re right, a trigger is only evaluated when new item data comes in.

Guys, see my comment from 2011 May 04 10:57, we can indeed use a trigger ack macro for this.
For instance, using hysteresis this expression would allow a trigger to activate on an incoming event and only deactivate on a trigger ack.

({Host:item.nodata(60)}#1 & ({TRIGGER.VALUE}=0) |  ({TRIGGER.VALUE}=1 & {TRIGGER.ACK}#1)

It seems that enabling TIGGERS.ACK macro on 'trigger expression level' could do the trick.
Would that be difficult to implement? This is really cool feature, one that would be extremely useful for us.

Patch against 2.4.3, adding support for TRIGGER.ACK

works fine it schemas like

{host:item.change()}<>0 or ({TRIGGER.VALUE}=1 and {TRIGGER.ACK}=0)

about 104.patch file

sql currently doesn't use indexes so it might be slow,
I need to figure how get source and object id's for a given event this will improve sql query performance
(it will use events_1 index)

Maybe it's not a cleanest approach but it works, when it will use indexes performance impact should be neglectable
(it's evaluated only on triggers using TRIGGER.ACK macro)

queries from https://support.zabbix.com/browse/ZBX-4357

aren't using indexes

mysql> explain select count(*) from events where object=0 and objectid=13141 and value in (1,0) and acknowledged=0\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 25
        Extra: Using where
1 row in set (0.00 sec)

mine will

mysql> explain select * from events where source=0 and object=0 and objectid=13557 and clock=1421166380\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
         type: ref
possible_keys: events_1,events_2
          key: events_1
      key_len: 20
          ref: const,const,const,const
         rows: 1
        Extra: 
1 row in set (0.00 sec)

I will also change the syntax to TRIGGER.EVENTS.ACK to be more consistent with other parts of zabbix.

Does anyone still care about this ?

Is zabbix team interested in merging this feature if we manage toresolve issues (performance, better gui integration, naming) ?

Yes I still care about this and would be great to get it working.

Same here. This feature would optimize our workflow greatly.

I think I have fixed the performance issue, now the query is using an index.

I have moved the sources to github

https://github.com/lazy404/zabbix/wiki
https://github.com/lazy404/zabbix/tree/trigger.ack

so basically

wget https://github.com/lazy404/zabbix/archive/trigger.ack.zip

unzip trigger.ack.zip

./configure ....

+1 from me

Hi,

Did anyone test the patched version ?
Did it work for You ?

I really like to have this feature implemented since logfile monitoring without the ability to reset a trigger is basically useless when one greps for "ERROR" in a logfile and the string ERROR only pops up once a day or even less frequent keeping the alarm up for all eternity.

Max feel free to check my https://github.com/lazy404/zabbix/archive/trigger.ack.zip branch (based on latest 2.4 release).

I have contacted zabbix devs and this issue isn't on the roadmap, so I don't expect it to be merged anytime soon.
I guess If You have comercial support contract You can nag them about this.

This patch is almost trivial and small under 50 lines of code, i don't think it whould take long to merge it or find problems if there are any.

Hey Michal,

thanks for the patch, but it will take some time 'till we either update to 2.4 or test/port the patch to our current installed v 2.2.5.
Since we're on a SLES 11 ppc64 I guess I have to check if we can meet all the build dependencies needed by zabbix-server. Somewhere in the back of my head I remember that there were some problems with that.

Sadly, we have no commercial support subscription :/.

Until then, I configured an action that will execute a zabbix-sender which again will send "0" to the Item to reset the Trigger after 5 minutes.
I thought I could use the "Event Acknowledge = ACK" function in this action to have it depend on the acknoledged status of the event, but this does seem broken as well... . So there is just a fixed 5 minutes timer and then it will reset the trigger by flooding the recorded log senseless "logentries".

Actually, i just pimped my workaround to have the fake "log-entries" to be deleted once the trigger was "reset".
It's not that easy, it only works if you have setup a CLI sql client on a host with connectivity to your zabbix-server's database and it's propably not secure as plani text passwords get stored in your GUI - I recommend not doing this in a production environment:

My reset-action, only triggered by the trigger to be reset:

where step 1 is basically a NULL action only to delay step 2

Step 2 fires the following remote command to a machine with set-up ODBC:

user=<zabbix-database-user>
password=<zabbix-database-password>

for times in {1..5} ; do 
  zabbix-sender -z <zabbix-server> -p <zabbix-trapper-port> -s <source-system-with-logfile> -k '<key-to-logfile-on-server>' -o '---Zabbix-Problem-Ack-Marker---'
done
sleep 60 #delay to give zabbix time reset trigger
echo 'delete from history_log where value = "---Zabbix-Problem-Ack-Marker---" AND itemid = '<itemid>' ;' | isql -b -d" " ODBC-connection $user $password #delete prev. false "logentries".

If you can live wit false logentries in your historical data, better skip the delete statement - it probably messes with your zabbix database and i'll watch this on a test system for a long while now. Hope this dirty trick will help someone who cant apply Michals test like me.

The times

will have to be modifed depending on how many logentries your triggers looks in the past. Mine checks the last 5 entries so i'll have to send him 5 logentries wich do not match the triggers expression.

Just FYI: If someone would want to just update trigger.value=0 in database - it will not work because the trigger.value is stored in configuration cache and zabbix server re-uses it.
https://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew200#trigger_cache

Here is my test on 2.4.3
PROBLEM value (77) sent:

 14823:20150211:121033.728 In evaluate() expression:'77>5'
 14823:20150211:121033.728 End of evaluate() value:1.000000
 14823:20150211:121033.728 End of evaluate_expressions()
 14823:20150211:121033.728 In process_triggers() values_num:1
 14823:20150211:121033.728 In process_trigger() triggerid:13575 value:0(0) new_value:1
 14823:20150211:121033.728 End of process_trigger():SUCCEED
 14823:20150211:121033.728 query [txnlev:1] [update triggers set lastchange=1423649429,value=1 where triggerid=13575;]
 14823:20150211:121033.729 End of process_triggers()
 14823:20150211:121033.729 End of DCmass_update_triggers()
 14823:20150211:121033.729 In DCmass_update_trends()
 14823:20150211:121033.729 End of DCmass_update_trends()
 14823:20150211:121033.729 In DCflush_nextchecks() nextcheck_num:0
 14823:20150211:121033.729 End of DCflush_nextchecks()
 14823:20150211:121033.729 In process_events() events_num:1
 14823:20150211:121033.729 In DCget_nextid() table:'events' num:1
 14823:20150211:121033.729 query [txnlev:1] [select max(eventid) from events where eventid between 0 and 9223372036854775807]
 14823:20150211:121033.729 End of DCget_nextid() table:'events' [266:266]
 14823:20150211:121033.729 query [txnlev:1] [insert into events (eventid,source,object,objectid,clock,ns,value) values (266,0,0,13575,1423649429,952917432,1);]

manually executed:

mysql> UPDATE triggers SET value=0 WHERE triggerid=13575;
Query OK, 1 row affected (0.01 sec)

PROBLEM value (6667) sent again:

 14823:20150211:121103.755 In evaluate() expression:'6667>5'
 14823:20150211:121103.755 End of evaluate() value:1.000000
 14823:20150211:121103.755 End of evaluate_expressions()
 14823:20150211:121103.755 In process_triggers() values_num:1
 14823:20150211:121103.755 In process_trigger() triggerid:13575 value:1(0) new_value:1
 14823:20150211:121103.755 End of process_trigger():FAIL
 14823:20150211:121103.755 End of process_triggers()
 14823:20150211:121103.755 End of DCmass_update_triggers()
 14823:20150211:121103.755 In DCmass_update_trends()
 14823:20150211:121103.755 End of DCmass_update_trends()
 14823:20150211:121103.755 In DCflush_nextchecks() nextcheck_num:0
 14823:20150211:121103.755 End of DCflush_nextchecks()
 14823:20150211:121103.755 In process_events() events_num:0
 14823:20150211:121103.755 End of process_events()

OK value (2) sent:

 14823:20150211:121123.784 In evaluate() expression:'2>5'
 14823:20150211:121123.784 End of evaluate() value:0.000000
 14823:20150211:121123.784 End of evaluate_expressions()
 14823:20150211:121123.784 In process_triggers() values_num:1
 14823:20150211:121123.784 In process_trigger() triggerid:13575 value:1(0) new_value:0
 14823:20150211:121123.784 End of process_trigger():SUCCEED
 14823:20150211:121123.784 query [txnlev:1] [update triggers set lastchange=1423649479,value=0 where triggerid=13575;]
 14823:20150211:121123.785 End of process_triggers()
 14823:20150211:121123.785 End of DCmass_update_triggers()
 14823:20150211:121123.785 In DCmass_update_trends()
 14823:20150211:121123.785 End of DCmass_update_trends()
 14823:20150211:121123.785 In DCflush_nextchecks() nextcheck_num:0
 14823:20150211:121123.785 End of DCflush_nextchecks()
 14823:20150211:121123.785 In process_events() events_num:1
 14823:20150211:121123.785 In DCget_nextid() table:'events' num:1
 14823:20150211:121123.785 End of DCget_nextid() table:'events' [267:267]
 14823:20150211:121123.785 query [txnlev:1] [insert into events (eventid,source,object,objectid,clock,ns,value) values (267,0,0,13575,1423649479,752742380,0);]

Configuration cache update after the SQL - doesn't provide any effect.

dbconfig.c:

/******************************************************************************
 *                                                                            *
 * Function: DCconfig_set_trigger_value                                       *
 *                                                                            *
 * Purpose: set trigger value, value flags, and error                         *
 *                                                                            *
 * Author: Aleksandrs Saveljevs                                               *
 *                                                                            *
 ******************************************************************************/
void	DCconfig_set_trigger_value(zbx_uint64_t triggerid, unsigned char value,
		unsigned char state, const char *error, int *lastchange)
{
	ZBX_DC_TRIGGER	*dc_trigger;

	LOCK_CACHE;

	if (NULL != (dc_trigger = zbx_hashset_search(&config->triggers, &triggerid)))
	{
		DCstrpool_replace(1, &dc_trigger->error, error);
		dc_trigger->value = value;
		dc_trigger->state = state;
		if (NULL != lastchange)
			dc_trigger->lastchange = *lastchange;
	}

	UNLOCK_CACHE;
}

you could offer a timer as well to have a automatic resubmission if the problem had not been resolved by this time...

plexus, you're possibly interested in ZBXNEXT-1687 as well.

Edit:
After re-reading ZBXNEXT-1687 actually completely unrelated - Sorry for the noise

After some consideration I believe this request should be changed somewhat.
The intended workflow as I understand is that upon noticing a new problem an operator would acknowledge to indicate they are working on it.
This is different and should be kept separate to clearing the Problem status of a trigger.
To meet the requirement discussed here a "Clear" function under the trigger popup menu where "Events" and "Configuration" are would serve us better and may be easier to implement.

Hello!

I have a log trigger that needs to be acknowledged every time that is triggered. I upgraded my zabbix server to 2.4.3 and I added the acknowledge verification(TRIGGER.ACK=0) in my trigger expression. I'm using the AND(E) operand. But my problem wasn't solved, it triggers every time yet. How can I configure my trigger to this feature works?

Thanks,

Leonardo

Leonardo, the {TRIGGER.ACK} macro is not officially supported, it can work only if apply the patch, see discussion above.

Oleksiy, I applied it. I forgot talking about it.

After install trigger ack...

Item:

log["/tmp/teste.txt","ERRO1"]

Trigger:

{hostname:log["/tmp/teste.txt","ERRO1"].str(ERRO1)}=1 >>Trigger OK
{hostname:log["/tmp/teste.txt","ERRO1"].str(ERRO1)}=1 or ({TRIGGER.ACK}=0) >> Trigger 
error with status unknown:

This error appears in dashboard.

Invalid expression [{17469}=1 or ({TRIGGER.ACK}=0)]

Someone could use this "trigger.ack"?

Did you follow the instructions on

https://github.com/lazy404/zabbix/wiki ?

and are sure that You are running a patched version ?

TRIGGER.ACK should be visible in the gui along with TRIGGER.VALUE

Yap Michael.

I go to "Expression constructor" in trigger click in "insert expression" and open 4 options, after apply patch, open only 2 options.

But don't work for me.

don't use the patch it's outdated,

please use https://github.com/lazy404/zabbix/archive/trigger.ack.zip instead

I use this patch Michal.

Zabbix 2.4.3 Copyright 2001-2014 by Zabbix SIA, ZE 2.1.2

Gratz

If You want to use my

patch you have to use the sources from
https://github.com/lazy404/zabbix/archive/trigger.ack.zip

just as described at https://github.com/lazy404/zabbix/wiki

Michal.

I am work with zabbix 2.2.4, update to zabbix 2.4.4, and execute your patch. (https://github.com/lazy404/zabbix/archive/trigger.ack.zip)

Maybe my error is dont execute patch overwrite build.

Guys, use please zabbix forum or IRC to discuss patching related questions, thanks.
Here is not the best place to discuss such things.

Hello,

Could you update the status ? Are you plan to implement it in v3.0.x ?

There was comment by Alexei Vladishev at 2014 Jan 23 16:48 : " ...I guess we have some good news. (1) is scheduled to be implemented in Zabbix 2.4. (2) is to be discussed, I hope it will also be implemented. ..."

Thanks!
Natalia

bump

please see http://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue

I have some good news for all of us. The functionality will be implemented in 3.2 as ability to close problems manually from the UI. Also it will be possible to configure on trigger level if it's allowed to close problems manually or not.

Nice!

Thanks Alexei! This is really a good news!

(1) Database patch ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-104

sasha Successfully tested! CLOSED

Server side ready for testing.

(2) [I] data.tmpl

• new items are not assigned to application Zabbix server
• new triggers Zabbix task manager processes more than 75% busy are not created
• we doesn't use 00A000 color; may be 009900?
• all existing triggers with hysteresis will be rewritten using recovery expression.

wiper RESOLVED in r61483, r61488

sasha CLOSED

(3) [IS] problem.userid must be added into a database.

wiper Database schema and patch done in r61490

wiper Added problem.userid handling. Also fixed closing of single event when multiple problem events from the same trigger are open.
RESOLVED in r61495,r61509

sasha CLOSED

(4) [S] Template linkage ignore values of these fields: trigger.correlation_mode, trigger.correlation_tag and trigger.manual_close

Related to ZBXNEXT-3274.

wiper RESOLVED in r61515

sasha CLOSED

(5) Translation string changes

Strings added:

• Allow manual close
• CLOSING
• Cannot close problem: %1$s.
• Close problem
• User action
• event is not in PROBLEM state
• trigger does not allow manual closing

gunarspujats CLOSED

(6) [A] New read-write attribute manual_close for trigger and trigger prototype methods create, update and get. Read-only for templated triggers and discovered triggers.

RESOLVED in r61467

iivs CLOSED

(7) [S] Task manager should process tasks every 5 seconds. I.e. pause between checks should be calculated by the same way as in timer processes.

wiper RESOLVED in r61512

sasha CLOSED with small improvements in 61529.

wiper Reviewed, added process title updates before entering main loop.
REOPENED and RESOLVED in r61530

sasha Thanks! CLOSED

(8) [A] XML import/export.
XML format should be extended to include information about new trigger and trigger prototype attribute manual_close.

RESOLVED in r61473

iivs CLOSED

(9) I think the time has come!

src/zabbix_server/taskmanager/taskmanager.c

/* TODO: set problem_count to 0 after merging in 3274-3 changes */
diff->problem_count = 1;

wiper RESOLVED in r61509

sasha CLOSED

(10) [A] New read-write attribute action for method event.acknowledge.

RESOLVED in r61506

iivs CLOSED

(11) [S] Have a look at my changes in r61524.

wiper Thanks. CLOSED

(12) Uninitialized variables:

task manager

==25017== Conditional jump or move depends on uninitialised value(s)
==25017==    at 0x41885D: update_correlated_trigger_problem_count (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x418A21: update_trigger_changes (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x419287: process_trigger_events (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F5E4: tm_execute_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F80B: tm_try_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F8F5: tm_process_tasks (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43FA72: taskmanager_thread (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x48CC80: zbx_thread_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x41B738: MAIN_ZABBIX_ENTRY (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x48B636: daemon_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x41AE6C: main (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017== 
==25017== Conditional jump or move depends on uninitialised value(s)
==25017==    at 0x418C12: update_trigger_changes (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x419287: process_trigger_events (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F5E4: tm_execute_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F80B: tm_try_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43F8F5: tm_process_tasks (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x43FA72: taskmanager_thread (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x48CC80: zbx_thread_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x41B738: MAIN_ZABBIX_ENTRY (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x48B636: daemon_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)
==25017==    by 0x41AE6C: main (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server)

wiper RESOLVED in r61537

sasha CLOSED with small fix in r61540.

(13) [A] Please see my changes in r61538

gunarspujats OK thanks!
Please see my changes in r61568

iivs Thanks!
CLOSED

(14) [F] CLOSING state is not displayed while server close a problem.

iivs RESOLVED in r61552

gunarspujats CLOSED

(15) [F] This message must be printed for OK event. Not for PROBLEM.

iivs RESOLVED in r61563

gunarspujats CLOSED

(17) [S] "Manual close" operation closes triggers regardless of quantity of open problems

wiper RESOLVED in r61542

sasha CLOSED

Server side was successfully tested!

(18) [F] checkbox 'Close problem' not disabled in acknowledgement form , if problem closed by a trigger and in state Resolved
Steps to reproduce:
1. Create a trigger with flag 'Allow manual close'
2. Make a trigger in problem state
3. Make a trigger in OK state
4. Go to Monitoring→Problems and open acknowledgement form
Result: checkbox 'Close problem' not disabled

iivs RESOLVED in r61578

natalja.zabbix ui successfully tested

gunarspujats CLOSED

(18) [S] Server crash when processing event correlation rules.
RESOLVED in r61561

sasha CLOSED

(20) [F] problem not closed manually when in first acknowledgement checked "Close problem" and selected "Selected and all unacknowledged PROBLEM events" or "Selected and all unacknowledged events"

iivs RESOLVED in r61585

gunarspujats CLOSED

(21) Resolved merge conflicts from trunk. Please review r61592

gunarspujats Reviewed, fixed dbupgrade error in r61596

iivs Thanks!
CLOSED

Implemented in pre-3.2.0alpha2 (trunk) r61598

(22) [S] Use of uninitialized variable when task is not ZBX_TM_TASK_CLOSE_PROBLEM, see CID 152048.

** CID 152048:  Uninitialized variables  (UNINIT)
/src/zabbix_server/taskmanager/taskmanager.c: 198 in tm_process_tasks()


________________________________________________________________________________________________________
*** CID 152048:  Uninitialized variables  (UNINIT)
/src/zabbix_server/taskmanager/taskmanager.c: 198 in tm_process_tasks()
192     		{
193     			case ZBX_TM_TASK_CLOSE_PROBLEM:
194     				ret = tm_try_task_close_problem(taskid);
195     				break;
196     		}
197     
>>>     CID 152048:  Uninitialized variables  (UNINIT)
>>>     Using uninitialized value "ret".
198     		if (FAIL != ret)
199     			processed_num++;
200     	}
201     	DBfree_result(result);
202     
203     	return 0;

wiper RESOLVED in r61601.

sandis.neilands CLOSED.

(23) [S] CID 152047: looks like sleeptime reset calculation is not working as intended, please take a look.

** CID 152047:  Control flow issues  (DEADCODE)
/src/zabbix_server/taskmanager/taskmanager.c: 225 in taskmanager_thread()


________________________________________________________________________________________________________
*** CID 152047:  Control flow issues  (DEADCODE)
/src/zabbix_server/taskmanager/taskmanager.c: 225 in taskmanager_thread()
219     	DBconnect(ZBX_DB_CONNECT_NORMAL);
220     
221     	sec1 = zbx_time();
222     	sec2 = sec1;
223     
224     	if (0 == (sleeptime = ZBX_TASKMANAGER_TIMEOUT - (int)sec1 % ZBX_TASKMANAGER_TIMEOUT))
>>>     CID 152047:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach this statement: "sleeptime = 5;".
225     		sleeptime = ZBX_TASKMANAGER_TIMEOUT;
226     
227     	zbx_setproctitle("%s [started, idle %d sec]", get_process_type_string(process_type), sleeptime);
228     
229     	for (;;)
230     	{

wiper RESOLVED in r61601.

sandis.neilands CLOSED.

(24) [D] API documentation needs to be updated

gunarspujats Updated API documentation:

• https://www.zabbix.com/documentation/3.2/manual/api/changes_3.0_-_3.2#event
• https://www.zabbix.com/documentation/3.2/manual/api/changes_3.0_-_3.2#trigger
• https://www.zabbix.com/documentation/3.2/manual/api/changes_3.0_-_3.2#triggerprototype

iivs The given information is not enough for API changelog. New fields should be also described in methods. Import/Export examples should be updated. The order of issues is also wrong and too many methods are mentioned in the changes.

REOPENED

gunarspujats Updated api changes, also updated following API documentation:

• https://www.zabbix.com/documentation/3.2/manual/api/reference/configuration/export
• https://www.zabbix.com/documentation/3.2/manual/api/reference/configuration/import
• https://www.zabbix.com/documentation/3.2/manual/api/reference/event/acknowledge
• https://www.zabbix.com/documentation/3.2/manual/api/reference/trigger/object#trigger
• https://www.zabbix.com/documentation/3.2/manual/api/reference/trigger/get
• https://www.zabbix.com/documentation/3.2/manual/api/reference/triggerprototype/object#trigger_prototype
• https://www.zabbix.com/documentation/3.2/manual/api/reference/triggerprototype/get

iivs Outdated and incorrect examples updated:

• configuration.export 3.0, 3.2, 3.4
• configuration.import 3.0, 3.2, 3.4
• triggerprototype.get 3.2, 3.4

Please, review.
RESOLVED

sasha Looks good to me. CLOSED

Hello, this change affects this new version 3.2?

i am wait.

Edited.
Sorry, http://www.zabbix.com/whats_new.php

Great i am update now

GREAT... function working perfectly...

Thx

Am I missing something or is it possible to close a trigger / problem for a specified time?
Because if I close a problem like "Agent down" based on "agent.ping" it will reappear the second zabbix gets new data/ the function will be checked again.

alauer, now is not possible to close problem for a specified time.

Existing functionality is very usable to close problems, generated by triggers with disabled OK events (OK event generation = None).

(26) [D] Documented in:

• What's new in Zabbix 3.2
• Manual closing of problems

sasha Perfect! CLOSED