Bob Proulx wrote:
> Ah... I had not ever seen ntpdate or rdate used for clock comparison
> before.
It really is a very useful tool for clock comparisons.
Chris
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.
Chris Angelico wrote:
> Bob Proulx wrote:
> > Rick Thomas wrote:
> >> Have you tried "rdate -np" ? It does the same thing (pretty much)
> >> as your "ntpdate -qu"
> >
> > The big problem with ntpdate and rdate is that they step the clock.
> > That is only appropriate at boot time.
>
> But -q mean
On Jun 13, 2014, at 12:18 AM, Chris Angelico wrote:
> On Fri, Jun 13, 2014 at 4:47 PM, Rick Thomas wrote:
>> If you want to compare the local clock with a remote system's clock (often
>> called "skew"), the best way I know is with "ntpdate -qu". The "offset" it
>> mentions is the difference be
On Fri, Jun 13, 2014 at 4:47 PM, Rick Thomas wrote:
> If you want to compare the local clock with a remote system's clock (often
> called "skew"), the best way I know is with "ntpdate -qu". The "offset" it
> mentions is the difference between your clock and the remote clock. Sadly,
> "rdate -n
On Jun 12, 2014, at 11:03 PM, Bob Proulx wrote:
> Why do you need to step the clock? It is better to install ntp and
> adjust the rate of the clock so that every tick is seen but adjusted
> to be in time with the rest of the world.
NTP, as configured by the default Debian package, also steps th
On Jun 12, 2014, at 11:11 PM, Chris Angelico wrote:
> On Fri, Jun 13, 2014 at 4:03 PM, Bob Proulx wrote:
>> Rick Thomas wrote:
>>> Have you tried "rdate -np" ? It does the same thing (pretty much)
>>> as your "ntpdate -qu"
>>
>> The big problem with ntpdate and rdate is that they step the cloc
On Fri, Jun 13, 2014 at 4:03 PM, Bob Proulx wrote:
> Rick Thomas wrote:
>> Have you tried "rdate -np" ? It does the same thing (pretty much)
>> as your "ntpdate -qu"
>
> The big problem with ntpdate and rdate is that they step the clock.
> That is only appropriate at boot time.
But -q means not
Rick Thomas wrote:
> Chris Davies wrote:
> > For day-to-day usage I would agree with your recommendation of ntp
> > to ntpdate. However, I have yet to find a useful alternative to
> > the very convenient "ntpdate -qu {server}". Is there one?
>
> Have you tried "rdate -np" ? It does the same thing
On Friday, June 13, 2014 5:30:01 AM UTC+5:30, Rick Thomas wrote:
> On Jun 9, 2014, at 7:19 PM, Rusi Mody wrote:
> > Ubuntu does not seem to have the 3 line structure of adjtime -- just 1 line.
> > In particular it does not have the UTC/LOCAL 3rd line:
> > # mount LABEL=Ubuntu64 /mnt/
> > # cat /m
On Friday, June 13, 2014 4:10:02 AM UTC+5:30, Bob Proulx wrote:
> Andrei POPESCU wrote:
> > If you have indeed a UTC vs. local problem you need to check
> > /etc/adjtime on all systems. If all files show the same ntp can take
> > care of your hardware clock.
> Try this and see if it says somethi
On Jun 9, 2014, at 7:19 PM, Rusi Mody wrote:
> Ubuntu does not seem to have the 3 line structure of adjtime -- just 1 line.
> In particular it does not have the UTC/LOCAL 3rd line:
>
>
> # mount LABEL=Ubuntu64 /mnt/
> # cat /mnt/etc/adjtime
> 0.0 0 0.0
> #
>
> Any ideas where to make the UT
On Jun 9, 2014, at 11:01 AM, Chris Davies wrote:
> Andrei POPESCU wrote:
>> ntpdate is obsolete, please remove (purge) it and install ntp.
>
> For day-to-day usage I would agree with your recommendation of ntp to
> ntpdate. However, I have yet to find a useful alternative to the very
> convenie
Andrei POPESCU wrote:
> If you have indeed a UTC vs. local problem you need to check
> /etc/adjtime on all systems. If all files show the same ntp can take
> care of your hardware clock.
Try this and see if it says something different between the two
different booted operating systems.
# hwcl
On Ma, 10 iun 14, 15:44:24, Chris Davies wrote:
> Andrei POPESCU wrote:
> > On Lu, 09 iun 14, 19:01:51, Chris Davies wrote:
> >> I have yet to find a useful alternative to the very convenient
> >> "ntpdate -qu {server}". Is there one?
>
> > Just by looking at manpages maybe 'sntp ' is what you're
2014-06-09 19:11 keltezéssel, Rusi Mody írta:
>> If you have indeed a UTC vs. local problem you need to check
>> /etc/adjtime on all systems. If all files show the same ntp can take
>> care of your hardware clock.
>
> Aha.There it is
> That seems to bring me closer to identifying the solution
>
Andrei POPESCU wrote:
> On Lu, 09 iun 14, 19:01:51, Chris Davies wrote:
>> I have yet to find a useful alternative to the very convenient
>> "ntpdate -qu {server}". Is there one?
> Just by looking at manpages maybe 'sntp ' is what you're looking
> for?
Thank you. They're similar enough that I'l
On Lu, 09 iun 14, 19:01:51, Chris Davies wrote:
> Andrei POPESCU wrote:
> > ntpdate is obsolete, please remove (purge) it and install ntp.
>
> For day-to-day usage I would agree with your recommendation of ntp to
> ntpdate. However, I have yet to find a useful alternative to the very
> convenient
On Monday, June 9, 2014 11:00:02 PM UTC+5:30, Rusi Mody wrote:
> On Monday, June 9, 2014 8:40:02 PM UTC+5:30, Andrei POPESCU wrote:
> > If you have indeed a UTC vs. local problem you need to check
> > /etc/adjtime on all systems. If all files show the same ntp can take
> > care of your hardware c
Andrei POPESCU wrote:
> ntpdate is obsolete, please remove (purge) it and install ntp.
For day-to-day usage I would agree with your recommendation of ntp to
ntpdate. However, I have yet to find a useful alternative to the very
convenient "ntpdate -qu {server}". Is there one?
Chris
--
To UNSUB
On Monday, June 9, 2014 8:40:02 PM UTC+5:30, Andrei POPESCU wrote:
>
> If you have indeed a UTC vs. local problem you need to check
> /etc/adjtime on all systems. If all files show the same ntp can take
> care of your hardware clock.
Aha.There it is
That seems to bring me closer to identifying
Rusi Mody writes:
> My guess is that in some cases the ntp stores the date in UTC in some
> in local.
Ntp never uses anything but UTC. Make sure your hardware clock is set
in UTC and that all your OSs are configured to assume that it is.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
Le 09/06/2014 17:07, Andrei POPESCU a écrit :
> On Lu, 09 iun 14, 05:33:20, Rusi Mody wrote:
>> I am a bit mystified by what I find:
>> Ive removed ntp and trying to only use ntpdate
>
> ntpdate is obsolete, please remove (purge) it and install ntp. Neither
> requires further configuration.
I w
On Lu, 09 iun 14, 05:33:20, Rusi Mody wrote:
>
> I am a bit mystified by what I find:
> Ive removed ntp and trying to only use ntpdate
ntpdate is obsolete, please remove (purge) it and install ntp. Neither
requires further configuration.
[snip ntpdate configuring]
> However if someone has a
On Mon, 9 Jun 2014 05:33:20 -0700 (PDT)
Rusi Mody wrote:
> Ive removed ntp and trying to only use ntpdate
You can't, you must use command line ntpdate-debian
(same pkg).
…
> So servers are not used because NTPDATE_USE_NTP_CONF is yes
>
> But I have no ntp and therefore no /etc/ntp.conf
So, c
On Monday, June 9, 2014 4:10:01 PM UTC+5:30, B wrote:
> On Sun, 8 Jun 2014 21:02:21 -0700 (PDT)
>
> Rusi Mody wrote:
>
>
> > Rebooting one and then another causes errors of
> > "superblock time in future"
>
>
>
> Either, as you've been told, you're not using the same
> setup (UTC|local) e
On Sun, 8 Jun 2014 21:02:21 -0700 (PDT)
Rusi Mody wrote:
> Rebooting one and then another causes errors of
> "superblock time in future"
Either, as you've been told, you're not using the same
setup (UTC|local) everywhere or this machine has a large
positive clock drift (ntp can take up to 11 min
2014-06-09 06:02 keltezéssel, Rusi Mody írta:
> I have a couple of debians (32 and 64 bit) and an ubuntu on different
> partitions.
>
> Rebooting one and then another causes errors of
> "superblock time in future"
>
> My guess is that in some cases the ntp stores the date in UTC in some in
> lo
27 matches
Mail list logo
