NTP issue - time drifting, ntpd crashing?
in [Slackware]
|
Prev: Driver for Buffalo LPC PCM CLX
Next: Apple iPod
From: Grant on 16 Jan 2006 15:10 On Mon, 16 Jan 2006 19:54:33 GMT, A Guy Called Tyketto <tyketto(a)sbcglobal.net.invalid> wrote: > You gave your answer. You should have moved along. But you >didn't. Sad and pathetic. > > BL. >- -- >Brad Littlejohn | Email: tyketto(a)sbcglobal.net >Unix Systems Administrator, | tyketto(a)ozemail.com.au >Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not Found The requested URL /users/tyketto was not found on this server. Apache/1.3.27 Server at redirect.viawest.net Port 80 Faked .sigs are pathetic too ;) Grant. -- Cats are smarter than dogs. You can't make eight cats pull a sled through the snow.
From: A Guy Called Tyketto on 16 Jan 2006 18:53 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Grant <bugsplatter(a)gmail.com> wrote: > On Mon, 16 Jan 2006 19:54:33 GMT, A Guy Called Tyketto <tyketto(a)sbcglobal.net.invalid> wrote: > >> You gave your answer. You should have moved along. But you >>didn't. Sad and pathetic. >> >> BL. >>- -- >>Brad Littlejohn | Email: tyketto(a)sbcglobal.net >>Unix Systems Administrator, | tyketto(a)ozemail.com.au >>Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Faked .sigs are pathetic too ;) > > Grant. Thought I changed that. Thanks for noticing. It was my ISP 5 years ago. So I'm a lazy git. ;) BL. - -- Brad Littlejohn | Email: tyketto(a)sbcglobal.net Unix Systems Administrator, | tyketto(a)ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzDHhyBkZmuMZ8L8RAoF8AKDBX2v3YnGZzmrHGBjhxfWzOhdeWwCguZnk boNXeRtE+YRdKEnD8WBHGHY= =PdxU -----END PGP SIGNATURE-----
From: Chu Mai Fat on 17 Jan 2006 08:44 Eef Hartman wrote: > Chu Mai Fat <ChuMaiFat(a)nowhere.com> wrote: > >>I was under the impression that odd numbered kernels, ie 2.1.x, 2.3.x >>and 2.5.x were development kernels and should be updated but that even >>numbered kernels were considered stable and if they contained all the >>needed functionality then they were suitable and sufficient for general >>use. > > > That scheme isn't used anymore. > The "stable kernel" gets updated for security and bugfix reasons, > giving the 2.6.N.* versions, and _in the same time_ the NEXT upgrade is > being developed as 2.6.N+1 (and when it gets reasonable stable it becomes > a "rcX", a Release Candidate). > As soon as it DOES gets released, that version will get the .1 etc. SUBversions, > while the development team goes on with 2.6.N+2. > Ah...I wasn't aware that the old scheme had been abandoned and there was a new model. Thank you (and Grant) for your timely and informative responses. Regards Chu
From: Chu Mai Fat on 18 Jan 2006 05:29 Dan C for Chump wrote: > > Trailer? LOL! You'd be surprised. > Damn, still residing in the car on blocks? With kind regards Chu
From: Logical on 19 Jan 2006 05:08
Martin Boening wrote: > I think these are needed to actually allow these servers to > be accepted as time sources. I don't see any similar entries in your > ntp.conf file. According to the documentation one would think they > are unnecessary, since the server statements should implicitly allow the > listed servers - however, I never got NTP to work without them. Try it and > see what happens. (Maybe the server responses come as "queries which return > information", thus the weird interpretation). > > Interestingly enough, while checking all this as result of your > query, I found that my third 'server' line and my third "restrict" line > differ, as one ntp server was changed some time ago. 'ntp -p -n' on my > system shows the third server (not covered by a restrict statement) as > > 84.207.3.38 .STEP. 16 u - 1024 0 0.000 0.000 > 4000.00 I figured that was one of my problems, I've now got (for testing purposes) no restrict statemtnts which should allow all time sources to be used. I now have better performance, but only for two days. The log file has entries for two days, then nothing. # tail /var/log/ntp.log 16 Jan 12:15:10 ntpd[2810]: time reset +0.173450 s 16 Jan 12:19:28 ntpd[2810]: synchronized to LOCAL(0), stratum=10 16 Jan 12:23:46 ntpd[2810]: synchronized to 203.0.178.191, stratum=3 16 Jan 12:24:48 ntpd[2810]: synchronized to 128.184.1.1, stratum=2 16 Jan 17:34:08 ntpd[2810]: synchronized to LOCAL(0), stratum=10 # date Thu Jan 19 21:02:03 EST 2006 The time is now about four minutes off # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) LOCAL(0) 10 l 5 64 377 0.000 0.000 0.001 dns.iinet.net.a 203.55.231.26 3 u 858 1024 377 15.951 268580. 1433.16 fa0-0-1.syd-cor 202.72.191.202 3 u 891 1024 377 26.420 268526. 1420.71 sol.ccs.deakin. 128.250.36.2 2 u 797 1024 377 34.411 268668. 1432.60 241.126.233.220 LOCAL(0) 11 u 775 1024 77 70.752 268291. 1424.89 From that I ascertain that it can still contact the time server? ntpd appears to be still running correctly # ps aux | grep ntpd root 2810 0.0 0.7 3644 3640 ? SLs Jan15 0:05 /usr/sbin/ntpd -l /var/log/ntp.log Any other thoughts? |