Quote:
Code:
ps -ef | grep ntpd Quote:
Code:
grep ntp /etc/dhcpcd.conf |
Quote:
I couldn't find any option to disable this feature without recompiling the kernel. I am not a fan of building my own kernel as it is too much maintenance work for me. What are other who are not affected doing? |
Quote:
|
I hope that does fix it Pat as I just got hit by this little kernel addition and if you also run your own DNS as I do dnssec will fall in a heap and it is pretty much a requirement these days.
|
I'd encourage folks to run their hw clock on UTC if at all possible and only use 'localtime' if absolutely necessary. It's clearly the way the system is intended to be used and avoids these sorts of issues.
If you dual-boot with Windows there's a registry entry you can change to make it also treat the hardware clock as UTC which is what I've done here. |
Quote:
|
It does seem to be the issue. I switched to running all of my systems using UTC for the hardware clock a while ago using similar logic as Gazl.
|
I wouldn't call it necessary, however I would rather have my hardware clock set to localtime. Since the kernel does not do localtime, then this option should read:
Quote:
|
Running the new kernel and the new options are right :-
Code:
root@indigo:/proc# zcat config.gz | grep RTC Code:
Fri Oct 4 21:46:34 EST 2013 Pulled the code from the kernel it it is :- Code:
#if defined(CONFIG_GENERIC_CMOS_UPDATE) || defined(CONFIG_RTC_SYSTOHC) EDIT2 Remove the offending config setting which is actually deprecated, the new option we've been talking about replaces this one Code:
--- arch/x86/Kconfig.old 2013-10-04 22:47:31.925835050 +1000 |
Hi All,
grabbed this part from arch linux Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing). These will generate /etc/adjtime automatically; no further configuration is required. During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of /sys/class/rtc/rtcN/hctosys (N=0,1,2,..) will be set to 1. Later, the system clock is set again from the hardware clock from systemd/udev, dependent on values in /etc/adjtime. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea. so indeed the option of wildwizard is the other option that needs to be killed :) |
Quote:
|
From 'man hwclock' (Bold emphasis is mine)
Code:
Automatic Hardware Clock Synchronization By the Kernel |
I have been looking at /usr/src/linux/kernel/time/ntp.c
As I read it, if you turn off both CONFIG_GENERIC_CMOS_UPDATE and CONFIG_RTC_SYSTOHC, then the "11 minute mode" will be entirely turned off. |
Yep it looks like the new RTC stuff is only part of the story and there's a second mechanism at play here.
Here's some background info I stumbled upon: https://lkml.org/lkml/2013/4/23/690 The interesting thing is that ntp.c contains this: Code:
getnstimeofday(&now); This whole area looks like a big mess. Maybe the latest util-linux might help?, but to be honest I'm inclined to go back to my previous suggestion which echoes one of the comments in kernel/time.c: Code:
|
I just encountered this on a -current machine after overnight extended power failure.
Nothing new to offer, but thanks for all who have posted - gives me an easier start! |
All times are GMT -5. The time now is 02:54 AM. |