sticky acknowledgement lost on state change

766 views
Skip to first unread message

un...@gmx.at

unread,
Jun 11, 2012, 1:39:21 PM6/11/12
to th...@googlegroups.com

Hello,

I have noted a regression in Thruk after upgrading to 1.3x.
Acknowledgements seem to get lost on state changes (WARNING->CRITICAL,
DOWN->UNREACHABLE, ...).

Currently I'm using the Debian Squeeze package for 1.32 from thruk.org.

On submitting a host/svc acknowledgment via Thruk, the external command
sent to Nagios is:

[1339395054] EXTERNAL COMMAND:
ACKNOWLEDGE_SVC_PROBLEM;NE_RTR;NET_PING;1;0;1;thrukadmin;ok

Note that next to the service name NET_PING, the sticky option is set to
1. According to the nagios docs:

> If the "sticky" option is set to one (1), the acknowledgement will
> remain until
> the service returns to an OK state. Otherwise the acknowledgement
> will automatically
> be removed when the service changes state.

But in fact 1 seems not to be working.
If the service/host state changes the acknowledgement is lost.

Even the original Nagios CGI interface submits the external command by
setting the sticky option to 2. An example acknowledgment triggered from
the CGI interface:

[1339406866] EXTERNAL COMMAND:
ACKNOWLEDGE_SVC_PROBLEM;MMM_RTR;NET_VPN_GW;2;0;1;unki;route down

And I have verified that Thruk did this before too (an ack from
February with one of the 1.2x versions):

[1329134635] EXTERNAL COMMAND:
ACKNOWLEDGE_SVC_PROBLEM;VIE_WIN;WIN_SERVICES;2;1;0;thrukadmin;ok


The "2" is neverywhere documented in the Nagios documentation, but that
one seems to work.

For now I have adapted cmd_typ_33.tt and cmd_typ_34.tt and set line 16 to:

[% IF c.request.parameters.sticky_ack %][% sticky_ack = 2 %][% ELSE
%][% sticky_ack = 0 %][% END %]

By this the acknowledgements remain on state changes.

Best Regards,
Andreas

Vincent Besançon

unread,
Jun 11, 2012, 3:18:50 PM6/11/12
to th...@googlegroups.com
Hello unki,

Are you using Icinga instead of Nagios ? Because it seems sticky ack with code 2 comes from it...




--
Vincent Besançon
Follow me: Twitter or Google+
Email: besancon...@gmail.com

Andreas Unterkircher

unread,
Jun 11, 2012, 3:56:47 PM6/11/12
to th...@googlegroups.com, Vincent Besançon
Hi *Vincent,

It's *Nagios^Core^v3.2.3.
Looks like they forked this bug too :-)

Cheers,
Andreas

On 06/11/2012 09:18 PM, Vincent Besançon wrote:
> Hello unki,
>
> Are you using Icinga instead of Nagios ? Because it seems sticky ack
> with code 2 comes from it...
>
> http://docs.icinga.org/1.7/en/extcommands2.html
>
> 2012/6/11 <un...@gmx.at <mailto:un...@gmx.at>>
>
>
> Hello,
>
> I have noted a regression in Thruk after upgrading to 1.3x.
> Acknowledgements seem to get lost on state changes
> (WARNING->CRITICAL, DOWN->UNREACHABLE, ...).
>
> Currently I'm using the Debian Squeeze package for 1.32 from
> thruk.org <http://thruk.org>.
>
> On submitting a host/svc acknowledgment via Thruk, the external
> command sent to Nagios is:
>
> [1339395054] EXTERNAL COMMAND:
> ACKNOWLEDGE_SVC_PROBLEM;NE_RTR;NET_PING;1;0;1;thrukadmin;ok
>
> Note that next to the service name NET_PING, the sticky option is
> set to 1. According to the nagios docs:
>
> If the "sticky" option is set to one (1), the acknowledgement will
> remain until
> the service returns to an OK state. Otherwise the acknowledgement
> will automatically
> be removed when the service changes state.
>
>
> But in fact 1 seems not to be working.
> If the service/host state changes the acknowledgement is lost.
>
> Even the original Nagios CGI interface submits the external
> command by setting the sticky option to 2. An example
> acknowledgment triggered from the CGI interface:
>
> [1339406866] EXTERNAL COMMAND:
> ACKNOWLEDGE_SVC_PROBLEM;MMM_RTR;NET_VPN_GW;2;0;1;unki;route down
>
> And I have verified that Thruk did this before too (an ack from
> February with one of the 1.2x versions):
>
> [1329134635] EXTERNAL COMMAND:
> ACKNOWLEDGE_SVC_PROBLEM;VIE_WIN;WIN_SERVICES;2;1;0;thrukadmin;ok
>
>
> The "2" is neverywhere documented in the Nagios documentation, but
> that one seems to work.
>
> For now I have adapted cmd_typ_33.tt <http://cmd_typ_33.tt> and
> cmd_typ_34.tt <http://cmd_typ_34.tt> and set line 16 to:
>
> [% IF c.request.parameters.sticky_ack %][% sticky_ack = 2 %][%
> ELSE %][% sticky_ack = 0 %][% END %]
>
> By this the acknowledgements remain on state changes.
>
> Best Regards,
> Andreas
>
>
>
>
> --
> *Vincent Besançon*
> Follow me: Twitter <http://twitter.com/oldguru> or Google+
> <https://profiles.google.com/besancon.vincent/about>
> Email: besancon...@gmail.com <mailto:besancon...@gmail.com>
>

Sven Nierlein

unread,
Jun 11, 2012, 4:17:50 PM6/11/12
to th...@googlegroups.com
On 6/11/12 21:56, Andreas Unterkircher wrote:
> Hi *Vincent,
>
> It's *Nagios^Core^v3.2.3.
> Looks like they forked this bug too :-)

Hi,

Thanks for your report, i just checked the nagios source, it really has to be 2.
Fixed in git already:
https://github.com/sni/Thruk/commit/9076dc7d5875bd1aa23125ecbf443e9b415eaf41

Thanks,
Sven
Reply all
Reply to author
Forward
0 new messages