hard crash on leap second
Travis Crump
Hash: SHA1
I had a hard crash of my lenny system precisely when the leap second was
added. While X has flaked in the past, I've never had a hard crash
before. I have no other evidence they were related, but I wasn't doing
anything unusual at the time. Any ideas?
Travis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklcDXUACgkQlxHEcbyY0snlQQCgukkCFBv27AxFDOASyYms+rEL
4N4AnjUlpmyctVeJ/pXXzmfQuf5Q/Lom
=IxRA
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
>
> I had a hard crash of my lenny system precisely when the leap second was
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
That *is* unusual, since my mobo loses about 0.5 seconds every three
hours, reset by ntpdate every time.
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Justin Piszcz
System Events
=-=-=-=-=-=-=
Dec 31 18:59:59 p34 kernel: [38776.165550] Clock: inserting leap second 23:59:60 UTC
No issue here, "X has flaked in the past" -- how? Coincidence? X should
not flake. Bad memory? Have you run memtest?
Justin.
Frank Lanitz
Travis Crump <pret...@techhouse.org> wrote:
> I had a hard crash of my lenny system precisely when the leap second
> was added. While X has flaked in the past, I've never had a hard
> crash before. I have no other evidence they were related, but I
> wasn't doing anything unusual at the time. Any ideas?
No problems over here. Are there any entries in syslog?
Cheers,
Frank
--
http://frank.uvena.de/en/
Ken Irving
>
> I had a hard crash of my lenny system precisely when the leap second was
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
Could you clarify when this happened? Your message has a timestamp of
07:25:25PM -0500, but I thought the leap second was to be applied at
midnight. Or maybe you're referring to a system in another timezone?
I'm just curious, and have no particular insight on the problem. I'm
expecting to see an additional second of error in the clocks of some
systems I manage via radio telemetry, but wasn't expecting anything
like you describe.
Ken
--
Ken Irving
Ron Johnson
[snip]
>
> System Events
> =-=-=-=-=-=-=
> Dec 31 18:59:59 p34 kernel: [38776.165550] Clock: inserting leap second
> 23:59:60 UTC
Why don't I see this in my syslog or dmesg?
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Ken Irving
> On Wed, Dec 31, 2008 at 07:25:25PM -0500, Travis Crump wrote:
> >
> > I had a hard crash of my lenny system precisely when the leap second was
> > added. While X has flaked in the past, I've never had a hard crash
> > before. I have no other evidence they were related, but I wasn't doing
> > anything unusual at the time. Any ideas?
>
> Could you clarify when this happened? Your message has a timestamp of
> 07:25:25PM -0500, but I thought the leap second was to be applied at
> midnight. Or maybe you're referring to a system in another timezone?
Duh... Of course this was done at midnight UTC. I see in my logs:
Dec 31 14:59:59 isto kernel: Clock: inserting leap second 23:59:60 UTC
Ron Johnson
> On Wed, Dec 31, 2008 at 04:02:03PM -0900, Ken Irving wrote:
>> On Wed, Dec 31, 2008 at 07:25:25PM -0500, Travis Crump wrote:
>>> I had a hard crash of my lenny system precisely when the leap second was
>>> added. While X has flaked in the past, I've never had a hard crash
>>> before. I have no other evidence they were related, but I wasn't doing
>>> anything unusual at the time. Any ideas?
>> Could you clarify when this happened? Your message has a timestamp of
>> 07:25:25PM -0500, but I thought the leap second was to be applied at
>> midnight. Or maybe you're referring to a system in another timezone?
>
> Duh... Of course this was done at midnight UTC. I see in my logs:
>
> Dec 31 14:59:59 isto kernel: Clock: inserting leap second 23:59:60 UTC
Do you run ntp?
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Douglas A. Tutty
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
I don't know, but I forgot about the leap second thing. It may explain
why my mirror (ftp3.nrc.ca) stopped working about 7 pm Eastern. I'm
trying with another mirror now and having troubles.
Ken Irving
> On 12/31/08 19:19, Ken Irving wrote:
>> On Wed, Dec 31, 2008 at 04:02:03PM -0900, Ken Irving wrote:
>>> On Wed, Dec 31, 2008 at 07:25:25PM -0500, Travis Crump wrote:
>>>> I had a hard crash of my lenny system precisely when the leap second was
>>>> added. While X has flaked in the past, I've never had a hard crash
>>>> before. I have no other evidence they were related, but I wasn't doing
>>>> anything unusual at the time. Any ideas?
>>> Could you clarify when this happened? Your message has a timestamp
>>> of 07:25:25PM -0500, but I thought the leap second was to be applied
>>> at
>>> midnight. Or maybe you're referring to a system in another timezone?
>>
>> Duh... Of course this was done at midnight UTC. I see in my logs:
>>
>> Dec 31 14:59:59 isto kernel: Clock: inserting leap second 23:59:60 UTC
>
> Do you run ntp?
Yes.
--
Ken Irving
Ron Johnson
> On Wed, Dec 31, 2008 at 07:48:41PM -0600, Ron Johnson wrote:
>> On 12/31/08 19:19, Ken Irving wrote:
>>> On Wed, Dec 31, 2008 at 04:02:03PM -0900, Ken Irving wrote:
>>>> On Wed, Dec 31, 2008 at 07:25:25PM -0500, Travis Crump wrote:
>>>>> I had a hard crash of my lenny system precisely when the leap second was
>>>>> added. While X has flaked in the past, I've never had a hard crash
>>>>> before. I have no other evidence they were related, but I wasn't doing
>>>>> anything unusual at the time. Any ideas?
>>>> Could you clarify when this happened? Your message has a timestamp
>>>> of 07:25:25PM -0500, but I thought the leap second was to be applied
>>>> at
>>>> midnight. Or maybe you're referring to a system in another timezone?
>>> Duh... Of course this was done at midnight UTC. I see in my logs:
>>>
>>> Dec 31 14:59:59 isto kernel: Clock: inserting leap second 23:59:60 UTC
>> Do you run ntp?
>
> Yes.
That's why I didn't see it, then, since I run ntpdate every three
hours. But that's probably also what the -0.56 second step is at 18:03.
$ sudo grep 'time server' /var/log/syslog
Dec 31 09:03:02 haggis ntpdate[3653]: adjust time server 68.0.14.76
offset 0.438687 sec
Dec 31 12:03:02 haggis ntpdate[7156]: adjust time server 68.0.14.76
offset 0.439682 sec
Dec 31 15:03:01 haggis ntpdate[8467]: adjust time server 68.0.14.76
offset 0.439121 sec
Dec 31 18:03:01 haggis ntpdate[9521]: step time server 68.0.14.76
offset -0.562385 sec
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Ron Johnson
> On Wed, Dec 31, 2008 at 07:25:25PM -0500, Travis Crump wrote:
>> I had a hard crash of my lenny system precisely when the leap second was
>> added. While X has flaked in the past, I've never had a hard crash
>> before. I have no other evidence they were related, but I wasn't doing
>> anything unusual at the time. Any ideas?
>
> I don't know, but I forgot about the leap second thing. It may explain
> why my mirror (ftp3.nrc.ca) stopped working about 7 pm Eastern. I'm
> trying with another mirror now and having troubles.
See if your ISP has a timeserver. For example, mine is ntp.cox.net.
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Nate Bargmann
> On 12/31/08 18:49, Justin Piszcz wrote:
> [snip]
>>
>> System Events
>> =-=-=-=-=-=-=
>> Dec 31 18:59:59 p34 kernel: [38776.165550] Clock: inserting leap second
>> 23:59:60 UTC
>
> Why don't I see this in my syslog or dmesg?
Dunno. It's in this machine's syslog. Do you have NTP running as a
daemon?
After the insertion this machine was in lock-step with WWV on 2.5 MHz
while my LaCrosse "atomic" clock took 8 or 9 minutes to resync with
WWVB and was one second "fast".
HNY!
- Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html
Ken Irving
I see the same as that in a machine running ntpdate. I used to mainly use
ntpdate, but saw lots of references (though I have no citations to offer)
recommending ntp over ntpdate, and find that it *just works" now when I set
up a machine.
Ken
--
Ken Irving
Nate Bargmann
> I see the same as that in a machine running ntpdate. I used to mainly use
> ntpdate, but saw lots of references (though I have no citations to offer)
> recommending ntp over ntpdate, and find that it *just works" now when I set
> up a machine.
Until earlier this year I was running ntpdate as well, but found
differences of a few to a few tens of seconds between my machines.
After installing ntp, they are in sync with each other as expected.
- Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html
John Hasler
> See if your ISP has a timeserver.
Debian has time servers:
0.debian.pool.ntp.org
1.debian.pool.ntp.org
2.debian.pool.ntp.org
3.debian.pool.ntp.org
--
John Hasler
Ron Johnson
> Ron Johnson writes:
>> See if your ISP has a timeserver.
>
> Debian has time servers:
>
> 0.debian.pool.ntp.org
> 1.debian.pool.ntp.org
> 2.debian.pool.ntp.org
> 3.debian.pool.ntp.org
Right, but your ISP's time server is "closer".
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Vincent Bernat
Crump <pret...@techhouse.org> disait :
> I had a hard crash of my lenny system precisely when the leap second was
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
Hi!
Which kernel do you use?
It is a known problem on 2.6.21 but may appear on any kernel before
2.6.21.6. See:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg00714.html
http://lkml.org/lkml/2007/7/3/103
It should not happen on Lenny kernel (2.6.26).
--
#define BB_STAT2_TMP_INTR 0x10 /* My Penguins are burning.
Are you able to smell it? */
2.2.16 /usr/src/linux/include/asm-sparc/obio.h
Bob Cox
> Ron Johnson writes:
> > See if your ISP has a timeserver.
>
> Debian has time servers:
>
> 0.debian.pool.ntp.org
> 1.debian.pool.ntp.org
> 2.debian.pool.ntp.org
> 3.debian.pool.ntp.org
These are all aliases for 0.pool.ntp.org, 1.pool.ntp.org and so on.
It's probably best to use servers as close to you as possible - maybe
your ISP's if it exists, or, for example in Europe, the relevant ones
from this list: http://www.pool.ntp.org/zone/europe.
John - in your case it looks like your ISP is CenturyTel and they appear
to have a timeserver running on ntp0.centurytel.net - although as this is an
alias for time-c.timefreq.bldrdoc.gov (at NIST in Boulder) it may not be
exactly on your doorstep. (It's easy to forget how huge your country is
from over here).
I use a UK ISP called Zen, and my list of servers is:
server ntp0.zen.co.uk
server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org
The resulting current list of peers is interesting:
bob@gaia:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp0.zen.co.uk 195.66.241.3 2 u 803 1024 377 31.644 1.352 0.117
-ntp.sinodun.org 130.159.196.118 3 u 746 1024 377 52.359 2.796 0.027
*ntp4.ja.net .DCFa. 1 u 859 1024 377 39.036 1.115 0.018
+ntp1.arse.org 195.66.241.10 2 u 790 1024 377 37.877 1.609 0.344
-ginny.provu.co. 213.2.4.80 4 u 839 1024 377 45.955 -0.677 0.606
It seems that ntp4.ja.net is preferred to ntp0.zen.co.uk despite the
longer delay, presumably because it's a stratum 1 server? TBH I don't
know: it 'just works' most of the time.
Yes, that third listed peer does have an usual domain name ;-)
--
Bob Cox. Stoke Gifford, near Bristol, UK.
Please reply to the list only. Do NOT send copies directly to me.
Debian on the NSLU2: http://bobcox.com/slug/
Bob Cox
> Yes, that third listed peer does have an usual domain name ;-)
Oops. Fourth.
Barry Samuels
>
> I had a hard crash of my lenny system precisely when the leap second
> was added. While X has flaked in the past, I've never had a hard
> crash before. I have no other evidence they were related, but I
> wasn't doing anything unusual at the time. Any ideas?
>
> Travis
My system, which runs 24 hours a day, also crashed at around, I
suspect, midnight. I run Testing/Lenny and this machine has been stable
for a number of years.
The latest entry in any of the logs is in syslog:
Dec 31 23:57:58 dataman1 -- MARK --
There is nothing after that and there is, apparently, nothing untoward
in the logs.
This morning the machine was totally unresponsive to mouse and
keyboard. Trying to connect via ssh failed - no route to host and the
magic sysrq keys had no effect.
The timing does seem to be significant.
--
Barry Samuels
http://www.beenthere-donethat.org.uk
The Unofficial Guide to Great Britain
Vincent Lefevre
> On 12/31/08 18:49, Justin Piszcz wrote:
> [snip]
>>
>> System Events
>> =-=-=-=-=-=-=
>> Dec 31 18:59:59 p34 kernel: [38776.165550] Clock: inserting leap second
>> 23:59:60 UTC
>
> Why don't I see this in my syslog or dmesg?
Since it's a kernel message, it's at least in /var/log/kern.log, and
I have that one too:
Jan 1 00:59:59 ay kernel: [220491.482702] Clock: inserting leap second 23:59:60 UTC
But I hadn't any crash here.
BTW, I could also see:
$ while true; do TZ=UTC date; sleep 1; done
[...]
Wed Dec 31 23:59:58 UTC 2008
Wed Dec 31 23:59:59 UTC 2008
Wed Dec 31 23:59:59 UTC 2008
Thu Jan 1 00:00:00 UTC 2009
Thu Jan 1 00:00:01 UTC 2009
Thu Jan 1 00:00:02 UTC 2009
Happy new year!
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre
> Until earlier this year I was running ntpdate as well, but found
> differences of a few to a few tens of seconds between my machines.
> After installing ntp, they are in sync with each other as expected.
Yes, IIRC if the difference is too large, ntp doesn't fix the date.
I use both too on my laptop.
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Paul Cartwright
> > Dec 31 18:03:01 haggis ntpdate[9521]: step time server 68.0.14.76 offset
> > -0.562385 sec
>
> I see the same as that in a machine running ntpdate. I used to mainly use
> ntpdate, but saw lots of references (though I have no citations to offer)
> recommending ntp over ntpdate, and find that it *just works" now when I set
> up a machine.
I didn't realize we had a choice..
mine looks like this:
grep ntp /var/log/syslog
Dec 31 12:35:47 paulandcilla ntpd[3701]: clock is now synced
Dec 31 12:43:39 paulandcilla ntpd[3700]: adjusting local clock by -0.176692s
Dec 31 15:41:23 paulandcilla ntpd[3701]: peer 207.5.137.134 now invalid
Dec 31 15:49:56 paulandcilla ntpd[3701]: peer 209.67.219.106 now invalid
Dec 31 15:53:50 paulandcilla ntpd[3701]: peer 64.247.17.250 now valid
Dec 31 16:00:16 paulandcilla ntpd[3701]: peer 64.247.17.250 now invalid
Dec 31 16:02:21 paulandcilla ntpd[3701]: peer 209.104.4.227 now valid
Dec 31 16:13:01 paulandcilla ntpd[3701]: peer 72.52.190.26 now valid
Dec 31 19:30:37 paulandcilla ntpd[3700]: adjusting local clock by -0.689160s
Dec 31 19:34:18 paulandcilla ntpd[3700]: adjusting local clock by -0.511293s
Dec 31 19:34:18 paulandcilla ntpd[3701]: clock is now unsynced
Dec 31 19:38:42 paulandcilla ntpd[3700]: adjusting local clock by -0.257269s
Dec 31 19:42:34 paulandcilla ntpd[3700]: adjusting local clock by -0.473127s
Dec 31 19:44:52 paulandcilla ntpd[3700]: adjusting local clock by 0.136218s
Dec 31 19:56:37 paulandcilla ntpd[3700]: adjusting local clock by -0.344708s
Dec 31 19:56:37 paulandcilla ntpd[3701]: clock is now synced
Dec 31 19:59:46 paulandcilla ntpd[3700]: adjusting local clock by -0.174025s
Dec 31 19:59:46 paulandcilla ntpd[3701]: clock is now unsynced
Dec 31 20:07:27 paulandcilla ntpd[3701]: clock is now synced
Dec 31 20:56:19 paulandcilla ntpd[3700]: adjusting local clock by -0.159575s
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Cameron Hutchison
>I had a hard crash of my lenny system precisely when the leap second was
>added. While X has flaked in the past, I've never had a hard crash
>before. I have no other evidence they were related, but I wasn't doing
>anything unusual at the time. Any ideas?
I have a lenny and sid system, oth of which are still running OK.
I am running openntpd on both, synced to my border router (openwrt),
also still running and running openntpd.
My logs show openntpd drifting the time back into sync from the leap
second.
Paul Cartwright
> Since it's a kernel message, it's at least in /var/log/kern.log, and
> I have that one too:
>
> Jan 1 00:59:59 ay kernel: [220491.482702] Clock: inserting leap second
> 23:59:60 UTC
>
> But I hadn't any crash here.
I grepped for 59:59 in all logs and found nothing. my kern.log stops at
54268 2008-12-31 17:16 kern.log
here's my time:
date
Thu Jan 1 08:11:02 EST 2009
what time do you have??
(that's a joke..)
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
John Hasler
> See if your ISP has a timeserver.
I wrote:
> Debian has time servers:
>
> 0.debian.pool.ntp.org
> 1.debian.pool.ntp.org
> 2.debian.pool.ntp.org
> 3.debian.pool.ntp.org
Ron Johnson writes:
> Right, but your ISP's time server is "closer".
That only matters if you have a particular need to synchronise precisely
with your ISP. And ISP servers are often unreliable.
--
John Hasler
Bob Cox
Are you on a dial-up connection Paul? If so, that may explain the
losses of sync.
This is what I see here:
gaia:~# grep ntp /var/log/syslog
Jan 1 06:53:07 gaia ntpd[1611]: kernel time sync status change 0001
Jan 1 07:44:21 gaia ntpd[1611]: kernel time sync status change 4001
Jan 1 08:01:24 gaia ntpd[1611]: kernel time sync status change 0001
Jan 1 08:52:39 gaia ntpd[1611]: kernel time sync status change 4001
Jan 1 09:09:44 gaia ntpd[1611]: kernel time sync status change 0001
Jan 1 09:43:55 gaia ntpd[1611]: kernel time sync status change 4001
Jan 1 10:00:58 gaia ntpd[1611]: kernel time sync status change 0001
Jan 1 12:00:31 gaia ntpd[1611]: kernel time sync status change 4001
Jan 1 12:34:39 gaia ntpd[1611]: kernel time sync status change 0001
AIUI the 4001 and 0001 status changes show toggling between PLL and
FLL modes.
--
Bob Cox. Stoke Gifford, near Bristol, UK.
Please reply to the list only. Do NOT send copies directly to me.
Debian on the NSLU2: http://bobcox.com/slug/
Douglas A. Tutty
> Travis Crump <pret...@techhouse.org> writes:
>
> >I had a hard crash of my lenny system precisely when the leap second was
> >added. While X has flaked in the past, I've never had a hard crash
> >before. I have no other evidence they were related, but I wasn't doing
> >anything unusual at the time. Any ideas?
>
> I have a lenny and sid system, oth of which are still running OK.
>
> I am running openntpd on both, synced to my border router (openwrt),
> also still running and running openntpd.
>
> My logs show openntpd drifting the time back into sync from the leap
> second.
Both my machines are PII and the boot messages say something about the
clock being unreliable... I found that OpenNTPd, since it only jumps
the time on startup if its out by more than 3 minutes, and then slews
slowly, couldn't keep up with the drifting nature of the two boxes'
clocks and they drifted apart. ntpd keeps them in better sync.
Of course, being on dialup doesn't help either.
Doug.
John Hasler
> Debian has time servers:
>
> 0.debian.pool.ntp.org
> 1.debian.pool.ntp.org
> 2.debian.pool.ntp.org
> 3.debian.pool.ntp.org
Bob Cox writes:
> These are all aliases for 0.pool.ntp.org, 1.pool.ntp.org and so on.
That is how Debian and ntp.org have set it up. It could change. See
<http://www.pool.ntp.org/vendors.html>.
> It's probably best to use servers as close to you as possible...
Unless you have unusual requirements (you'll know) it really doesn't
matter. It's just a few UDP packets per hour and just about any server
anywhere in the world will get you within 100ms.
> John - in your case it looks like your ISP is CenturyTel and they appear
> to have a timeserver running on ntp0.centurytel.net...
I prefer to use reliable sources. Also, as Chrony maintainer I feel that I
should use my default configuration as much as possible.
> It seems that ntp4.ja.net is preferred to ntp0.zen.co.uk despite the
> longer delay, presumably because it's a stratum 1 server?
Look at the jitter. The algorithm considers more than just the stratum and
the round-trip delay.
--
John Hasler
Ron Johnson
[snip]
>
> That only matters if you have a particular need to synchronise precisely
> with your ISP.
Or want to put less stress on public time servers. (After all, I'm
paying for time.cox.net...
> And ISP servers are often unreliable.
Say what??????
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Paul Cartwright
> > Dec 31 19:59:46 paulandcilla ntpd[3701]: clock is now unsynced
> > Dec 31 20:07:27 paulandcilla ntpd[3701]: clock is now synced
> > Dec 31 20:56:19 paulandcilla ntpd[3700]: adjusting local clock by
> > -0.159575s
>
> Are you on a dial-up connection Paul? If so, that may explain the
> losses of sync.
Westell modem->linksys router->PC.
>
> This is what I see here:
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Bob Cox
> I wrote:
> > Debian has time servers:
> >
> > 0.debian.pool.ntp.org
> > 1.debian.pool.ntp.org
> > 2.debian.pool.ntp.org
> > 3.debian.pool.ntp.org
>
> Bob Cox writes:
> > These are all aliases for 0.pool.ntp.org, 1.pool.ntp.org and so on.
>
> That is how Debian and ntp.org have set it up. It could change. See
> <http://www.pool.ntp.org/vendors.html>.
Thank you John. That's interesting.
> > It's probably best to use servers as close to you as possible...
>
> Unless you have unusual requirements (you'll know) it really doesn't
> matter. It's just a few UDP packets per hour and just about any server
> anywhere in the world will get you within 100ms.
>
> > John - in your case it looks like your ISP is CenturyTel and they appear
> > to have a timeserver running on ntp0.centurytel.net...
>
> I prefer to use reliable sources. Also, as Chrony maintainer I feel that I
> should use my default configuration as much as possible.
>
> > It seems that ntp4.ja.net is preferred to ntp0.zen.co.uk despite the
> > longer delay, presumably because it's a stratum 1 server?
>
> Look at the jitter. The algorithm considers more than just the stratum and
> the round-trip delay.
Yes, that makes sense. Thanks again.
--
Bob Cox. Stoke Gifford, near Bristol, UK.
Please reply to the list only. Do NOT send copies directly to me.
Debian on the NSLU2: http://bobcox.com/slug/
Ron Johnson
> On Thu January 1 2009, Bob Cox wrote:
>>> Dec 31 19:59:46 paulandcilla ntpd[3701]: clock is now unsynced
>>> Dec 31 20:07:27 paulandcilla ntpd[3701]: clock is now synced
>>> Dec 31 20:56:19 paulandcilla ntpd[3700]: adjusting local clock by
>>> -0.159575s
>> Are you on a dial-up connection Paul? If so, that may explain the
>> losses of sync.
> no, I have an always-on DSL connection.
> Westell modem->linksys router->PC.
What time server(s) do you use?
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Paul E Condon
> I wrote:
> > Debian has time servers:
> >
> > 0.debian.pool.ntp.org
> > 1.debian.pool.ntp.org
> > 2.debian.pool.ntp.org
> > 3.debian.pool.ntp.org
>
> should use my default configuration as much as possible.
>
> > It seems that ntp4.ja.net is preferred to ntp0.zen.co.uk despite the
> > longer delay, presumably because it's a stratum 1 server?
>
> Look at the jitter. The algorithm considers more than just the stratum and
> the round-trip delay.
> --
> John Hasler
John:
You and I appear to be the only people posting to this thread who use
chrony. I run it just the way you set it up in the package. (except
that I'm always connected to the Internet, and edited out the
'offline' from the server spec.s) Because of this long thread, and
especially because of reported crashes, I looked at my chrony logs.
I saw nothing remarkable, except that there was no evidence of a one
second leap. Because of the pool, there was not, in my record,
frequent data from a single ntp server, so I'm not sure I could have
seen a leap spread across four ntp servers. Did you see any evidence
of the leap?
Not that it really matters. I'm a physicist who is comfortable with
the fact of Einsteinian special relativity. For me its important that
my clock run smoothly, and that my software not crash when it discovers
a discrepancy between two clocks at widely separated locations. And,
the idea of leap seconds is something of an intellectual abomination,
anyway.
So, thanks for making chrony work the way a clock should work.
--
Paul E Condon
peco...@mesanetworks.net
Paul Cartwright
> > no, I have an always-on DSL connection.
> > Westell modem->linksys router->PC.
>
> What time server(s) do you use?
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server 3.debian.pool.ntp.org
server wuarchive.wustl.edu
server gilbreth.ecn.purdue.edu
server ntp.cmr.gov
server clock.psu.edu
server constellation.ecn.uoknor.edu
server ntp0.cornell.edu
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Bob Cox
> On Thu January 1 2009, Bob Cox wrote:
> > > Dec 31 19:59:46 paulandcilla ntpd[3701]: clock is now unsynced
> > > Dec 31 20:07:27 paulandcilla ntpd[3701]: clock is now synced
> > > Dec 31 20:56:19 paulandcilla ntpd[3700]: adjusting local clock by
> > > -0.159575s
> >
> > Are you on a dial-up connection Paul? If so, that may explain the
> > losses of sync.
> no, I have an always-on DSL connection.
> Westell modem->linksys router->PC.
Hi Paul - what's the output from ntpq -p please?
--
Bob Cox. Stoke Gifford, near Bristol, UK.
Please reply to the list only. Do NOT send copies directly to me.
Debian on the NSLU2: http://bobcox.com/slug/
John Hasler
> You and I appear to be the only people posting to this thread who use
> chrony. I run it just the way you set it up in the package. (except that
> I'm always connected to the Internet, and edited out the 'offline' from
> the server spec.s) Because of this long thread, and especially because of
> reported crashes, I looked at my chrony logs.
> I saw nothing remarkable, except that there was no evidence of a one
> second leap.
Chrony does not currently support leap seconds [1]. When the leap occurred
it lost synch, chose a different server, and then pulled back in.
> For me its important that my clock run smoothly, and that my software not
> crash when it discovers a discrepancy between two clocks at widely
> separated locations.
Have you looked at the version in Experimental with the real-time
enhancements? They should reduce latency variation but I don't have a way
to test that.
> And, the idea of leap seconds is something of an intellectual
> abomination, anyway.
Leap seconds should be kept in a file somewhere and appled when formatting
time for display like DST rules. They don't belong in the timestream.
[1] A reasonable-looking patch to add leap second support was posted to the
development list yesterday but I did not have time enough to apply and test
it.
--
John Hasler
Travis Crump
Hash: SHA1
> OoO En cette nuit nuageuse du jeudi 01 janvier 2009, vers 01:25, Travis
> Crump <pret...@techhouse.org> disait :
>
>> I had a hard crash of my lenny system precisely when the leap second was
>> added. While X has flaked in the past, I've never had a hard crash
>> before. I have no other evidence they were related, but I wasn't doing
>> anything unusual at the time. Any ideas?
>
> Hi!
>
> Which kernel do you use?
>
> It is a known problem on 2.6.21 but may appear on any kernel before
> 2.6.21.6. See:
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg00714.html
> http://lkml.org/lkml/2007/7/3/103
>
> It should not happen on Lenny kernel (2.6.26).
I was using an old revision of the lenny
kernel[linux-image-2.6.26-1-amd64 2.6.26-4], but have since upgraded to
the latest (lenny) version. Perhaps that was it.
Another potential data point, fetchmail was running and went to sleep
for 120 seconds at 11:58:00 UTC.
"X being flakey" was more to imply that I know the difference between X
freezing and the system crashing. X has never frozen on this hardware
though it does occasionally restart itself when I switch vts[I wasn't
switching vts at the time]. I couldn't ssh in and the Num Lock LED
wouldn't toggle[my standard as to whether the keyboard is alive]. The
monitor stayed in its last state and the last half-second of the audio
of the video I was watching looped continuously.
Travis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkldCakACgkQlxHEcbyY0skN9wCggRF+RXsHRGU2QQFTl9KNyGle
OTsAniAO3rQUbOiE5IjPUb8e5xaRZri6
=N4Ib
-----END PGP SIGNATURE-----
Paul E Condon
>
...
> Chrony does not currently support leap seconds [1]. When the leap occurred
> it lost synch, chose a different server, and then pulled back in.
IMHO, chrony's current behavior is already 'correct'. To me, it is far more
important that the reported time is always increasing than that it quickly
settles into synchronism with a source that exhibits sudden jumps or extended
periods of stasis.
> Have you looked at the version in Experimental with the real-time
> enhancements? They should reduce latency variation but I don't have a way
> to test that.
Actually, I think people are obsessive about time on computers. My
comment about special relativity can be expanded to an assertion that
there is surely no universally correct way to report time across all
possible reference frames.
Real time clocks are a quantized form of time, with the quantum being the
period of the cpu 'clock'. Reporting system event times to a precision of
1e-9 sec, as in done in the kernel, is crazy. The last digit of that 'time'
is surely not accurate. Computers are, after all, electronics devices that
operate in the real physical world, at real physical speeds. Only virtual
computers operate in virtual time.
>
> > And, the idea of leap seconds is something of an intellectual
> > abomination, anyway.
>
> Leap seconds should be kept in a file somewhere and appled when formatting
> time for display like DST rules. They don't belong in the timestream.
>
Yes. But there are a lot of social issues. Six and a half billion people,
of which perhaps a billion think they really know what time is ...
>
> [1] A reasonable-looking patch to add leap second support was posted to the
> development list yesterday but I did not have time enough to apply and test
> it.
Don't rush to fix something that really isn't broken.
Again, thanks for keeping chrony working so nicely.
--
Paul E Condon
peco...@mesanetworks.net
Vincent Lefevre
> IMHO, chrony's current behavior is already 'correct'. To me, it is
> far more important that the reported time is always increasing than
> that it quickly settles into synchronism with a source that exhibits
> sudden jumps or extended periods of stasis.
I agree that sudden jumps or extended periods of stasis are bad.
However this is how leap seconds currently work (it would have been
better to have a continuous synchronization between UTC and UT1[*]).
The consequence is that a machine using chrony can have 1 second
difference with other machines. When the files are stored remotely
(e.g. on a NFS server), this can yield problems, especially with
tools like "make" (even though one doesn't like tools based on
timestamps).
[*] According to Wikipedia, a vote towards this solution was planned
in 2008. But Wikipedia is not up-to-date.
> Real time clocks are a quantized form of time, with the quantum
> being the period of the cpu 'clock'. Reporting system event times to
> a precision of 1e-9 sec, as in done in the kernel, is crazy. The
> last digit of that 'time' is surely not accurate.
Isn't the goal is to avoid equalities or to have accurate *relative*
times on a machine?
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Paul Cartwright
> > no, I have an always-on DSL connection.
> > Westell modem->linksys router->PC.
>
> Hi Paul - what's the output from ntpq -p please?
paulandcilla:/etc# ntpq -p
bash: ntpq: command not found
... ok, so apt-cache search ntpq says hobbit-plugins
that didn't change anything.
so I tried :
# aptitude install ntp
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
openntpd
The following NEW packages will be installed:
ntp
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 434kB of archives. After unpacking 1065kB will be used.
The following packages have unmet dependencies:
openntpd: Conflicts: ntp but 1:4.2.4p4+dfsg-7 is to be installed.
The following actions will resolve these dependencies:
Remove the following packages:
openntpd
Score is 119
Accept this solution? [Y/n/q/?]
q
# dpkg --list|grep ntp
rc ntp 1:4.2.4p4+dfsg-5
Network Time Protocol daemon and utility programs
ii ntpdate 1:4.2.4p4+dfsg-7
client for setting system time from NTP servers
ii openntpd 3.9p1-7
OpenBSD NTP daemon
so I don't have ntpq..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Nate Bargmann
> The following packages are BROKEN:
> openntpd
> The following NEW packages will be installed:
> ntp
> 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 434kB of archives. After unpacking 1065kB will be used.
> The following packages have unmet dependencies:
> openntpd: Conflicts: ntp but 1:4.2.4p4+dfsg-7 is to be installed.
> The following actions will resolve these dependencies:
>
> Remove the following packages:
> openntpd
>
> Score is 119
>
> Accept this solution? [Y/n/q/?]
> q
> # dpkg --list|grep ntp
> rc ntp 1:4.2.4p4+dfsg-5
> Network Time Protocol daemon and utility programs
> ii ntpdate 1:4.2.4p4+dfsg-7
> client for setting system time from NTP servers
> ii openntpd 3.9p1-7
> OpenBSD NTP daemon
>
>
> so I don't have ntpq..
Of course not as ntp is still not installed due to the conflict with
openntp. `ntpq' is in the ntp package per:
Once openntp is removed then you'll have ntp installed and ntpq to go
with it.
- Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html
Yannick Patois
Travis Crump wrote:
> I had a hard crash of my lenny system precisely when the leap second was
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
Same behavior here.
My machine also crashed precisely at 0:59:59 - french time - (screen
froze, KDE bar displaying this time).
My current kernel is:
Linux 2.6.26-1-686 #1 SMP Mon Dec 15 18:15:07 UTC 2008 i686 GNU/Linux
This is an average 32 bits sempron 2600 machine.
I would be very interested to understand what's happened. I don't think
it's a coincidence, I've seen several other mention of such a crash
(with Debian) on the web today.
Yannick
--
_/ Yannick Patois \___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pat...@altespace.org | |
| Petit film d'animation pour enfants: http://animation.altespace.org |
Paul Cartwright
> > no, I have an always-on DSL connection.
> > Westell modem->linksys router->PC.
>
> Hi Paul - what's the output from ntpq -p please?
installed ntp
# /etc/init.d/ntp restart
Stopping NTP server: ntpd.
Starting NTP server: ntpd.
paulandcilla:/etc# ps -ef|grep ntp
root 26953 1 0 20:20 ? =20
00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 110:115 -g
root 26968 18388 0 20:20 pts/2 00:00:00 grep ntp
paulandcilla:/etc# ntpq -p
localhost: timed out, nothing received
***Request timed out
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Paul Cartwright
> On Thu January 1 2009, Bob Cox wrote:
> > > no, I have an always-on DSL connection.
> > > Westell modem->linksys router->PC.
> >
> > Hi Paul - what's the output from ntpq -p please?
>
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+keeleysam.com 129.6.15.28 2 u 37 64 377 62.332 158.333 360.774
+wsip-98-172-32- 129.7.1.66 2 u 37 64 377 85.031 131.351 241.558
+doctor-who.chpc 204.152.184.72 2 u 39 64 377 388.316 265.047 260.877
+splenda.rustyte 99.150.184.201 2 u 39 64 377 409.798 277.070 309.525
+kiri.nonexiste. 64.34.180.101 3 u 40 64 377 68.400 127.708 308.037
*smtp.housefront 198.72.72.10 3 u 37 64 377 88.059 121.465 240.557
wuarchive.wustl .INIT. 16 u - 64 0 0.000 0.000 0.000
gilbreth.ecn.pu .INIT. 16 u - 64 0 0.000 0.000 0.000
10.10.10.10 .INIT. 16 u - 64 0 0.000 0.000 0.000
+otc2.psu.edu 128.118.2.33 2 u 46 64 377 194.937 193.023 205.449
+cudns.cit.corne 128.118.25.12 2 u 54 64 377 46.661 130.277 144.958
Dennis Wicks
> Hi,
>
> Travis Crump wrote:
>> I had a hard crash of my lenny system precisely when the leap second was
>> added. While X has flaked in the past, I've never had a hard crash
>> before. I have no other evidence they were related, but I wasn't doing
>> anything unusual at the time. Any ideas?
>
> Same behavior here.
>
> My machine also crashed precisely at 0:59:59 - french time - (screen
> froze, KDE bar displaying this time).
>
> My current kernel is:
> Linux 2.6.26-1-686 #1 SMP Mon Dec 15 18:15:07 UTC 2008 i686 GNU/Linux
> This is an average 32 bits sempron 2600 machine.
>
> I would be very interested to understand what's happened. I don't think
> it's a coincidence, I've seen several other mention of such a crash
> (with Debian) on the web today.
>
> Yannick
>
Well, just for another data point, I have 6 machines running
lenny at various levels of being up-to-date and none of them
crashed.
I am running ntp 1:4.2.4p4+dfsg-7 according to aptitude. My
firewall is a stratum 2 timeserver and all the other
machines get their time from it.
Dennis
Douglas A. Tutty
> Yannick Patois wrote the following on 01/01/2009 06:09 PM:
> Well, just for another data point, I have 6 machines running
> lenny at various levels of being up-to-date and none of them
> crashed.
>
> I am running ntp 1:4.2.4p4+dfsg-7 according to aptitude. My
> firewall is a stratum 2 timeserver and all the other
> machines get their time from it.
Interestingly, I just noticed that I stopped receiving mail from
mi...@openbsd.org around the time of the leap second. I haven't looked
into why yet.
It seems that some of us had problems around the leap second, while some
of us didn't. Unfortunatly, both ntp and openntpd both use
/usr/sbin/ntpd (different binary of course).
I wonder if there is correlation between those of us who had a problem
and those of us who were running openntpd at the time?
Doug.
Thierry Chatelet
> I wonder if there is correlation between those of us who had a problem
> and those of us who were running openntpd at the time?
>
> Doug.
I will not help in solving the problem, but, running Lenny, my mail did not
work last night. Without thinking about the leap second, I rebooted the
laptop and every was back to normal. Now, reading about that, Iµ think the
laptop was in kind of disconfort whith the leap seconde. I am running npt on
it.
Ron Johnson
> Hi,
>
> Travis Crump wrote:
>> I had a hard crash of my lenny system precisely when the leap second was
>> added. While X has flaked in the past, I've never had a hard crash
>> before. I have no other evidence they were related, but I wasn't doing
>> anything unusual at the time. Any ideas?
>
> Same behavior here.
>
> My machine also crashed precisely at 0:59:59 - french time - (screen
> froze, KDE bar displaying this time).
>
> My current kernel is:
> Linux 2.6.26-1-686 #1 SMP Mon Dec 15 18:15:07 UTC 2008 i686 GNU/Linux
> This is an average 32 bits sempron 2600 machine.
>
> I would be very interested to understand what's happened. I don't think
> it's a coincidence, I've seen several other mention of such a crash
> (with Debian) on the web today.
What time sync method do you use? ntpdate, openntpd or ntp?
--
Ron Johnson, Jr.
Jefferson LA USA
I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.
Paul E Condon
On Fri, Jan 02, 2009 at 12:23:18AM +0100, Vincent Lefevre wrote:
> On 2009-01-01 11:58:14 -0700, Paul E Condon wrote:
> > IMHO, chrony's current behavior is already 'correct'. To me, it is
> > far more important that the reported time is always increasing than
> > that it quickly settles into synchronism with a source that exhibits
> > sudden jumps or extended periods of stasis.
>
> I agree that sudden jumps or extended periods of stasis are bad.
> However this is how leap seconds currently work (it would have been
> better to have a continuous synchronization between UTC and UT1[*]).
> The consequence is that a machine using chrony can have 1 second
> difference with other machines. When the files are stored remotely
> (e.g. on a NFS server), this can yield problems, especially with
> tools like "make" (even though one doesn't like tools based on
> timestamps).
>
When doing a build on a remote host I think one should use time stamps
that were generated on that remote host. It strikes me a very risky to
have a bunch of build objects scattered across a world wide array of
hosts and relying on locally generated timestamps to make sure they
are in sync. It seems to me that there must be a central authority, a
single host that assigns timestamps to all shared files. This is
doable, and if done, the local time on any single machine is
unimportant, and can be wildly wrong, and the system still works.
> [*] According to Wikipedia, a vote towards this solution was planned
> in 2008. But Wikipedia is not up-to-date.
>
I think there are fundamental, irreconsilable differences. Atomic clocks
and the Earth actually run at different rates, and the difference is
growing with time. It may be possible to hide one of the time standards
so that its existence is known only to a special few, but that really
won't solve the problem because people who know only about the visible
system will persist in designing stuff that can only work if there is
a single, universal definition of time, which there is NOT.
> > Real time clocks are a quantized form of time, with the quantum
> > being the period of the cpu 'clock'. Reporting system event times to
> > a precision of 1e-9 sec, as in done in the kernel, is crazy. The
> > last digit of that 'time' is surely not accurate.
>
> Isn't the goal is to avoid equalities or to have accurate *relative*
> times on a machine?
For finding pairs of files that are actually identical, one should use
a message digest such as md5sum. Time stamp is used only because it's
easy. Isn't it possible to specify that timestamps be preserved in a
file copy? A preserved timestamp is surely not rewritten during copy
to compensate for a mismatch in the time settings of the clocks on the
two computers. So in a system that uses timestamps, if the timestamps
differ, then, at the very least the copy was not done correctly.
In comparing timestamps there is a shoddiness in the kernel. If a file
is open, its timestamp is reported in kernel-time which is carried to
a precision of 1 nanosecond (1e-9sec). This precision is actually
meaningless, but at least it discourages developers from testing for
equality. When the file is closed, the reported time stamp is the
number that is recorded in the inode on disk, currently accurate to
a whole second. I call the kernel shoddy because its precision is
only for appearance. The reality is that the kernel developers have
no way of knowing how accurate this time actually is because they
have no independent measure of time with which to compare it at the
nanosecond level. So open vs closed affects the timestamp in a way
unknowable to the user.
For me, the first goal is to have a timestamp system that is self-
consistent on a single host. Jerking the clock setting around because
of transient (mis)information from a remote clock obtained over a
noisy channel doesn't improve the measurement of local time. Once
there are reasonable measures of local time on all hosts, it becomes
reasonable to think about synchronizing these measure, but only to
the precision that is meanful, given the noise in the communication
channel. For time data, jitter in the transmission delay of messages is
noise.
I'm really not as cranky as I seem ;-)
--
Paul E Condon
peco...@mesanetworks.net
Bob Cox
> On Thu January 1 2009, Paul Cartwright wrote:
> > On Thu January 1 2009, Bob Cox wrote:
> > > > no, I have an always-on DSL connection.
> > > > Westell modem->linksys router->PC.
> > >
> > > Hi Paul - what's the output from ntpq -p please?
> >
> and then:
> # ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> +keeleysam.com 129.6.15.28 2 u 37 64 377 62.332 158.333 360.774
> +wsip-98-172-32- 129.7.1.66 2 u 37 64 377 85.031 131.351 241.558
> +doctor-who.chpc 204.152.184.72 2 u 39 64 377 388.316 265.047 260.877
> +splenda.rustyte 99.150.184.201 2 u 39 64 377 409.798 277.070 309.525
> +kiri.nonexiste. 64.34.180.101 3 u 40 64 377 68.400 127.708 308.037
> *smtp.housefront 198.72.72.10 3 u 37 64 377 88.059 121.465 240.557
> wuarchive.wustl .INIT. 16 u - 64 0 0.000 0.000 0.000
> gilbreth.ecn.pu .INIT. 16 u - 64 0 0.000 0.000 0.000
> 10.10.10.10 .INIT. 16 u - 64 0 0.000 0.000 0.000
> +otc2.psu.edu 128.118.2.33 2 u 46 64 377 194.937 193.023 205.449
> +cudns.cit.corne 128.118.25.12 2 u 54 64 377 46.661 130.277 144.958
Hopefully, after it has been running for a while, it will settle down
and you will see smaller offset and jitter values and as that happens
the poll values should rise from 64 to 1024.
--
Bob Cox. Stoke Gifford, near Bristol, UK.
Please reply to the list only. Do NOT send copies directly to me.
Debian on the NSLU2: http://bobcox.com/slug/
Paul Cartwright
> I was running openntpd and since the leap second switched to ntp.
>
>
> and those of us who were running openntpd at the time?
as I found out I WAS running openntpd. I didn't remember switching, but when i
tries the command ntpq -p and it wasn't found, I started looking..
so I installed ntpd, THEN ran ntpq -p..
with openntpd I didn't have any messages about a leap second that I could
find. grepped for 59:59 in all logs with no success.
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
Florian Weimer
> I had a hard crash of my lenny system precisely when the leap second was
> added. While X has flaked in the past, I've never had a hard crash
> before. I have no other evidence they were related, but I wasn't doing
> anything unusual at the time. Any ideas?
Do you run Oracle RAC?
Yannick Patois
Ron Johnson wrote:
> On 01/01/09 18:09, Yannick Patois wrote:
>> My machine also crashed precisely at 0:59:59 - french time - (screen
>> froze, KDE bar displaying this time).
> What time sync method do you use? ntpdate, openntpd or ntp?
I use ntp from debian, deb versionned as 1:4.2.4p4+dfsg-7
There is nothing in the logs just before crash.
Yannick
--
_/ Yannick Patois \___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pat...@altespace.org | |
| Petit film d'animation pour enfants: http://animation.altespace.org |
Henrique de Moraes Holschuh
> > What time server(s) do you use?
> ntp.conf shows:
> server 0.pool.ntp.org
> server 1.pool.ntp.org
> server 2.pool.ntp.org
> server 0.debian.pool.ntp.org
> server 1.debian.pool.ntp.org
> server 2.debian.pool.ntp.org
> server 3.debian.pool.ntp.org
> server wuarchive.wustl.edu
> server gilbreth.ecn.purdue.edu
> server ntp.cmr.gov
> server clock.psu.edu
> server constellation.ecn.uoknor.edu
> server ntp0.cornell.edu
Dear <deity>, don't do that! It is a major abuse of the ntp servers,
and it doesn't even work well as your logs clearly show..., so it is
not like you're getting anything out of it.
Please just use the four "debian.pool" servers, OR do a proper custom
setup using *three* servers close to you network-wise (and with low
jitter), and for which you have permission to connect.
ntp works best with three to six upstream servers, and an end-user
workstation has no business using more than three.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Vincent Lefevre
> On Fri, Jan 02, 2009 at 12:23:18AM +0100, Vincent Lefevre wrote:
> > I agree that sudden jumps or extended periods of stasis are bad.
> > However this is how leap seconds currently work (it would have been
> > better to have a continuous synchronization between UTC and UT1[*]).
> > The consequence is that a machine using chrony can have 1 second
> > difference with other machines. When the files are stored remotely
> > (e.g. on a NFS server), this can yield problems, especially with
> > tools like "make" (even though one doesn't like tools based on
> > timestamps).
>
> When doing a build on a remote host I think one should use time stamps
> that were generated on that remote host.
This is not as simple: files can come from both the remote host (NFS
server) and the local disk, and it isn't always easy to avoid that.
It is even not always possible to use the time of the remote host
(e.g. because files have been transfered by ssh or some other mean).
> It strikes me a very risky to have a bunch of build objects
> scattered across a world wide array of hosts and relying on locally
> generated timestamps to make sure they are in sync. It seems to me
> that there must be a central authority, a single host that assigns
> timestamps to all shared files.
It would be easier not to use timestamps at all.
> > [*] According to Wikipedia, a vote towards this solution was planned
> > in 2008. But Wikipedia is not up-to-date.
>
> I think there are fundamental, irreconsilable differences. Atomic clocks
> and the Earth actually run at different rates, and the difference is
> growing with time.
I don't think this is a problem if almost-real-time corrections are
applied.
> For finding pairs of files that are actually identical, one should use
> a message digest such as md5sum. Time stamp is used only because it's
> easy. Isn't it possible to specify that timestamps be preserved in a
> file copy?
Not with all file systems.
> A preserved timestamp is surely not rewritten during copy to
> compensate for a mismatch in the time settings of the clocks on the
> two computers. So in a system that uses timestamps, if the
> timestamps differ, then, at the very least the copy was not done
> correctly.
One generally needs more than deciding that some file is the same as
the other: some file has been built after some other file.
> In comparing timestamps there is a shoddiness in the kernel. If a file
> is open, its timestamp is reported in kernel-time which is carried to
> a precision of 1 nanosecond (1e-9sec). This precision is actually
> meaningless, but at least it discourages developers from testing for
> equality. When the file is closed, the reported time stamp is the
> number that is recorded in the inode on disk, currently accurate to
> a whole second.
Well, kernel time is not just used for file timestamps. It can be used
for benchmarking, and only the relative accuracy is important (i.e. the
difference between two times).
--
Vincent Lefčvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)