I have observed that the hardware clock is not set by ntp (or by the kernel) after ntp applies a time step.
Hardware clock is set to UTC:
# hwclock --debug
hwclock from util-linux 2.21.2
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
date
...got clock tick
Time read from Hardware Clock: 2013/08/29 08:28:12
Hw clock time : 2013/08/29 08:28:12 = 1377764892 seconds since 1969
Thu 29 Aug 2013 08:28:12 AM UTC -0.849115 seconds
# date
Thu Aug 29 08:30:42 UTC 2013
ntp seems to be well synchronized:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.219.219.1 16 u 11 16 0 0.000 0.000 0.000
SHM(0) .GPS. 6 l - 16 0 0.000 0.000 0.000
SHM(1) .PPS. 5 l - 16 0 0.000 0.000 0.000
*192.168.11.1 217.79.179.106 3 u 45 64 37 0.342 3.034 2.175
ntp config:
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
tos orphan 7
tos maxdist 6
tinker panic 0
tinker step 1.2
server 10.219.219.1 minpoll 4 maxpoll 8 iburst
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 stratum 6 time1 0.150 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4
fudge 127.127.28.1 stratum 5 refid PPS
server 192.168.11.1 maxpoll 8 iburst
keys /etc/ntp.keys
trustedkey 1
requestkey 1
In fact, the hardware clock is never set by NTP (that is, not directly). The system time (kernel time) is changed by NTP (and is always interpreted as being in millisecs since the epoch in UTC). The hardware clock is set during shutdown (in your case, not being involved in any Windows thingies, in UTC). This so the system at boot can pick up a reasonable (only reasonable because hardware clocks are not that precise) time setting. This time setting to be corrected asap as the network is up and NTP can be run.
The machine is a server machine which should run for very long. It has a watchdog which performs a hard reboot (using IPMI interface) in case some software is not running (it might be discussable if that’s good but at the moment it’s not possible to change that). So most likely the machine is not shut down clean and therefore the hardware clock is not set on shutdown.
What about the kernels “11 minute mode”? I thought the kernel would update the hardware clock each 11 minutes. Is that correct or not?
Which process (and under which conditions) sets the status bits of the adjtimex -p output. This should turn on/off the kernels 11 minute mode?
Have a look at those options in /etc/sysconfig/ntp:
## Type: boolean
## Default: "yes"
#
# Force time synchronization befor start ntpd
#
NTPD_FORCE_SYNC_ON_STARTUP="yes"
## Type: boolean
## Default: "no"
#
# Force time synchronization of hwclock befor start ntpd.
# This works only if NTPD_FORCE_SYNC_ON_STARTUP is set
# to yes.
#
NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes"
Set both of them to “yes” and ntp should synchronize the hwclock on boot.
What does the comment to NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP mean?
# Force time synchronization of hwclock befor start ntpd.
# This works only if NTPD_FORCE_SYNC_ON_STARTUP is set
# to yes.
Before starting ntpd synchronize to a time source (which one?) and then set this synchronized time to hwclock?
or: use the system time and set this to the hardware clock before starting ntpd?
??
Point 1 would make sense for my situation.
Point 2 would be completely useless for me. Example: The hardware clock is 1h off. The system is rebooted e.g. by a power fault. Then the bad time from the hardware clock is used.
What does the comment to NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP mean?
Before starting ntpd synchronize to a time source (which one?) and then set this synchronized time to hwclock?
or: use the system time and set this to the hardware clock before starting ntpd?
??
Well, have a look yourself in /etc/init.d/ntp!
In short: If NTPD_FORCE_SYNC_ON_STARTUP is set to yes, “/etc/init.d/ntp start” calls “/etc/init.d/ntp ntptimeset”, which synchronizes the system time and calls update_cmos afterwards which should set the hwclock if NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP is yes.
So it behaves like your point 1.
The time sources are taken from /etc/ntp.conf of course.
What output do you get, when you call “/etc/init.d/ntp ntptimeset” manually?
What’s the content of /etc/adjtime?
Does it work when you call “hwclock -w --debug”, i.e. is the hwclock adjusted then? What output do you get?
And I just tried it: “/etc/init.d/ntp ntptimeset” correctly sets the RTC on my 12.3 system. So at least it’s not a general problem.
/etc/init.d/ntp ntptimeset takes the first reachable and non local server from /etc/ntp.conf.
include statements in the /etc/ntp.conf are not considered. If you have all servers in an include file /etc/init.d/ntp ntptimeset does not work.
In my case the server in /etc/ntp.conf are not reachable and therefore /etc/init.d/ntp ntptimeset has no effect. Only the server in an included file (which I merged in my posting) is reachable.
Ok, so that explains why NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP=“yes” does not work for me.
Anyhow I would be very interested why the kernel 11 minute mode does not work and/or why the adjtimex status bit 64 is not cleared by ntp.
wolfi323 wrote:
> uvoigt;2581737 Wrote:
>> Anyhow I would be very interested why the kernel 11 minute mode does not
>> work and/or why the adjtimex status bit 64 is not cleared by ntp.
> I have no idea about that, sorry.
> But apparently the kernel only adjusts the hardware clock only if it is
> less than a maximum amount of time off, see here f.e.: ‘What is the
> largest hardware clock update the Linux kernel “11-minute mode” can
> make? - Server Fault’ (http://tinyurl.com/oo2bmmv)
>
> So if the clock is 1 hr off, that may be too big and the kernel doesn’t
> adjust it then…
The top three hits from google “linux kernel 11 minute mode” might be useful
On 2013-08-29 17:57, uvoigt wrote:
>
> I forgot to mention:
>
> It’s a single boot system. So no problem with a dual boot Windows
> installation.
> The local timezone of the system is UTC.
What is
/etc/sysconfig/clock:
USE_HWCLOCK
HWCLOCK
If the later is not “-u” then cmos clock is not set.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Thanks! I already read them but I didn’t find a hint who (re)sets the adjtimex status bits.
Ok, I learned that the 11 minute mode works only if the time is less than 15 minutes off. Mmh sounds good for the desktop but it’s not useful in the real world.
I have decided now to write my own cron job that checks once a minute if ntp has performed a time step. In such a case the hardware clock is synchronized from the cron job. It’s quite unbelievable for me that such a thing need to be coded by myself…
By the way: I also turned off NTPD_FORCE_SYNC_ON_STARTUP and NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP because I cannot rely that the first server in my ntp.conf is a good one. That’s ok.
Anyhow I have decided to disable that due to the fact that I don’t know which ntp server is a good one and which gives a bad time. (The same configuration is used by serveral machines round the world at several different customers…)
ntp does a great job to identify a good time server from a list of time servers but the one shot synchronization at start up obviously cannot achieve this.
Then I seem not to understand your problem. When there is (almost) never a reboot, then of course the hardware clock is not set. But as the hardware clock is only needed to keep time during the shutdown time, what to bother about? It will be set on next shutdown (2015?), but it is not needed earlier.
Maybe I have to add that I did not read your whole first post here, let alone made an assessment of it. I acted seeing your title, the main statment about your problem, and IMHO it showed a wrong starting point of some strain of thoughts. Thus I tried to explain that. Not reading the post in fact, because when the starting point is incorrect …
hcvv wrote:
> uvoigt;2581695 Wrote:
>> The machine is a server machine which should run for very long. It has a
>> watchdog which performs a hard reboot (using IPMI interface) in case
>> some software is not running (it might be discussable if that’s good but
>> at the moment it’s not possible to change that). So most likely the
>> machine is not shut down clean and therefore the hardware clock is not
>> set on shutdown.
>>
> Then I seem not to understand your problem. When there is (almost) never
> a reboot, then of course the hardware clock is not set. But as the
> hardware clock is only needed to keep time during the shutdown time,
> what to bother about? It will be set on next shutdown (2015?), but it is
> not needed earlier.
No, you’ve missed the point that the OP made again in the bit that you
quote:
>> So most likely the machine is not shut down clean and therefore the
>> hardware clock is not set on shutdown.
He expects the machine to be brought down forcibly most of the time, so
the normal hwclock update will not take place. So it needs to be kept
reasonably accurate all the time the machine is running.
I don’t understand the actual problem though. Even if the apparent
automatic mechanism isn’t working, a simple cron job ought to answer the
requirement.
Sometimes it’s hard to start with a good explanation of the problem.
So all in all I have to understand the interaction between ntpd, hwclock and the kernel 11 minute mode.
Most of it has been explained by this thread so thank’s a lot!!
One more try to explain my real problem just for the sake of completeness:
Some applications on my server have problems with time steps > 1 minute. This causes a hard reset of the server.
When the hardware clock time is more than 1 minute off the server starts with the hardware clock and ntpd will correct that. But that causes a time step > 1 minute which causes a hard reset of the server.
In this case the hardware clock was never set because the server was never shutted down cleanly. So the procedure continues forever.
I aggree if you say the problem is that my application cannot handle time steps > 1 minute but that’s not solvable at the moment.
On 2013-08-30 09:06, uvoigt wrote:
>
> robin_listas;2581807 Wrote:
>
> So there is no variable HWCLOCK…
So I’m seeing, the variable has been removed recently. I’m asking about
that in the mail list, because the ntp init script does use that
variable, which does not exist.
What’s the content of the /etc/adjtime file, then?
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
uvoigt wrote:
> One more try to explain my real problem just for the sake of
> completeness:
> Some applications on my server have problems with time steps > 1 minute.
> This causes a hard reset of the server.
> When the hardware clock time is more than 1 minute off the server starts
> with the hardware clock and ntpd will correct that. But that causes a
> time step > 1 minute which causes a hard reset of the server.
>
> In this case the hardware clock was never set because the server was
> never shutted down cleanly. So the procedure continues forever.
>
> I aggree if you say the problem is that my application cannot handle
> time steps > 1 minute but that’s not solvable at the moment.
So just to check that I’ve understood the problem:
When your system starts (and assuming it wasn’t shut down cleanly) your
application starts, then ntp starts and changes the time by more than
one minute, and then your application causes the server to reset.
If that’s the problem then there seem to be at least three solutions:
(1) make sure that NTP starts and synchronizes before your applications
are allowed to start
(2) write a cron job that writes the current system time to the hardware
clock every hour (or whatever time interval is reasonable)
(3) figure out what is wrong with the system you believe should take
care of it automatically
> Sometimes it’s hard to start with a good explanation of the problem.
>
> So all in all I have to understand the interaction between ntpd, hwclock
> and the kernel 11 minute mode.
You could try the mail list. I was just “talking” with the chap that
does the coding of the openSUSE clock scripts.
> Most of it has been explained by this thread so thank’s a lot!!
>
> One more try to explain my real problem just for the sake of
> completeness:
> Some applications on my server have problems with time steps > 1 minute.
> This causes a hard reset of the server.
Oh.
> When the hardware clock time is more than 1 minute off the server starts
> with the hardware clock and ntpd will correct that. But that causes a
> time step > 1 minute which causes a hard reset of the server.
Oh
> In this case the hardware clock was never set because the server was
> never shutted down cleanly. So the procedure continues forever.
Mmmm…
> I aggree if you say the problem is that my application cannot handle
> time steps > 1 minute but that’s not solvable at the moment.
Well, you might delay starting your application till after the clock has
been appropriately set. There are other applications in Linux that die
if the clock changes a lot - for instance, dovecot.
At boot, the clock has to be set with as big a step as needed. Later on,
ntpd only changes the speed of the clock so that it catches the correct
time - in time.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
