Make complains "warning: Clock skew detected." on NFS client
Dave
server. Until earlier today, the time on the NFS server was set with a
cron job ever hour, using ntpdate.
I changed that to use the ntp service, with a config file of
kirkby@t2:[~] $ cat /etc/inet/ntp.conf
driftfile /var/ntp/ntp.drift
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
I did the same on the NFS client (previously the clock on this was not
set at all, so was about 30 seconds out).
Since the time on the two machines is not very close, I'm seeing errors
from 'make' while compiling on the NFS client.
make[8]: warning: Clock skew detected. Your build may be incomplete.
There's also complaints from 'make' of files having modification times
in the future. The times are only ms in the future.
I suspect what is happening is something like.
* The two machines have ms differences between them - NTP is not perfect.
* Time stamp on the file is probably set by the NTP server.
* Make reads the time from the NFS client
What's the best way to solve this issue?
I thought that by actually having the machines at the right time (within
ms) would be a good thing. I seem to have created a problem I was not
expecting.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Dave
> I have a couple of machines. One x86 running Solaris 11 is an NFS
> server. Until earlier today, the time on the NFS server was set with a
> cron job ever hour, using ntpdate.
Not be me I would add!
> Since the time on the two machines is not very close, I'm seeing errors
> from 'make' while compiling on the NFS client.
Oops, that was supposed to be "Since the time on the two machines is
*now* very close".
Sine they both get their time from time servers, they obviously are
pretty close.
ThanksButNo
>
> Sine they both get their time from time servers, they obviously are
> pretty close.
>
I generally like to have one machine in charge of getting the
time from an external server, then all the other machines get
the time from it.
That way, if something happens to prevent connection to the
time server, at least all the machines on the LAN won't drift
away from each other. They might all be wrong, but at least
they're all wrong by the same amount.
\:-\
Dave
I can see some logic in that.
But my more pressing issue is what to do about the fact that Make is
complaining about minor time differences between machines. Here is one
such message. As you can see, the time is very small, but it could make
the difference between a source file being compiled and it not being
compiled.
make[7]: Warning: File `atlas_dr1.h' has modification time 0.14 s in the
future
Tony Curtis
That's the point of strata, isn't it? When I've been
responsible for this kind of thing, I'll take 2 machines
and designate them as e.g. time1 and time2 reading from
NTP pool servers. Internal machines slave from time1 and
time2.
In my last gig, we had about 100 NFS clients (Solaris,
Linux) and the only clock skew issue was with a loaned
pre-production machine that had some firmware problems.
hth
t
ji...@specsol.spam.sux.com
> ThanksButNo wrote:
>> On Jun 16, 5:23 pm, Dave <f...@coo.com> wrote:
>>
>>> Sine they both get their time from time servers, they obviously are
>>> pretty close.
>>>
>>
>> I generally like to have one machine in charge of getting the
>> time from an external server, then all the other machines get
>> the time from it.
>>
>> That way, if something happens to prevent connection to the
>> time server, at least all the machines on the LAN won't drift
>> away from each other. They might all be wrong, but at least
>> they're all wrong by the same amount.
>>
>> \:-\
>
> I can see some logic in that.
>
> But my more pressing issue is what to do about the fact that Make is
> complaining about minor time differences between machines. Here is one
> such message. As you can see, the time is very small, but it could make
> the difference between a source file being compiled and it not being
> compiled.
>
> make[7]: Warning: File `atlas_dr1.h' has modification time 0.14 s in the
> future
What does ntpq -p tell you?
--
Jim Pennino
Remove .spam.sux to reply.
Richard B. Gilbert
NTPD is slow to "converge". It may take several hours for all the
machines to be able to agree on what time it is. When everything
settles out, the two machines should be within a 50 or 100 microseconds
of each other. It helps to have a good "hardware reference clock"; e.g.
a GPS timing receiver; that rock solid source is easy to synchronize with.
Once you have synchronization, you should be able to keep it until one
or more of the machines are rebooted.
ji...@specsol.spam.sux.com
It will take a long time to settle to the correct time if ntp is started
without running ntpdate and the machine is more than a few seconds
from the correct time.
If ntpdate runs first, the time error will be in milliseconds.
> Once you have synchronization, you should be able to keep it until one
> or more of the machines are rebooted.
At which time ntpdate should run setting the booting machine to within
milliseconds of the correct time.
Tim Bradshaw
> make[7]: Warning: File `atlas_dr1.h' has modification time 0.14 s in the
> future
That's not close. NTP should get the times much, much closer than
that. Chances are it has not got them in sync yet. You can work
around this (if you do not care about steps) by:
* stopping NTP
* using ntpdate to get the time right
* restarting it.
The unknown warrior
Recent versions of NTP do call ntp date if the time is way out. One of
the machines I had was 30 seconds off. As soon as xntp started, it
called ntpdate. I don't know how much it will allow them to be off
before it calls ntp date.
Of course, even if the machine are set perfectly now, in a few minutes
the errors in the clocks will make them inaccurate. When they are next
compared to the time servers, ntp will work out the skew and continusly
adjust in future. Hence even after calling ntp date on all machiens, the
accuracy should improve further in the next few hours (days?).
The unknown warrior
You talk of having time1 and time2. I assume if you have 100 machines,
its sensible to not rely on just one, so I can see the need for having
two set from ntp servers.
But in my case, will setting say the NFS server from an external ntp
server, then setting the NFS client from the NTP server be best? Then
the two machines should hopefully differ by less than they would if they
both called the external servers.
Is that sufficent?
One worry of relying on them getting close enough with ntp running
extenral servers, is that if one is rebooted, ocols down, the clock
frequency will adjust somewhat more than usual, the errors between them
will increase and I'm back to having to wait for them to both get much
close. That is cleraly not a good long term solution.
So my basic question is that if one is set from an external server
(ntp.pool or similar) and others on the LAN from that machine, will that
be ok to avoid the nfs/make issues?
A basic config file for showing how to have a Sun work as both a server
and client would be handy if you have one, but if not I'm sure I can
work that out from a read of the ntp docs.
Dave
The unknown warrior
PS, I'm on the laptop, why my 'username' is differnet. I should change
that. But I'm the da...@foo.com who started the thread
The unknown warrior
As far as I am aware, ntpdate will be called automatically if the time
errors are large. xntpd has enough sence to know its a bit pointess
trying to correct a large difference, if there is a much quicker way to
get them close
Richard B. Gilbert
If make is counting milliseconds or microseconds then you need to either
do everything on one machine or synchronize your clocks to within
milliseconds or microseconds! The later is both difficult and time
consuming. An offset of less than ten milliseconds from "the one true
time" can be achieved without much difficulty. An offset of five
milliseconds or less is more difficult. One millisecond is far more
difficult than five and so on!
ji...@specsol.spam.sux.com
Not quite.
ntpdate won't run if ntp is running.
Most OS's in general, and Solaris in particular, are set up to run
ntpdate, which does an absolute set of the system clock no matter
what the error, before starting the xntpd demon.
Richard B. Gilbert
Ntpdate has been deprecated for at least a couple of years now! Recent
versions of Ntpd, V4.0 and later, have an option, "-g" that will cause
it to set the clock unconditionally at startup. (Solaris ships with a
very old version of Ntpd!
ji...@specsol.spam.sux.com
Yes, I know.
Since the original post was to comp.unix.solaris, I'm assuming the
poster is running Solaris, which uses ntpdate.
FWIW HP-UX also ships with a version of ntp that uses ntpdate.
But what has any of this to do with the original poster's problem?
The version of ntp bundled with Solaris works just fine if configured
correctly.
Tony Curtis
>> The unknown warrior <some-secr...@invalid.invalid> said:
> You talk of having time1 and time2. I assume if you have
> 100 machines, its sensible to not rely on just one, so I
> can see the need for having two set from ntp servers.
Well, about 100 *NFS* clients, there was a non-trivial
number of other machines, e.g. QFS nodes and standalone.
> But in my case, will setting say the NFS server from an
> external ntp server, then setting the NFS client from
> the NTP server be best? Then the two machines should
> hopefully differ by less than they would if they both
> called the external servers.
I've tended to operate things in what I call
"orthogonality"; machines that are directly
user-accessible do not do system/infrastructure things.
Machines that provide services like
DHCP/mail/DNS/print-server are "system" in this scheme,
and are not accessible to users via any persistent setup:
NFS mounts are persistent (server goes down, clients get
angry). DHCP/mail etc. are transactional operations and
persistence is not required (e.g. you can have multiple MX
servers to try in order).
So if possible what I would do here is take 2 machines
that might be providing services as above and set 2 (or
maybe more, depending on operational scale) of them up to
get their time from some outside source. (Heck,
virtualize if you want more isolation).
This source could be NTP pool servers and/or some "parent"
source (like a campus-wide NTP server). Then in this
scenario, the NFS server and all the clients would
synch. to the same local NTP servers.
Modulo the initial one-time clock skew that others have
addressed, you should see really close clocks in the
steady-state. And if your general operation mode isn't
"steady-state", you're doing something very wrong ;-)
> A basic config file for showing how to have a Sun work
> as both a server and client would be handy if you have
> one, but if not I'm sure I can work that out from a read
> of the ntp docs.
broadcast to local network, server to synch. with other
NTP servers. Don't forget a driftfile spec.
hth
t