Nagios Support Forum

--00148531b92c11b8f90471e1945c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 24, 2009 at 11:58, S=C3=A9bastien Barbereau wrote:

> On Fri, Aug 21, 2009 at 2:54 PM, Ton Voon wrote:
>
>>
>> On 21 Aug 2009, at 09:52, Hiren Patel wrote:
>>
>> Ton Voon wrote:
>>
>> Hi!
>>
>>
>> I've setup the required central server for Tinderbox builds now. I've
>>
>> added a server so this is run every 24 hours now.
>>
>>
>> Status page: http://tinderbox.nagios.org/nagios/status.html
>>
>>
>> Information page: http://tinderbox.nagios.org (redirects to wiki)
>>
>>
>> If you care about Nagios building and running correctly on your
>>
>> platform of choice, please take a look at the pages to setup tinderbox
>>
>> builds on your systems. I'll be pleased to setup the necessary access
>>
>> for you to send your reports to the central server.
>>
>>
>>
>> interesting, and nice
>> what platforms do we currently have builds for?
>>
>>
>> That's easy - look at: http://tinderbox.nagios.org/nagios/status.html
>>
>> I could add more, but actually, I want more participation from the
>> community.
>>
>> and which are the most
>> common ones we want to start out with?
>>
>>
>> Add which ever ones you are interested in. There's the ability to add in
>> configure options, so I can see that you may want to test that certain
>> configure options work as expected.
>>
>> Ton
>>
>

> Hi,
> not sure what i'm missing here but I was trying to use the tinderbox_buil=
d
on a fresh nagios-head and
> I get a bunch of error related to the tap library. Replacing the
nagios/tap dir by the original source code
> branch from
http://people.freebsd.org/~nik/public_d ... .01.tar.gz seem to
magically resolve the
> issues.
> This seem particularly strange to me as the only modification is in the
tap.c file for the threads parts.
> Anyone has a clue on why I see this and how to fix it properly? (I was
suspecting some autoconf/automake
> weirdness related to the generated libtool)
>
> Seb.

I've found a timezone-related issue, sounds a bit different though: the
following resolves the error I had with tinderbox builds outside of
BST/UTC+1 timezone. The epoch time is hard-coded, so I shifted all logging
to UTC, but that uses the base/logging function, and might shift everyone's
log files off a few hours.

I can do this through configure.in if it's preferred. At least this is the
rootcause of the error I have been having.



Index: base/logging.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/nagios/nagios/base/logging.c,v
retrieving revision 1.41
diff -r1.41 logging.c
395c395
t=3Dgmtime(&rotation_time); /* see t-tap/var/nagios.log.expected, and a n=
ote
near t-tap/test_logging.c@81 look for "base/logging.c@395" */
cvs diff: Diffing t-tap
Index: t-tap/test_logging.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/nagios/nagios/t-tap/test_logging.c,v
retrieving revision 1.2
diff -r1.2 test_logging.c
79a80,88
> /*
> * this was UTC+1 or BST timezone working with base/logging.c@395:
t=3Dlocaltime(&rotation_time)
> * - not an error until they have to coincide. Problem is, this isn't an
error so long as the
> * Nagios server never changes timezones because the log files will alway=
s
be created in
> * local timezone, and rotated on local time. In effect, by putting an
epoch-based time
> * here, you're effectively requiring that all tinderbox servers be in th=
e
same timezone.
> * Switching to gmtime effectively neutralizes, but puts everyone in UTC,
which is an
> * hour off. Adjusting the epoch to match.
> *
80a90,91
> */
> rotation_time =3D (time_t)1242953298; /* + 3600 ,
t-tap/var/

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]