[ntp:questions] Initial sync on starting ntpd with 20-21 minute time difference

[Karen Austin]

Hi,

We have a RH 6.8 server with ntpd installed, but not currently running.

The time on this server is showing around 20-21 minutes ahead.

The server has been restarted and the messages log shows a successful ntpd start, but it is no longer running.

I would like to attempt to manually start the daemon but am concerned that the local time will then 'jump' to the correct time, which may affect applications on the server.

Can anyone confirm that the time will sync gradually?

Many thanks






This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. If you are not the intended recipient, any use, disclosure, copying or forwarding of this email and/or its attachments is unauthorised. If you have received this email in error please notify the sender by email and delete this message and any attachments immediately. Nothing in this email shall bind the Company or any of its subsidiaries or businesses in any contract or obligation, unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, company number 02150618 and whose registered office is at 37 Carr Lane, Hull, HU1 3RE.

[Mike Cook]

Karen,

Post by Karen Austin
Hi,
We have a RH 6.8 server with ntpd installed, but not currently running.
The time on this server is showing around 20-21 minutes ahead.
The server has been restarted and the messages log shows a successful ntpd start, but it is no longer running.

This is normal as ntpd will bail out if the initial difference between the reference server and local clock is greater than 1000 seconds, or 16mins 40secs.
So if you restart the daemon it will just exit as before.

Post by Karen Austin
I would like to attempt to manually start the daemon but am concerned that the local time will then 'jump' to the correct time, which may affect applications on the server.

You could override this protection mechanism by using startup option -g , but the local clock will step to the correct time, with possible application issues. There is an option -x to prevent steps on time differences greater than 128ms, but the max time difference accounted for is 600s, which is too small for your issue.

Before restarting ntpd you could use ntpdate to set the clock using the -B option to slew, rather than step, the clock to the correct time before restarting ntpd, but your offset is so large (1260 secs), that this may take a long time to complete.

On an Arm/Linux system I have I did a test with your offset and my clock is slewing at a little over 0,025 secs per minute, so the correction will need around 14 hours to complete.

Mike

Post by Karen Austin
Can anyone confirm that the time will sync gradually?
Many thanks
This email has been scanned for all viruses.
Please consider the environment before printing this email.
The content of this email and any attachment is private and may be privileged. If you are not the intended recipient, any use, disclosure, copying or forwarding of this email and/or its attachments is unauthorised. If you have received this email in error please notify the sender by email and delete this message and any attachments immediately. Nothing in this email shall bind the Company or any of its subsidiaries or businesses in any contract or obligation, unless we have specifically agreed to be bound.
KCOM Group PLC is a public limited company incorporated in England and Wales, company number 02150618 and whose registered office is at 37 Carr Lane, Hull, HU1 3RE.
_______________________________________________
questions mailing list
http://lists.ntp.org/listinfo/questions

People have only as much liberty as they have the intelligence to want and the courage to take.

Emma Goldman

[Mike Cook]

Karen,

Post by Mike Cook
Before restarting ntpd you could use ntpdate to set the clock using the -B option to slew, rather than step, the clock to the correct time before restarting ntpd, but your offset is so large (1260 secs), that this may take a long time to complete.
On an Arm/Linux system I have I did a test with your offset and my clock is slewing at a little over 0,025 secs per minute, so the correction will need around 14 hours to complete.

My sums were wrong… at 0,025sec per minute, 1260 seconds correction takes (1260/0,025)/60/24 = 35 days

maybe too long for you.

Only other option , as Monty P suggests, is start again.
Boot it in single user mode to prevent ntpd starting. Reset the clock. Remove the ntp drift file . reboot.
That will probably fix it though I have known some cases where a power cycle is required as active frequency corrections were not reset by hardware on a normal boot cycle.

Post by Mike Cook
Mike

[Harlan Stenn]

Post by Karen Austin
Hi,
We have a RH 6.8 server with ntpd installed, but not currently running.
The time on this server is showing around 20-21 minutes ahead.
The server has been restarted and the messages log shows a successful ntpd st
art, but it is no longer running.

This is because of the 'panic gate' check I'll mention, below.

Post by Karen Austin
I would like to attempt to manually start the daemon but am concerned that th
e local time will then 'jump' to the correct time, which may affect applicati
ons on the server.
Can anyone confirm that the time will sync gradually?
Many thanks

ntpd will exit if the system time differs from 'upstream' time by more
than 1000 seconds (the panic gate).

There are startup options to slew time corrections instead of stepping
them. 'ntpd -x' will slew up to 600 seconds' difference. There are
config options to make this window longer, but note that ntpd will
correct these at the rate of 1 second in about 33 minutes' time, so a 20
minute correction will take over 660 hours' time to apply. That's more
than 27 days' time.

Forward time steps are generally 'safe'. Backward time steps are not,
as they violate ACID assumptions for databases.

We recommend the following startup sequence:

- Start ntpd as soon as possible in the boot process,
- Using the -g options *at cold-start only* to set the clock initially.
- Start all other applications that do not require sync'd time.
- run ntp-wait (perhaps with -v) to wait for the clock to sync.
- Start the applications that require sync'd time.

Note that depending on what this system is being used for, there might
be other considerations during the time the system clock is wrong. This
depends on how accurate your timestamping requirements are.