[Nagios-devel] Antwort: Re: Antwort: Re: Check becomes unplanned
Posted: Thu Sep 11, 2008 11:56 pm
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 002BA0DCC12574C2_=
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] schrieb am 11.09.2008 20:53:18:
> So although this is a bug, I wouldn't expect Nagios to work very well
> with time shifts and there's many other applications/daemons out there
> that could fail as well. You shouldn't have to constantly re-adjust the
> clock - if you do then there might me a bigger problem...
Of course it's a problem rooted somewhere deeper in the environment,
yet I don't think programs should suffer from it.
> Have you tried running an ntp daemon? It should try keeping the clock
> sync without causing time shifts (as Andreas explained, it slows down or
> speed up the clock instead). What OS is it on? under a VM? custom
> compiled kernel? There might be something broken or unsupported in your
> setup that causes this. If you don't fix it you shouldn't expect your
> system to work very well anyway.
Running ntpd won't help at all. The timeshifts happen because the
systemclock is running too fast. It doesn't really matter if you
adjust it back in little ticks or in one big bang once a day.
You can easily reproduce this with running an older 2.6 kernel
inside a VM using the clocksource=3Dpit kernelparameter. The systemclock
will be running 1 jitter too fast, resulting in 1 sec backshift like
every 5 minutes - either from ntpd or from the vmware-tools timesync.
The only workaround I can think of is running a
"/etc/init.d/nagios stop
ntpdate
/etc/init.d/nagios start"
once a day - which is quite ugly though.
> One thing that might help is setting this to 1 in your nagios.cfg. This
> will make Nagios periodically check for services that aren't scheduled:
>=20
> check_for_orphaned_services=3D1
Well, the problem is that the service IS scheduled - just 1 year ahead.
> Besides, to fix this I would make the sanity check reschedule the check
> for the end of the check period (possibly only if it's not scheduled
> already), as it wouldn't have to check for this condition for every
> service on every time shift.
Why for the end? You'll still lose like all checks then. It runs the check
once and then sleeps, because the check_period is not valid anymore. Then
the time shifts again - rinse and repeat. You'll end up with one check
each day for such services.
Regards
Sascha
--=20
Sascha Runschke
IT-Infrastruktur
GFKL Financial Services AG
Limbecker Platz 1
45127 Essen
Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201)=20
102-1102105
GFKL Financial Services AG
Vorstand: Dr. Peter J=C3=A4nsch (Vors.), J=C3=BCrgen Baltes, Dr. Till Ergen=
zinger, Dr. Tom Haverkamp
Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma
Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522
--=_alternative 002BA0DCC12574C2_=
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] schrieb
am 11.09.2008 20:53:18:
> So although this is a bug, I wouldn't expect Nagios to work very well
> with time shifts and there's many other applications/daemons out there=
> that could fail as well. You shouldn't have to constantly re-adjust
the
> clock - if you do then there might me a bigger problem...
Of course it's a problem rooted somewhere deeper in
the environment,
yet I don't think programs should suffer from it.
> Have you tried running an ntp daemon? It should try keeping the clock
> sync without causing time shifts (as Andreas explained, it slows down
or
> speed up the clock instead). What OS is it on? under a VM? custom
> compiled kernel? There might be something broken or unsupported in
your
> setup that causes this. If you don't fix it you shouldn't expect your
> system to work very well anyway.
</
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
--=_alternative 002BA0DCC12574C2_=
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] schrieb am 11.09.2008 20:53:18:
> So although this is a bug, I wouldn't expect Nagios to work very well
> with time shifts and there's many other applications/daemons out there
> that could fail as well. You shouldn't have to constantly re-adjust the
> clock - if you do then there might me a bigger problem...
Of course it's a problem rooted somewhere deeper in the environment,
yet I don't think programs should suffer from it.
> Have you tried running an ntp daemon? It should try keeping the clock
> sync without causing time shifts (as Andreas explained, it slows down or
> speed up the clock instead). What OS is it on? under a VM? custom
> compiled kernel? There might be something broken or unsupported in your
> setup that causes this. If you don't fix it you shouldn't expect your
> system to work very well anyway.
Running ntpd won't help at all. The timeshifts happen because the
systemclock is running too fast. It doesn't really matter if you
adjust it back in little ticks or in one big bang once a day.
You can easily reproduce this with running an older 2.6 kernel
inside a VM using the clocksource=3Dpit kernelparameter. The systemclock
will be running 1 jitter too fast, resulting in 1 sec backshift like
every 5 minutes - either from ntpd or from the vmware-tools timesync.
The only workaround I can think of is running a
"/etc/init.d/nagios stop
ntpdate
/etc/init.d/nagios start"
once a day - which is quite ugly though.
> One thing that might help is setting this to 1 in your nagios.cfg. This
> will make Nagios periodically check for services that aren't scheduled:
>=20
> check_for_orphaned_services=3D1
Well, the problem is that the service IS scheduled - just 1 year ahead.
> Besides, to fix this I would make the sanity check reschedule the check
> for the end of the check period (possibly only if it's not scheduled
> already), as it wouldn't have to check for this condition for every
> service on every time shift.
Why for the end? You'll still lose like all checks then. It runs the check
once and then sleeps, because the check_period is not valid anymore. Then
the time shifts again - rinse and repeat. You'll end up with one check
each day for such services.
Regards
Sascha
--=20
Sascha Runschke
IT-Infrastruktur
GFKL Financial Services AG
Limbecker Platz 1
45127 Essen
Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201)=20
102-1102105
GFKL Financial Services AG
Vorstand: Dr. Peter J=C3=A4nsch (Vors.), J=C3=BCrgen Baltes, Dr. Till Ergen=
zinger, Dr. Tom Haverkamp
Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma
Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522
--=_alternative 002BA0DCC12574C2_=
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] schrieb
am 11.09.2008 20:53:18:
> So although this is a bug, I wouldn't expect Nagios to work very well
> with time shifts and there's many other applications/daemons out there=
> that could fail as well. You shouldn't have to constantly re-adjust
the
> clock - if you do then there might me a bigger problem...
Of course it's a problem rooted somewhere deeper in
the environment,
yet I don't think programs should suffer from it.
> Have you tried running an ntp daemon? It should try keeping the clock
> sync without causing time shifts (as Andreas explained, it slows down
or
> speed up the clock instead). What OS is it on? under a VM? custom
> compiled kernel? There might be something broken or unsupported in
your
> setup that causes this. If you don't fix it you shouldn't expect your
> system to work very well anyway.
</
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]