On 24. September 2013 at 10:56:07, danta (merte...@axsguard.net) wrote:
We have some problems using collectd and ntpd.
Whenever ntpd sets the clock in the past (because of a clock drift),
collectd sleeps until it is back at it's 'normal' time.
To give an example:
- Suppose it's 10:00am,
- ntpd
Hi Dave,
We see the problem on virtual machines, where the host machine has it's
clock set to the local time. I realize this is a wrong setup but
unfortunately we can't change the settings on the host machine. Also the
host clock seems rather unstable, leading to large drifts if the ntpd
On 24. September 2013 at 12:12:15, danta (merte...@axsguard.net) wrote:
Hi Dave,
We see the problem on virtual machines, where the host machine has it's
clock set to the local time. I realize this is a wrong setup but
unfortunately we can't change the settings on the host machine. Also the
host
Hello,
I have already noticed this problem too.
Forget about ntpd. Some may try to understand what ntpd has to do with
it and maybe suggest solutions for ntpd. The problem is the time on the
machine.
How to reproduce :
0/ disable ntpd (so you can see that there is nothing to do with ntpd)
1/
On 9/24/2013 4:53 AM, danta wrote:
We have some problems using collectd and ntpd.
Whenever ntpd sets the clock in the past (because of a clock drift),
collectd sleeps until it is back at it's 'normal' time.
To give an example:
- Suppose it's 10:00am,
- ntpd sees a large clock drift and set the
Hello Lode,
On Tue, Sep 24, 2013 at 10:53:02AM +0200, danta wrote:
Whenever ntpd sets the clock in the past (because of a clock drift),
collectd sleeps until it is back at it's 'normal' time.
When trying to debug the problem, we found that the do_loop function
in collectd.c determines the