nagios-devel — Developers List

[Nagios-devel] NRPE and NMAP problems

[Simon D. <sim...@gm...>]

Hi all,

I'm having some problems with NMAP scanning my NRPE servers [1]. It
turned out I'm not alone and someone also sent a patch that was
unfortunately never integrated [2]. I tested the patch from this thread
and it indeed fixes the issue.

I've attached a refreshed patch against 2.14 and would really appreciate
if it could be included by someone with commit access.

Best regards,
Simon

1: https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1126890
2: http://comments.gmane.org/gmane.network.nagios.devel/6774

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Ton V. <ton...@op...>]

On 9 Apr 2013, at 19:35, Andreas Ericsson wrote:

> On 04/08/2013 02:12 PM, Ton Voon wrote:
>> 
>> RHEL5 32 bit:
>> long = 4
>> time_t = 4
>> tv = 8
>> pqueue_pri_t = 8
>> 
>> 
>> RHEL5 64 bit:
>> long = 8
>> time_t = 8
>> tv = 16
>> pqueue_pri_t = 8
>> 
> 
> Ah. Obviously. We're truncating 16 bytes down to 8 for priority,
> checking, but retain the 16 bytes to check if it's time to actually
> run the event yet, so we hang in the event execution loop when
> we come across such events.
> 
> I've committed a fix which will allow events to be scheduled
> until year 141166 for 64-bit systems (43 bits). It's not
> possible to extend the time for 32-bit systems, so if you think
> you managed to schedule things beyond year 2038, you were wrong.
> 
> That last point is sort of important though. It's still possible
> to schedule things that appear to be far into the future that
> actually run straight away. We can't do anything about that, because
> in lib/squeue we can't differ between "far in the past" or "far into
> the future", since the value is already wrapped when we get it there.

It appears that in Nagios 3, if you schedule a downtime to end in the year 2113 on a 32 bit system, it is silently ignored and no downtime is marked. I think that's reasonable - someone will just schedule again with better values. This happens on a 32 bit system in Nagios 4 too.

If you schedule downtime on a 64 bit system in 2113 on Nagios 3, then it is accepted.

So what happened was that some downtime was set in 2113 in Nagios 3, and then when Nagios 4 read the accepted value in retention.dat, it triggered this event queue error.

I guess you could get strange values if you transitioned from a 64 bit system to a 32 bit system, but that would be unlikely.

> We will not, however, stop running events anymore.

I've just tried to recreate the error and your fix allows the event queue to continue, so I can confirm this is fine now.

Ton

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Andreas E. <ae...@op...>]

On 04/08/2013 02:12 PM, Ton Voon wrote:
>
> On 4 Apr 2013, at 22:55, Andreas Ericsson wrote:
>>> This fails on CentOS 5 64bit, though appears to work on Debian Squeeze 32bit, so it maybe a 64 bit only issue.
>>>
>>> We think this is an issue when the event is scheduled via squeue_add(). We've managed to get the test-squeue to fail by changing the time value to be greater than 2038 with the following:
>>>
>>> Index: test-squeue.c
>>> ===================================================================
>>> --- test-squeue.c	(revision 2716)
>>> +++ test-squeue.c	(working copy)
>>> @@ -116,7 +116,7 @@
>>>   	sq_test_random(sq);
>>>   	t(squeue_size(sq) == 0, "Size should be 0 after first sq_test_random");
>>>
>>> -	t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
>>> +	t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
>>>   	t(squeue_size(sq) == 1);
>>>   	t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
>>>   	t(squeue_size(sq) == 2);
>>>
>>> This gives the test result of:
>>>
>>> ### squeue tests
>>>    FAIL max <= *d @test-squeue.c:86
>>>    FAIL x == &b @test-squeue.c:133
>>>    FAIL x->id == b.id @test-squeue.c:134
>>>    FAIL x == &c @test-squeue.c:141
>>> about to fail pretty fucking hard...
>>> ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x: 0xbfde9b80
>>>    FAIL x == &b @test-squeue.c:152
>>>    FAIL x->id == b.id @test-squeue.c:153
>>>    FAIL x == &b @test-squeue.c:160
>>>    FAIL x->id == b.id @test-squeue.c:161
>>>    FAIL x == &c @test-squeue.c:166
>>>    FAIL x->id == c.id @test-squeue.c:167
>>> Test results: 390637 passed, 10 failed
>>>
>>> Changing to a factor of 1.1 instead of 2 passes:
>>>
>>
>> I'm not surprised. 1.1 would mean it's still within the unix timeframe.
>>
>> What's the size of time_t, long and struct timeval on systems where it
>> fails?
>> What's the sizes on systems where it succeeds?
>
> With the recreation steps, Nagios 4 works fine on rhel5 32bit, but fails on rhel5 64bit.
>
> sizes.c:
>
> #include <string.h>
> #include <stdio.h>
> #include <assert.h>
> #include <sys/types.h>
> #include <signal.h>
> #include <unistd.h>
> #include <sys/time.h>
> #include "pqueue.h"
>
> int main(int argc, char **argv)
> {
>      struct timeval tv;
>
>      printf("long = %d\n", sizeof(long));
>      printf("time_t = %d\n", sizeof(time_t));
>      printf("tv = %d\n", sizeof(tv));
>      printf("pqueue_pri_t = %d\n", sizeof(pqueue_pri_t));
>      return 0;
>
> }
>
> RHEL5 32 bit:
> long = 4
> time_t = 4
> tv = 8
> pqueue_pri_t = 8
>
>
> RHEL5 64 bit:
> long = 8
> time_t = 8
> tv = 16
> pqueue_pri_t = 8
>

Ah. Obviously. We're truncating 16 bytes down to 8 for priority,
checking, but retain the 16 bytes to check if it's time to actually
run the event yet, so we hang in the event execution loop when
we come across such events.

I've committed a fix which will allow events to be scheduled
until year 141166 for 64-bit systems (43 bits). It's not
possible to extend the time for 32-bit systems, so if you think
you managed to schedule things beyond year 2038, you were wrong.

That last point is sort of important though. It's still possible
to schedule things that appear to be far into the future that
actually run straight away. We can't do anything about that, because
in lib/squeue we can't differ between "far in the past" or "far into
the future", since the value is already wrapped when we get it there.

That means it's considered buggy user-behaviour to try to schedule
things beyond year 2038 on 32-bit systems. We won't support it, ever,
because we can't. It's also considered a buggy user-behaviour to try
to schedule things beyond year 141166 on 64-bit systems. Both actions
will result in "undefined behaviour", which means we'll run the event
whenever the truncated value happens to suggest it should be run (so
it's actually pretty well-defined behaviour but will be hard for users
to verify).

We will not, however, stop running events anymore.

>>
>> Well, modifying the evt_compute_pri() algorithm to discard
>> everything but the 21 least significant bits of the tv->tv_usec
>> would allow us to use 43 bits for the seconds value. That would
>> land us somewhere in the year 141234 before we run out of seconds.
>> It's not a real fix though, since we could live with discarding
>> events that are patently absurd, but blocking the entire scheduler
>> because we get a bogus date is just plain wrong.
>
> I've changed the code so it now looks like this:
>
> static pqueue_pri_t evt_compute_pri(struct timeval *tv)
> {
>          pqueue_pri_t ret;
>
>          /* keep weird compilers on 32-bit systems from doing wrong */
>          if(sizeof(pqueue_pri_t) < 8) {
>                  ret = tv->tv_sec;
>                  ret += !!tv->tv_usec;
>          } else {
>                  ret = (pqueue_pri_t) tv->tv_sec;
>                  ret <<= 43;
>                  ret |= (tv->tv_usec & 0x1FFFFF);
>          }
>
>          return ret;
> }
>
> For the same recreation steps, the event queue is now working properly.
>

No it's not. you just removed the 11 most significant bits of the
priority, so what you think is scheduled 30 years into the future is
in reality scheduled to run sometime within the next 24 days. The fix
I proposed was to change it to

   ret <<= 21;
   ret |= tv->tv_usec & ((1 << 21) - 1);

Although the second line is an unnecessary change, since that's
what it effectually means already, it's easier to read that way
and will prevent others from making the same mistake you just
did.

> The changes I made to test-squeue.c to change the multiplication factor now works up to a factor of 1,000,000 on a 64 bit system. These tests fail on 32 bit, but that's to be expected since the time_t part is 32 bit.
>
> So 43 bits for seconds + 21 bits for usec seem fine.

Except you botched the implementation, so you turned that entire
statement around. It's 21 bits for seconds with your patch. Just
enough for 24 days.

>
>> Besides, with 43 bits for the seconds we could still get too
>> large a number for us to handle and we'd still be back at square 1.
>
> I notice that in pqueue.h that pqueue_pri_t is changed from a double to unsigned long long:
>
> /*
>   * Altered for Nagios by Andreas Ericsson <ae...@op...> with the excplicit
>   * consent of Volkan Yazici <vol...@gm...>. Many thanks.
>   * Changed as follows:
>   *
>   * - pqueue_pri_t is an unsigned long long instead of a double
>   *   ull comparisons are 107 times faster than double comparisons
>   *   on my 64-bit laptop
>   */
>
> Would it be better to leave it as a double, so that all values will work properly, and take the performance hit?
>

Definitely not. The event queue is the heart of Nagios. Making it
107 times slower so we can support scheduling checks to see exactly
when the sun explodes is just plain stupid.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

[Nagios-devel] [PATCH] core: Avoid lock file removal race condition

[Anton L. <alo...@op...>]

This patch avoids a  race condition in removal of lock files. The race
condition happens when:

1. we receive a SIGHUP, breaking us out of the event execution loop, and
2. receive a SIGTERM - or any other "shutdown" signal - AFTER checking for
the sigshutdown state but BEFORE the do-while loop terminates. I.e, during
execution of cleanup() or close_debug_log() towards the end of the loop.

Signed-off-by: Anton Lofgren <alo...@op...>
---
 base/nagios.c | 15 +++++++++++----
 base/utils.c  |  1 -
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/base/nagios.c b/base/nagios.c
index 6b834b2..806d355 100644
--- a/base/nagios.c
+++ b/base/nagios.c
@@ -539,6 +539,11 @@ int main(int argc, char **argv) {

         /* keep monitoring things until we get a shutdown command */
         do {
+            if (daemon_mode == TRUE && sigrestart == TRUE) {
+                /* if we've restarted in daemon mode, we don't want to
leak the
+                 * lock file */
+                my_free(lock_file);
+            }

             /* reset program variables */
             reset_variables();
@@ -827,10 +832,6 @@ int main(int argc, char **argv) {
                 iobroker_destroy(nagios_iobs, IOBROKER_CLOSE_SOCKETS);
                 nagios_iobs = NULL;

-                /* make sure lock file has been removed - it may not have
been if we received a shutdown command */
-                if(daemon_mode == TRUE)
-                    unlink(lock_file);
-
                 /* log a shutdown message */
                 logit(NSLOG_PROCESS_INFO, TRUE, "Successfully shutdown...
(PID=%d)\n", (int)getpid());
                 }
@@ -844,6 +845,12 @@ int main(int argc, char **argv) {
             }
         while(sigrestart == TRUE && sigshutdown == FALSE);

+        /* make sure lock file has been removed - it may not have been if
we received a shutdown command */
+        if(daemon_mode == TRUE) {
+            unlink(lock_file);
+            my_free(lock_file);
+        }
+
         /* free misc memory */
         my_free(config_file);
         }
diff --git a/base/utils.c b/base/utils.c
index af95663..1ff1e7b 100644
--- a/base/utils.c
+++ b/base/utils.c
@@ -3157,7 +3157,6 @@ void free_memory(nagios_macros *mac) {
     my_free(temp_path);
     my_free(check_result_path);
     my_free(command_file);
-    my_free(lock_file);
     my_free(log_archive_path);

     return;
-- 
1.8.2

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Ton V. <ton...@op...>]

On 4 Apr 2013, at 22:55, Andreas Ericsson wrote:
>> This fails on CentOS 5 64bit, though appears to work on Debian Squeeze 32bit, so it maybe a 64 bit only issue.
>> 
>> We think this is an issue when the event is scheduled via squeue_add(). We've managed to get the test-squeue to fail by changing the time value to be greater than 2038 with the following:
>> 
>> Index: test-squeue.c
>> ===================================================================
>> --- test-squeue.c	(revision 2716)
>> +++ test-squeue.c	(working copy)
>> @@ -116,7 +116,7 @@
>>  	sq_test_random(sq);
>>  	t(squeue_size(sq) == 0, "Size should be 0 after first sq_test_random");
>> 
>> -	t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
>> +	t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
>>  	t(squeue_size(sq) == 1);
>>  	t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
>>  	t(squeue_size(sq) == 2);
>> 
>> This gives the test result of:
>> 
>> ### squeue tests
>>   FAIL max <= *d @test-squeue.c:86
>>   FAIL x == &b @test-squeue.c:133
>>   FAIL x->id == b.id @test-squeue.c:134
>>   FAIL x == &c @test-squeue.c:141
>> about to fail pretty fucking hard...
>> ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x: 0xbfde9b80
>>   FAIL x == &b @test-squeue.c:152
>>   FAIL x->id == b.id @test-squeue.c:153
>>   FAIL x == &b @test-squeue.c:160
>>   FAIL x->id == b.id @test-squeue.c:161
>>   FAIL x == &c @test-squeue.c:166
>>   FAIL x->id == c.id @test-squeue.c:167
>> Test results: 390637 passed, 10 failed
>> 
>> Changing to a factor of 1.1 instead of 2 passes:
>> 
> 
> I'm not surprised. 1.1 would mean it's still within the unix timeframe.
> 
> What's the size of time_t, long and struct timeval on systems where it 
> fails?
> What's the sizes on systems where it succeeds?

With the recreation steps, Nagios 4 works fine on rhel5 32bit, but fails on rhel5 64bit.

sizes.c:

#include <string.h>
#include <stdio.h>
#include <assert.h>
#include <sys/types.h>
#include <signal.h>
#include <unistd.h>
#include <sys/time.h>
#include "pqueue.h"

int main(int argc, char **argv)
{
    struct timeval tv;

    printf("long = %d\n", sizeof(long));
    printf("time_t = %d\n", sizeof(time_t));
    printf("tv = %d\n", sizeof(tv));
    printf("pqueue_pri_t = %d\n", sizeof(pqueue_pri_t));
    return 0;

}

RHEL5 32 bit:
long = 4
time_t = 4
tv = 8
pqueue_pri_t = 8


RHEL5 64 bit:
long = 8
time_t = 8
tv = 16
pqueue_pri_t = 8

> Does time_t differ in signedness on them?

Not sure how to check this.

> I think a runtime check based on those sizes should work just fine, and
> also be optimized away so we don't actually have to pay for it, but I'm
> curious to see where it actually goes wrong. If it's before we get to
> see the number in squeue.c we're pretty much fscked, as the only option
> then is a macro which does voodoo-casting so the squeue api sees the
> right number.
> 
>> ### squeue tests
>> Test results: 390647 passed, 0 failed
>> 
>> This worked in Nagios 3, so we're guessing that the change to use the squeue library for events is probably where this limitation has come in.
>> 
>> Any thoughts?
>> 
> 
> Well, modifying the evt_compute_pri() algorithm to discard
> everything but the 21 least significant bits of the tv->tv_usec
> would allow us to use 43 bits for the seconds value. That would
> land us somewhere in the year 141234 before we run out of seconds.
> It's not a real fix though, since we could live with discarding
> events that are patently absurd, but blocking the entire scheduler
> because we get a bogus date is just plain wrong.

I've changed the code so it now looks like this:

static pqueue_pri_t evt_compute_pri(struct timeval *tv)
{
        pqueue_pri_t ret;

        /* keep weird compilers on 32-bit systems from doing wrong */
        if(sizeof(pqueue_pri_t) < 8) {
                ret = tv->tv_sec;
                ret += !!tv->tv_usec;
        } else {
                ret = (pqueue_pri_t) tv->tv_sec;
                ret <<= 43;
                ret |= (tv->tv_usec & 0x1FFFFF);
        }

        return ret;
}

For the same recreation steps, the event queue is now working properly. 

The changes I made to test-squeue.c to change the multiplication factor now works up to a factor of 1,000,000 on a 64 bit system. These tests fail on 32 bit, but that's to be expected since the time_t part is 32 bit.

So 43 bits for seconds + 21 bits for usec seem fine.

> Besides, with 43 bits for the seconds we could still get too
> large a number for us to handle and we'd still be back at square 1.

I notice that in pqueue.h that pqueue_pri_t is changed from a double to unsigned long long:

/*
 * Altered for Nagios by Andreas Ericsson <ae...@op...> with the excplicit
 * consent of Volkan Yazici <vol...@gm...>. Many thanks.
 * Changed as follows:
 * 
 * - pqueue_pri_t is an unsigned long long instead of a double
 *   ull comparisons are 107 times faster than double comparisons
 *   on my 64-bit laptop
 */

Would it be better to leave it as a double, so that all values will work properly, and take the performance hit?

Ton

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Anton L. <alo...@op...>]

On Fri, Apr 5, 2013 at 4:55 PM, Andreas Ericsson <ae...@op...> wrote:

> On 04/05/2013 09:41 AM, Anton Löfgren wrote:
>
>> For the record, the following patch identically triggers the faults on my
>> x86_64 Arch installation (where time_t normally is a quad word).
>>
>>
> Well, yes. You're explicitly casting it to a 32-bit value but it can't
> hold that much so it gets truncated.

Right. The point I was trying to make was merely that it indeed seems like
an integer overflow is causing the issue Ton Voon's experiencing. I'm sorry
for the noise if that had already established as fact.


> But CentOS 5 really shouldn't have
> 32-bit time_t, and especially not on 64-bit archs, so I don't know
> where it's getting its cast from.
>
Indeed - it'd be great to have some more information on what structs are
actually being used on his system. Along, possibly, with whichever build
flags were used to build his CentOS Nagios installation

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Andreas E. <ae...@op...>]

On 04/05/2013 09:41 AM, Anton Löfgren wrote:
> For the record, the following patch identically triggers the faults on my
> x86_64 Arch installation (where time_t normally is a quad word).
>

Well, yes. You're explicitly casting it to a 32-bit value but it can't
hold that much so it gets truncated. But CentOS 5 really shouldn't have
32-bit time_t, and especially not on 64-bit archs, so I don't know
where it's getting its cast from.

It's weird though, because we use the timeval struct provided by
squeue_event_runtime() to check the delay. The delay should always be
< 0 if we overflow the tv_sec field, or huge if we don't. Either way,
we should either run the event as scheduled (and then remove it), or
it shouldn't be at the top of the queue.

Not that I'm overly bothered with what happens when you schedule things
25 years into the future, but bugs that shouldn't exist tend to piss me
off.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Anton L. <alo...@op...>]

For the record, the following patch identically triggers the faults on my
x86_64 Arch installation (where time_t normally is a quad word).

Subject: [PATCH] test-squeue: trigger y2038 bug

Signed-off-by: Anton Lofgren <alo...@op...>
---
 lib/test-squeue.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/test-squeue.c b/lib/test-squeue.c
index 556952d..faf0b5d 100644
--- a/lib/test-squeue.c
+++ b/lib/test-squeue.c
@@ -11,6 +11,7 @@
 #include <sys/time.h>
 #include "squeue.c"
 #include "t-utils.h"
+#include <stdint.h>

 static void squeue_foreach(squeue_t *q, int (*walker)(squeue_event *, void
*), void *arg)
 {
@@ -116,7 +117,7 @@ int main(int argc, char **argv)
        sq_test_random(sq);
        t(squeue_size(sq) == 0, "Size should be 0 after first
sq_test_random");

-       t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
+       t((a.evt = squeue_add(sq, (int32_t)(time(NULL) * 2), &a)) != NULL);
        t(squeue_size(sq) == 1);
        t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
        t(squeue_size(sq) == 2);
-- 
1.8.2




test-squeue:
### squeue tests
  FAIL max <= *d @test-squeue.c:87
  FAIL x == &b @test-squeue.c:134
  FAIL x->id == b.id @test-squeue.c:135
  FAIL x == &c @test-squeue.c:142
about to fail pretty fucking hard...
ea: 0x7fffe6dd1e50; &b: 0x7fffe6dd1e60; &c: 0x7fffe6dd1e70; ed:
0x7fffe6dd1e80; x: 0x7fffe6d83de0
  FAIL x == &b @test-squeue.c:153
  FAIL x->id == b.id @test-squeue.c:154
  FAIL x == &b @test-squeue.c:161
  FAIL x->id == b.id @test-squeue.c:162
  FAIL x == &c @test-squeue.c:167
  FAIL x->id == c.id @test-squeue.c:168
Test results: 390637 passed, 10 failed
make[1]: *** [test] Error 1


/Anton

On Thu, Apr 4, 2013 at 11:55 PM, Andreas Ericsson <ae...@op...> wrote:

> On 04/04/2013 06:32 PM, Ton Voon wrote:
> > Hi!
> >
> > We've come across a problem in an upgrade of Nagios 3 to Nagios 4 which
> we can't work out where the fix is. It occurs when an event is scheduled in
> the future beyond 2038.
> >
>
> Why on earth would you want to schedule something to end beyond 2038?
> It sounds like you're using a patch on a workaround for something that
> was the wrong solution in the first place.
>
> > Recreation steps:
> >    * Set a downtime on a service to end next day
> >    * Stop Nagios
> >    * Edit the retention.dat so that the end_date=4514791088 (some other
> values seem to work)
> >    * Start Nagios
> >
> > When Nagios starts, it will not run any scheduled events in the events
> queue.
> >
>
> Ouch. That's pretty bad.
>
> > This fails on CentOS 5 64bit, though appears to work on Debian Squeeze
> 32bit, so it maybe a 64 bit only issue.
> >
> > We think this is an issue when the event is scheduled via squeue_add().
> We've managed to get the test-squeue to fail by changing the time value to
> be greater than 2038 with the following:
> >
> > Index: test-squeue.c
> > ===================================================================
> > --- test-squeue.c     (revision 2716)
> > +++ test-squeue.c     (working copy)
> > @@ -116,7 +116,7 @@
> >       sq_test_random(sq);
> >       t(squeue_size(sq) == 0, "Size should be 0 after first
> sq_test_random");
> >
> > -     t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
> > +     t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
> >       t(squeue_size(sq) == 1);
> >       t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
> >       t(squeue_size(sq) == 2);
> >
> > This gives the test result of:
> >
> > ### squeue tests
> >    FAIL max <= *d @test-squeue.c:86
> >    FAIL x == &b @test-squeue.c:133
> >    FAIL x->id == b.id @test-squeue.c:134
> >    FAIL x == &c @test-squeue.c:141
> > about to fail pretty fucking hard...
> > ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x:
> 0xbfde9b80
> >    FAIL x == &b @test-squeue.c:152
> >    FAIL x->id == b.id @test-squeue.c:153
> >    FAIL x == &b @test-squeue.c:160
> >    FAIL x->id == b.id @test-squeue.c:161
> >    FAIL x == &c @test-squeue.c:166
> >    FAIL x->id == c.id @test-squeue.c:167
> > Test results: 390637 passed, 10 failed
> >
> > Changing to a factor of 1.1 instead of 2 passes:
> >
>
> I'm not surprised. 1.1 would mean it's still within the unix timeframe.
>
> What's the size of time_t, long and struct timeval on systems where it
> fails?
> What's the sizes on systems where it succeeds?
> Does time_t differ in signedness on them?
>
> I think a runtime check based on those sizes should work just fine, and
> also be optimized away so we don't actually have to pay for it, but I'm
> curious to see where it actually goes wrong. If it's before we get to
> see the number in squeue.c we're pretty much fscked, as the only option
> then is a macro which does voodoo-casting so the squeue api sees the
> right number.
>
> > ### squeue tests
> > Test results: 390647 passed, 0 failed
> >
> > This worked in Nagios 3, so we're guessing that the change to use the
> squeue library for events is probably where this limitation has come in.
> >
> > Any thoughts?
> >
>
> Well, modifying the evt_compute_pri() algorithm to discard
> everything but the 21 least significant bits of the tv->tv_usec
> would allow us to use 43 bits for the seconds value. That would
> land us somewhere in the year 141234 before we run out of seconds.
> It's not a real fix though, since we could live with discarding
> events that are patently absurd, but blocking the entire scheduler
> because we get a bogus date is just plain wrong.
>
> Besides, with 43 bits for the seconds we could still get too
> large a number for us to handle and we'd still be back at square 1.
>
> --
> Andreas Ericsson                   and...@op...
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Andreas E. <ae...@op...>]

On 04/04/2013 06:32 PM, Ton Voon wrote:
> Hi!
>
> We've come across a problem in an upgrade of Nagios 3 to Nagios 4 which we can't work out where the fix is. It occurs when an event is scheduled in the future beyond 2038.
>

Why on earth would you want to schedule something to end beyond 2038?
It sounds like you're using a patch on a workaround for something that
was the wrong solution in the first place.

> Recreation steps:
>    * Set a downtime on a service to end next day
>    * Stop Nagios
>    * Edit the retention.dat so that the end_date=4514791088 (some other values seem to work)
>    * Start Nagios
>
> When Nagios starts, it will not run any scheduled events in the events queue.
>

Ouch. That's pretty bad.

> This fails on CentOS 5 64bit, though appears to work on Debian Squeeze 32bit, so it maybe a 64 bit only issue.
>
> We think this is an issue when the event is scheduled via squeue_add(). We've managed to get the test-squeue to fail by changing the time value to be greater than 2038 with the following:
>
> Index: test-squeue.c
> ===================================================================
> --- test-squeue.c	(revision 2716)
> +++ test-squeue.c	(working copy)
> @@ -116,7 +116,7 @@
>   	sq_test_random(sq);
>   	t(squeue_size(sq) == 0, "Size should be 0 after first sq_test_random");
>
> -	t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
> +	t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
>   	t(squeue_size(sq) == 1);
>   	t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
>   	t(squeue_size(sq) == 2);
>
> This gives the test result of:
>
> ### squeue tests
>    FAIL max <= *d @test-squeue.c:86
>    FAIL x == &b @test-squeue.c:133
>    FAIL x->id == b.id @test-squeue.c:134
>    FAIL x == &c @test-squeue.c:141
> about to fail pretty fucking hard...
> ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x: 0xbfde9b80
>    FAIL x == &b @test-squeue.c:152
>    FAIL x->id == b.id @test-squeue.c:153
>    FAIL x == &b @test-squeue.c:160
>    FAIL x->id == b.id @test-squeue.c:161
>    FAIL x == &c @test-squeue.c:166
>    FAIL x->id == c.id @test-squeue.c:167
> Test results: 390637 passed, 10 failed
>
> Changing to a factor of 1.1 instead of 2 passes:
>

I'm not surprised. 1.1 would mean it's still within the unix timeframe.

What's the size of time_t, long and struct timeval on systems where it 
fails?
What's the sizes on systems where it succeeds?
Does time_t differ in signedness on them?

I think a runtime check based on those sizes should work just fine, and
also be optimized away so we don't actually have to pay for it, but I'm
curious to see where it actually goes wrong. If it's before we get to
see the number in squeue.c we're pretty much fscked, as the only option
then is a macro which does voodoo-casting so the squeue api sees the
right number.

> ### squeue tests
> Test results: 390647 passed, 0 failed
>
> This worked in Nagios 3, so we're guessing that the change to use the squeue library for events is probably where this limitation has come in.
>
> Any thoughts?
>

Well, modifying the evt_compute_pri() algorithm to discard
everything but the 21 least significant bits of the tv->tv_usec
would allow us to use 43 bits for the seconds value. That would
land us somewhere in the year 141234 before we run out of seconds.
It's not a real fix though, since we could live with discarding
events that are patently absurd, but blocking the entire scheduler
because we get a bogus date is just plain wrong.

Besides, with 43 bits for the seconds we could still get too
large a number for us to handle and we'd still be back at square 1.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Anton L. <alo...@op...>]

Hi,

Without having access to a computer, I'd venture a guess that time_t is too
small on centos 5. You might want to compare it to your Debian installation.

I think this is more likely to be a problem with "old glibc" than a problem
with your cpu architecture.

Best regards,
Anton
On 4 Apr 2013 18:55, "Ton Voon" <ton...@op...> wrote:

> Hi!
>
> We've come across a problem in an upgrade of Nagios 3 to Nagios 4 which we
> can't work out where the fix is. It occurs when an event is scheduled in
> the future beyond 2038.
>
> Recreation steps:
>   * Set a downtime on a service to end next day
>   * Stop Nagios
>   * Edit the retention.dat so that the end_date=4514791088 (some other
> values seem to work)
>   * Start Nagios
>
> When Nagios starts, it will not run any scheduled events in the events
> queue.
>
> This fails on CentOS 5 64bit, though appears to work on Debian Squeeze
> 32bit, so it maybe a 64 bit only issue.
>
> We think this is an issue when the event is scheduled via squeue_add().
> We've managed to get the test-squeue to fail by changing the time value to
> be greater than 2038 with the following:
>
> Index: test-squeue.c
> ===================================================================
> --- test-squeue.c       (revision 2716)
> +++ test-squeue.c       (working copy)
> @@ -116,7 +116,7 @@
>         sq_test_random(sq);
>         t(squeue_size(sq) == 0, "Size should be 0 after first
> sq_test_random");
>
> -       t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
> +       t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
>         t(squeue_size(sq) == 1);
>         t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
>         t(squeue_size(sq) == 2);
>
> This gives the test result of:
>
> ### squeue tests
>   FAIL max <= *d @test-squeue.c:86
>   FAIL x == &b @test-squeue.c:133
>   FAIL x->id == b.id @test-squeue.c:134
>   FAIL x == &c @test-squeue.c:141
> about to fail pretty fucking hard...
> ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x:
> 0xbfde9b80
>   FAIL x == &b @test-squeue.c:152
>   FAIL x->id == b.id @test-squeue.c:153
>   FAIL x == &b @test-squeue.c:160
>   FAIL x->id == b.id @test-squeue.c:161
>   FAIL x == &c @test-squeue.c:166
>   FAIL x->id == c.id @test-squeue.c:167
> Test results: 390637 passed, 10 failed
>
> Changing to a factor of 1.1 instead of 2 passes:
>
> ### squeue tests
> Test results: 390647 passed, 0 failed
>
> This worked in Nagios 3, so we're guessing that the change to use the
> squeue library for events is probably where this limitation has come in.
>
> Any thoughts?
>
> Ton
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>

[Nagios-devel] Bug report: downtimes beyond 2038 cause event queue errors

[Ton V. <ton...@op...>]

Hi!

We've come across a problem in an upgrade of Nagios 3 to Nagios 4 which we can't work out where the fix is. It occurs when an event is scheduled in the future beyond 2038.

Recreation steps:
  * Set a downtime on a service to end next day
  * Stop Nagios
  * Edit the retention.dat so that the end_date=4514791088 (some other values seem to work)
  * Start Nagios

When Nagios starts, it will not run any scheduled events in the events queue.

This fails on CentOS 5 64bit, though appears to work on Debian Squeeze 32bit, so it maybe a 64 bit only issue.

We think this is an issue when the event is scheduled via squeue_add(). We've managed to get the test-squeue to fail by changing the time value to be greater than 2038 with the following:

Index: test-squeue.c
===================================================================
--- test-squeue.c	(revision 2716)
+++ test-squeue.c	(working copy)
@@ -116,7 +116,7 @@
 	sq_test_random(sq);
 	t(squeue_size(sq) == 0, "Size should be 0 after first sq_test_random");
 
-	t((a.evt = squeue_add(sq, time(NULL) + 9, &a)) != NULL);
+	t((a.evt = squeue_add(sq, time(NULL)*2, &a)) != NULL);
 	t(squeue_size(sq) == 1);
 	t((b.evt = squeue_add(sq, time(NULL) + 3, &b)) != NULL);
 	t(squeue_size(sq) == 2);

This gives the test result of:

### squeue tests
  FAIL max <= *d @test-squeue.c:86
  FAIL x == &b @test-squeue.c:133
  FAIL x->id == b.id @test-squeue.c:134
  FAIL x == &c @test-squeue.c:141
about to fail pretty fucking hard...
ea: 0xbfe065e0; &b: 0xbfe065d8; &c: 0xbfe065d0; ed: 0xbfe065c8; x: 0xbfde9b80
  FAIL x == &b @test-squeue.c:152
  FAIL x->id == b.id @test-squeue.c:153
  FAIL x == &b @test-squeue.c:160
  FAIL x->id == b.id @test-squeue.c:161
  FAIL x == &c @test-squeue.c:166
  FAIL x->id == c.id @test-squeue.c:167
Test results: 390637 passed, 10 failed

Changing to a factor of 1.1 instead of 2 passes:

### squeue tests
Test results: 390647 passed, 0 failed

This worked in Nagios 3, so we're guessing that the change to use the squeue library for events is probably where this limitation has come in.

Any thoughts?

Ton

Re: [Nagios-devel] Support quoting vertical bar (|) character in plugin output

[Jochen B. <Joc...@LI...>]

On 27.03.2013 12:24, Andreas Ericsson wrote:
> OTOH, perfdata should've been on a line of its own from the start,
> prefixed with 'perfdata=' instead of a magic character put in the
> plugin output.

Just in case that someone reads (or later unearths) this thread looking
for actual suggestions: Making it a magic *character* IMHO isn't the
problem *IF*:
-- it helps with still-limited buffers
-- you require it to appear *first* on the line (no scanning ahead
   Lord-knows-how-far or breaking lines up)
-- you define a method (character stuffing?) to escape it in
   non-perfdata ("output") lines
-- you allow an *arbitrary mix* of output and perfdata lines (so that
   you can run a *series* of plugins or have a plugin printf() data
   in whichever sequence it "naturally" comes across it without having
   to worry that that'll break the global syntax)
-- you do the concatenation within Nagios properly (add back the '\n'
   at the end of output lines *and a ' ' between perfdata lines*; the
   current core assembles the perfdata from
	printf("foo|bar=1\nbaz|org=2\n");
   into "bar=1org=2")
             ^^

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

Re: [Nagios-devel] Support quoting vertical bar (|) character in plugin output

[Andreas E. <ae...@op...>]

On 03/26/2013 07:09 PM, Jochen Bern wrote:
> On 26.03.2013 18:23, Jim Winkle wrote:
>> It's possible for a plugin to have a vertical bar (|) character in its
>> regular output.
> 
> That depends a bit on what your definition of "(plugin) output" is.
> Plugins certainly *can* shove pipe symbols out their stdout/stderr, but
> (lacking any defined escaping) they'll never arrive in what Nagios
> considers the "Plugin Output" (while extraneous pipes *will* appear in
> the Performance Data).
> 
>> For example, I've seen cases where check_logfiles does this [...]
>> It seems that (and correct me if I'm wrong) Nagios doesn't support a
>> way to escape '|' in plugin output.
> 
> That's correct as of 3.x. (Somebody please speak up if the upcoming 4.x
> is going to change that.)
> 

Nothing has changed in that regard for Nagios 4.

>> If this is true, I'll request this enhancement on tracker.nagios.org.
> 
> IIUC API changes wouldn't get applied until at least 4.1, so you might
> want to simultaneously ask Gerhard for a fix in the plugin for the time
> being.
> 

It's not really an API change to allow random characters to be escaped
in plugin output.

OTOH, perfdata should've been on a line of its own from the start,
prefixed with 'perfdata=' instead of a magic character put in the
plugin output.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Support quoting vertical bar (|) character in plugin output

[Jochen B. <Joc...@LI...>]

On 26.03.2013 18:23, Jim Winkle wrote:
> It's possible for a plugin to have a vertical bar (|) character in its
> regular output.

That depends a bit on what your definition of "(plugin) output" is.
Plugins certainly *can* shove pipe symbols out their stdout/stderr, but
(lacking any defined escaping) they'll never arrive in what Nagios
considers the "Plugin Output" (while extraneous pipes *will* appear in
the Performance Data).

> For example, I've seen cases where check_logfiles does this [...]
> It seems that (and correct me if I'm wrong) Nagios doesn't support a
> way to escape '|' in plugin output.

That's correct as of 3.x. (Somebody please speak up if the upcoming 4.x
is going to change that.)

> If this is true, I'll request this enhancement on tracker.nagios.org.

IIUC API changes wouldn't get applied until at least 4.1, so you might
want to simultaneously ask Gerhard for a fix in the plugin for the time
being.

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

[Nagios-devel] Support quoting vertical bar (|) character in plugin output

[Jim W. <jrw...@wi...>]

It's possible for a plugin to have a vertical bar (|) character in its regular output. For example, I've seen cases where check_logfiles does this when there is a '|' in /var/log/messages. Nagios interprets anything after the '|' as performance data, so all of the plugin output doesn't get reported and performance data for that point in time is corrupt.

It seems that (and correct me if I'm wrong) Nagios doesn't support a way to escape '|' in plugin output. If it did, the author of any such plugin could escape any '|' characters in the regular output.

If this is true, I'll request this enhancement on tracker.nagios.org.

Thanks in advance!

--
Jim

Re: [Nagios-devel] [PATCH] libfanout: stash next pointer

[Andreas E. <ae...@op...>]

Embarrassing catch, but thanks.

On 03/22/2013 05:22 PM, Max Sikstrom wrote:
> From: Max Sikström <msi...@op...>
> 
> Stash next pointer for entry when iterating over a linked list in the obiously
> correct fanout lib.
> 
> The next pointer is lost when freeing the entry item in a for loop... One
> penny^Cpointer saved is a pointer earned, as my grandma used to say...
> 
> Signed-off-by: Max Sikström <msi...@op...>
> ---
>   lib/fanout.c |   10 +++++++---
>   1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/fanout.c b/lib/fanout.c
> index dda2874..a14d693 100644
> --- a/lib/fanout.c
> +++ b/lib/fanout.c
> @@ -29,13 +29,15 @@ fanout_table *fanout_create(unsigned long size)
>   void fanout_destroy(fanout_table *t, void (*destructor)(void *))
>   {
>   	unsigned long i;
> +	struct fanout_entry *next;
>   
>   	if (!t || !t->entries || !t->alloc)
>   		return;
>   
>   	for (i = 0; i < t->alloc; i++) {
>   		struct fanout_entry *entry;
> -		for (entry = t->entries[i]; entry; entry = entry->next) {
> +		for (entry = t->entries[i]; entry; entry = next) {
> +			next = entry->next; /* Stash it, it might be gone later */
>   			if (destructor) {
>   				destructor(entry->data);
>   			}
> @@ -67,13 +69,15 @@ int fanout_add(struct fanout_table *t, unsigned long key, void *data)
>   
>   void *fanout_remove(fanout_table *t, unsigned long key)
>   {
> -	struct fanout_entry *entry, *prev = NULL;
> +	struct fanout_entry *entry, *next, *prev = NULL;
>   	unsigned long slot;
> +
>   	if (!t || !t->entries || !t->alloc)
>   		return NULL;
>   
>   	slot = key % t->alloc;
> -	for (entry = t->entries[slot]; entry; prev = entry, entry = entry->next) {
> +	for (entry = t->entries[slot]; entry; prev = entry, entry = next) {
> +		next = entry->next; /* Stash it, it might be gone later */
>   		if (entry->key == key) {
>   			void *data = entry->data;
>   			if (prev) {
> 


-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

[Nagios-devel] [PATCH] libfanout: stash next pointer

[Max S. <max...@op...>]

From: Max Sikström <msi...@op...>

Stash next pointer for entry when iterating over a linked list in the obiously
correct fanout lib.

The next pointer is lost when freeing the entry item in a for loop... One
penny^Cpointer saved is a pointer earned, as my grandma used to say...

Signed-off-by: Max Sikström <msi...@op...>
---
 lib/fanout.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lib/fanout.c b/lib/fanout.c
index dda2874..a14d693 100644
--- a/lib/fanout.c
+++ b/lib/fanout.c
@@ -29,13 +29,15 @@ fanout_table *fanout_create(unsigned long size)
 void fanout_destroy(fanout_table *t, void (*destructor)(void *))
 {
 	unsigned long i;
+	struct fanout_entry *next;
 
 	if (!t || !t->entries || !t->alloc)
 		return;
 
 	for (i = 0; i < t->alloc; i++) {
 		struct fanout_entry *entry;
-		for (entry = t->entries[i]; entry; entry = entry->next) {
+		for (entry = t->entries[i]; entry; entry = next) {
+			next = entry->next; /* Stash it, it might be gone later */
 			if (destructor) {
 				destructor(entry->data);
 			}
@@ -67,13 +69,15 @@ int fanout_add(struct fanout_table *t, unsigned long key, void *data)
 
 void *fanout_remove(fanout_table *t, unsigned long key)
 {
-	struct fanout_entry *entry, *prev = NULL;
+	struct fanout_entry *entry, *next, *prev = NULL;
 	unsigned long slot;
+
 	if (!t || !t->entries || !t->alloc)
 		return NULL;
 
 	slot = key % t->alloc;
-	for (entry = t->entries[slot]; entry; prev = entry, entry = entry->next) {
+	for (entry = t->entries[slot]; entry; prev = entry, entry = next) {
+		next = entry->next; /* Stash it, it might be gone later */
 		if (entry->key == key) {
 			void *data = entry->data;
 			if (prev) {
-- 
1.7.1

Re: [Nagios-devel] [PATCH] Macros: fix of invalid free for TOTALHOSTSERVICES* macros

[Andreas E. <ae...@op...>]

On 03/19/2013 12:06 AM, Max Sikstrom wrote:
> From: Max Sikström <msi...@op...>
>
> The $TOTALHOSTSERVICES*$ macros were computed all at the same time, with the
> result stashed in mac->x using the mkstr method (from worker.c? why worker.c?)
>

It's in nsutils.c now, if that's any comfort ;)


> The mkstr uses an static internal buffer of usally 256 strings, of each 32
> bytes, for generation of strings, used in macros. When computing
> TOTALHOSTSERVICES*, the valuse is, as said, stashed in mac->x[], which is freed
>   at cleanup, with some exceptions, and this isn't one of them.
>
> Those needs to be exceptions, so static function variables isn't freed
>

Neato. Thanks. I'll apply asap (which is tomorrow, since I'm too lazy to 
stash, apply and push right now).

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Nagios Core 3.5.0rc2

[eponymous a. <epo...@ya...>]

Sorry, I should have caught this trivial fix before the final release was out.  In common/macros.c, the current
code says:

#include "../include/macros.h"
#include "../include/config.h"

But this doesn't do the right thing, with regard to
defining the _GNU_SOURCE symbol so the compiler doesn't
complain about the asprintf() calls.  The problem is that
macros.h eventually includes <time.h>, which itself
includes <features.h>, which is where _GNU_SOURCE gets
turned into the __USE_GNU symbol that is actually used
in <stdio.h> to provide a definition for asprintf().
So the definition of _GNU_SOURCE at the top of config.h
comes too late to do any good.

Long story short, the order of those two lines in
common/macros.c needs to be reversed:

#include "../include/config.h"
#include "../include/macros.h"

Also in the way of trivial fixes, compilation of
cgiutils.c yields the warning:

cgiutils.c: In function 'include_ssi_files':
cgiutils.c:1571: warning: unused variable 'x'

This ought to be suppressed by removing the obsolete
declaration.

--- On Sat, 3/9/13, Eric Stanley <est...@na...> wrote:

> From: Eric Stanley <est...@na...>
> Subject: [Nagios-devel] Nagios Core 3.5.0rc2
> To: "Nagios Developers List" <nag...@li...>
> Date: Saturday, March 9, 2013, 2:37 PM
> I have just uploaded another Nagios
> Core release candidate. Thanks to 
> Phil Randal for find and reporting an issue.
> 
> You can download the 3.5.0rc2 tarball from 
> http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.5.0/nagios-3.5.0rc2.tar.gz/download.
> 
> Feel free to compile and try it out. I will release 3.5.0
> about midweek 
> unless I hear of significant issues.
> 
> The complete changelog since 3.4.4 is as follows:
> 
> * Fixed bug #403: The "configuration" page of the webui
> doesn't use 
> entity encoding
> when displaying the "command expansion" item (Eric Stanley,
> Phil Randal)
> * Fixed bug #424: Nagios Core 3.4.4 seg fault (core dump) on
> restart 
> after removing
> config for running service (Eric Stanley)
> * Updated CGI utility functions to support UTF-8 characters
> (Eric Stanley)
> * Fixed bug where selecting Command Expansion from
> Configuration CGI 
> page would disp
> lay commands instead (Eric Stanley)
> * Fixed bug #369: status.cgi crashes with segfault when
> there are german 
> ulauts (äöü
> ß) in the hostname or the servicename (Eric Stanley)
> * Fixed bug #418: Scheduled Downtime Notifications Resent On
> Nagios 
> Restart/reload (
> Eric Stanley)
> 
> -- 
> Eric Stanley
> ___
> Developer
> Nagios Enterprises, LLC
> Email:  est...@na...
> Web:    www.nagios.com
> 
> 
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in
> The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good
> choice" in the  
> endpoint security space. For insight on selecting the right
> partner to 
> tackle endpoint security challenges, access the full report.
> 
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

Re: [Nagios-devel] NRPE Version 2.14

[Daniel W. <dan...@st...>]

Try the the RPM's, along with the spec and src.rpm.  I've been working on a major update of 2.14 RPM just not gotten to it, but that's what I have in progress so far.

https://www.dropbox.com/l/ZyigukkOBNIArTwxlSAf6c

Dan

On Mar 16, 2013, at 10:50 PM, Kaushal Shriyan wrote:

Dan,

http://fpaste.org/SANg/ nrpe.spec file
http://fpaste.org/VqgD/ shows the build error

Regards,

Kaushal



On Sun, Mar 17, 2013 at 8:26 AM, Daniel Wittenberg <dan...@st...<mailto:dan...@st...>> wrote:
Oh yeah I found that too, just don't have new spec done :)

add:
%{__install} -m 0755 init-script ${RPM_BUILD_ROOT}%{_initddir}/nrpe

right before the %clean section.

Dan


On Mar 16, 2013, at 9:50 PM, Kaushal Shriyan wrote:



On Sun, Mar 17, 2013 at 8:04 AM, Daniel Wittenberg <dan...@st...<mailto:dan...@st...>> wrote:
wget http://nagios.svn.sourceforge.net/viewvc/nagios/nrpe/trunk/nrpe.spec?revision=2574

Dan


Dan , i get into this issue when i do rpmbuild -ba nrpe.spec file  http://fpaste.org/DYip/ Please suggest further.

Regards,

Kaushal
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
Nagios-devel mailing list
Nag...@li...<mailto:Nag...@li...>
https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Nagios-devel mailing list
Nag...@li...<mailto:Nag...@li...>
https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
Nagios-devel mailing list
Nag...@li...
https://lists.sourceforge.net/lists/listinfo/nagios-devel

Re: [Nagios-devel] NRPE Version 2.14

[Kaushal S. <kau...@gm...>]

Dan,

http://fpaste.org/SANg/ nrpe.spec file
http://fpaste.org/VqgD/ shows the build error

Regards,

Kaushal



On Sun, Mar 17, 2013 at 8:26 AM, Daniel Wittenberg <
dan...@st...> wrote:

>  Oh yeah I found that too, just don't have new spec done :)
>
>  add:
> %{__install} -m 0755 init-script ${RPM_BUILD_ROOT}%{_initddir}/nrpe
>
>  right before the %clean section.
>
>  Dan
>
>
>  On Mar 16, 2013, at 9:50 PM, Kaushal Shriyan wrote:
>
>
>
> On Sun, Mar 17, 2013 at 8:04 AM, Daniel Wittenberg <
> dan...@st...> wrote:
>
>>  wget
>> http://nagios.svn.sourceforge.net/viewvc/nagios/nrpe/trunk/nrpe.spec?revision=2574
>>
>>  Dan
>>
>>
>  Dan , i get into this issue when i do rpmbuild -ba nrpe.spec file
> http://fpaste.org/DYip/ Please suggest further.
>
>  Regards,
>
>  Kaushal
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
>
> http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>

Re: [Nagios-devel] NRPE Version 2.14

[Daniel W. <dan...@st...>]

Oh yeah I found that too, just don't have new spec done :)

add:
%{__install} -m 0755 init-script ${RPM_BUILD_ROOT}%{_initddir}/nrpe

right before the %clean section.

Dan


On Mar 16, 2013, at 9:50 PM, Kaushal Shriyan wrote:



On Sun, Mar 17, 2013 at 8:04 AM, Daniel Wittenberg <dan...@st...<mailto:dan...@st...>> wrote:
wget http://nagios.svn.sourceforge.net/viewvc/nagios/nrpe/trunk/nrpe.spec?revision=2574

Dan


Dan , i get into this issue when i do rpmbuild -ba nrpe.spec file  http://fpaste.org/DYip/ Please suggest further.

Regards,

Kaushal
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
Nagios-devel mailing list
Nag...@li...
https://lists.sourceforge.net/lists/listinfo/nagios-devel

Re: [Nagios-devel] NRPE Version 2.14

[Kaushal S. <kau...@gm...>]

On Sun, Mar 17, 2013 at 8:04 AM, Daniel Wittenberg <
dan...@st...> wrote:

>  wget
> http://nagios.svn.sourceforge.net/viewvc/nagios/nrpe/trunk/nrpe.spec?revision=2574
>
>  Dan
>
>
Dan , i get into this issue when i do rpmbuild -ba nrpe.spec file
http://fpaste.org/DYip/ Please suggest further.

Regards,

Kaushal

Re: [Nagios-devel] NRPE Version 2.14

[Daniel W. <dan...@st...>]

wget http://nagios.svn.sourceforge.net/viewvc/nagios/nrpe/trunk/nrpe.spec?revision=2574

Dan


On Mar 16, 2013, at 9:25 PM, Kaushal Shriyan wrote:



On Sun, Mar 17, 2013 at 7:42 AM, Daniel Wittenberg <dan...@st...<mailto:dan...@st...>> wrote:
Can you just download the spec and replace the one you have ?

Dan


Dan,

Have downloaded it from wget http://sourceforge.net/projects/nagios/files/nrpe-2.x/nrpe-2.14/nrpe-2.14.tar.gz and i still see 2.13 instead of 2.14 when reading the file
nrpe.spec -> http://paste.ubuntu.com/5621195/ Please suggest.

Regards,

Kaushal


On Mar 16, 2013, at 9:10 PM, Kaushal Shriyan wrote:



On Sun, Mar 17, 2013 at 7:32 AM, Daniel Wittenberg <dan...@st...<mailto:dan...@st...>> wrote:
I can post some RPM's tonight, but I can't fix the source download, so not sure…

Dan


Thanks Dan for the quick reply. will wait for your response.

Regards,

Kaushal
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
Nagios-devel mailing list
Nag...@li...<mailto:Nag...@li...>
https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Nagios-devel mailing list
Nag...@li...<mailto:Nag...@li...>
https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
Nagios-devel mailing list
Nag...@li...
https://lists.sourceforge.net/lists/listinfo/nagios-devel

Re: [Nagios-devel] NRPE Version 2.14

[Kaushal S. <kau...@gm...>]

On Sun, Mar 17, 2013 at 7:42 AM, Daniel Wittenberg <
dan...@st...> wrote:

>  Can you just download the spec and replace the one you have ?
>
>  Dan
>
>
Dan,

Have downloaded it from wget
http://sourceforge.net/projects/nagios/files/nrpe-2.x/nrpe-2.14/nrpe-2.14.tar.gzand
i still see 2.13 instead of 2.14 when reading the file
nrpe.spec -> http://paste.ubuntu.com/5621195/ Please suggest.

Regards,

Kaushal


>  On Mar 16, 2013, at 9:10 PM, Kaushal Shriyan wrote:
>
>
>
> On Sun, Mar 17, 2013 at 7:32 AM, Daniel Wittenberg <
> dan...@st...> wrote:
>
>>  I can post some RPM's tonight, but I can't fix the source download, so
>> not sure…
>>
>>  Dan
>>
>>
>  Thanks Dan for the quick reply. will wait for your response.
>
>  Regards,
>
>  Kaushal
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
>
> http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>