Heló!
A következő a gondom:
Telepítve van egy IBM (Intel(R) Celeron(R) CPU 2.80GHz) gépen egy Debain Sarge (5 napos telepítés, kernel: 2.6.8-2-386). Egy idő után azonban rosszul kezeli az időt. Pár óráig, néha egy fél napig megy rendesen, aztán egy idő megbolondul. Még az alapkernelt használom, ami alapból felkerült.
Abban szeretném a vélemenyeteket / javaslatotokat kérni, hogy ez mitől lehet, vagy hogy mit lehetne tenni vele. Én rontottam el valamit? Köszi előre is!
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:35 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 13:28:05 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:35 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:31 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:32 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:33 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
testing:~# date
Tue Apr 4 12:16:34 CEST 2006
- 2493 megtekintés
Hozzászólások
Nekem az ora folyamatos sietesevel volt (van) problemam. Hogy mitol van ez, nem jottem ra. Workaroundkent surun futtatom az ntpdate -t.
- A hozzászóláshoz be kell jelentkezni
Javaslom inkább az ntpd-t (ntp-simple csomag), az egyrészt nem rúgásszerűen állítja vissza az időt, hanem szép folyamatosan csúsztatja le, másrészt pedig pontosra állítja az órád sebességét. Ugyanis már régi tapasztalat, hogy az alaplapi órák elég pontatlanok a sebességet tekintve, így aztán a kernelben van egy korrekciós mechanizmus, ami, ha ismeri az órád sebességét (1 valós másodpercet mennyinek mér ő), akkor már rögtön a kiolvasás utántól a korrigált értéket tekinti rendszeridőnek. Ezt a paramétert az adjtimex-szel tudod kézikusan hangolni, de ha hálózaton van a géped, az ntp daemon némiképp pontosabb eredményt ér el :).
Ja, ha már ntp, egy szivattyút azért mondanék, amibe belefutottam vele. A time.kfki.hu-ról akartam szinkronizálni, olyan tűzfal mögül, ami az ipv6-ot elegánsan kiblokkolja mindenestül, és csodálkoztam, hogy miért nem megy. Hát, ezért:
fules@alpha:~$ host time.kfki.hu
time.kfki.hu is a nickname for ubul.kfki.hu
ubul.kfki.hu has address 148.6.0.1
ubul.kfki.hu has address 2001:738:5001::1
A szerencsétlen ntpd persze az utolsó rekord alapján ment volna kifelé, ami ugye nem volt túl sikeres ötlet. Az (ipv4-es) ip-t beírva szervernek, vígan üzemel :)...
- A hozzászóláshoz be kell jelentkezni
(Csak a kfki-hoz szolok hozza. Mivel azert van a gepeknek neve, hogy azt hasznaljuk, a megoldasod a problema megkerulese. - Amugy hozzateszem, attol hogy a "host" ezt mondja, attol meg forditva mukodik, es az elso talalatot hasznalja az ntpd, nem az utolsot. De hogy a megoldast is megadjam - magam is ezekben a hetekben futottam bele - javasolnam az ntp.conf beli nondocumented feature -t hasznalni. Azaz a
server time.kfki.hu
sorban pont ugyanugy szukitsd IPv4-re, ahogy azt az ntpdate -nel is teheted. -4 a te baratod.)
- A hozzászóláshoz be kell jelentkezni
A chrony talán még jobb választás - tudja ugyanazt, mint az ntpd, de ráadásul méri a pontatlanságot, és amíg nincs kapcsolat esetleg a time szerverrel, addig a mérések alapján korrigálja az órát, folyamatosan!
- A hozzászóláshoz be kell jelentkezni
Nekem is siet az IBM, méghozzá hatalmas mennyiséget: 31sec/nap. IMHO ez már kóros.
- A hozzászóláshoz be kell jelentkezni
Nekem is nagyjábol ennyit állít vissza ntpd :) amióta megy, nemigazán foglalkozom vele, szépen szinkronizál.
- A hozzászóláshoz be kell jelentkezni
Chrony-t használok. Az is fokozatosan korrigálja az időeltolódást.
Érdemes még időnként szinkronizálni a system time-ot a hwclock-kal (hwclock --systohc, vagy valami ilyesmi - man hwclock). Meg van olyan is, hogy adjtimex.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Nalam ez orankent is megvan...
Ha all a gep, akkor viszont jo.
Persze ebbol kovetkezik, hogy ntpd nem tudta visszaallitani eleg gyorsan es igy is vagy 3 perccel mindig megelozte.
Es igazabol mivel desktop nem erdekes, hogy hirtelen allitja vissza...
- A hozzászóláshoz be kell jelentkezni
Köszönöm a segítségeket; egyelöre belőttem az ntpdémont, most úgy tünik korrektül megy, remélem így marad.
- A hozzászóláshoz be kell jelentkezni
Üdv!
Felhozom ezt a topikot, remélem belefér a kérdésem:
Debian sarge-ra telepítettem ntpd-t. A gond az, hogy nem tudok hozzá kapcsolódni, pedig fut a daemon. Van ötletetek?
# rdate localhost
rdate: connect: Connection refused
# nmap -sU localhost
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-12-16 19:55 CET
Interesting ports on localhost.localdomain (127.0.0.1):
(The ... ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
...
123/udp open|filtered ntp
...
Nmap finished: 1 IP address (1 host up) scanned in ... seconds
Az rdate biztosan jó, mert:
# rdate time.kfki.hu
Sat 16 Dec 2006 07:56:30 PM CET
Petya
- A hozzászóláshoz be kell jelentkezni
Tűzfalban ntp azaz 123 udp/tcp engedve van?
ntp.conf:
# By default, exchange time with everybody, but don't allow configuration.
# See /usr/share/doc/ntp-doc/html/accopt.html for details.
restrict default kod notrap nomodify nopeer noquery
Mik
- A hozzászóláshoz be kell jelentkezni
Üdv!
Tűzfal nincs bekapcsolva, minden policy ACCEPT. De ha lenne, localhostról akkor is el tudnám érni.
123 tcp-n nem figyel a szolgáltatás az nmap szerint, csak udp-n.
A confban benne van az a sor amit ideírtál.
Petya
- A hozzászóláshoz be kell jelentkezni
Tűzfallal localhost is tíltható :)
Az ntp alapestben udp-t használ. (nem tudom tcp mikor használna...)
ntpq -p
mit mond?
Ilyesminek kellene jönni:
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 13 l 38 64 377 0.000 0.000 0.002
-host1.hu 148.6.0.36 2 u 44 64 377 4.561 -0.305 0.133
-host2.hu 147.231.19.43 2 u 29 64 377 12.346 -0.055 3.445
+host3.hu .GPS. 1 u 29 64 377 11.794 -0.205 0.286
*host4.hu .GPS. 1 u 23 64 377 3.442 -0.137 0.080
+host5.hu .GPS. 1 u 29 64 377 6.814 -0.115 0.067
Mik
- A hozzászóláshoz be kell jelentkezni
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.pilikia.org .INIT. 16 u - 1024 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 39 64 377 0.000 0.000 0.001
Petya
- A hozzászóláshoz be kell jelentkezni
Valmi nem jó nálad, az ntp csak a localhost-hoz szinkronizált. Az ns1.pilikia.org előtt "-" vagy "+" vagy "*" -nak kellene szerepelnie. Írj be több szervert az ntp.conf-ba.
Mik
- A hozzászóláshoz be kell jelentkezni
Üdv!
Beírtam a hu.pool.ntp.org -os és a time.kfki.hu -t.
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
bakacsin.ki.iif .INIT. 16 u - 128 0 0.000 0.000 4000.00
0x5552e941.adsl .INIT. 16 u - 128 0 0.000 0.000 4000.00
mabuse.homeip.n .INIT. 16 u - 128 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 9 64 377 0.000 0.000 0.001Úgy tűnik semmi változás, a local-nál van a csillag.
Petya
- A hozzászóláshoz be kell jelentkezni
Azthiszem túl korán futtattad le. Az ntp-nek indulás után több perc is kell amíg szinkronizál a szerverekhez. Várj vele kb. 5 percet, és utána nézd meg mit mond az ntpq -p.
Mik
- A hozzászóláshoz be kell jelentkezni
Üdv!
Már majdnem egy órája fut, és még mindig:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
bakacsin.ki.iif .INIT. 16 u - 1024 0 0.000 0.000 4000.00
0x5552e941.adsl .INIT. 16 u - 1024 0 0.000 0.000 4000.00
mabuse.homeip.n .INIT. 16 u - 1024 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 12 64 377 0.000 0.000 0.001
Petya
- A hozzászóláshoz be kell jelentkezni
Nos, nemtom. A time.kfki.hu-t nem látom a listában, esetleg a bakacsin.ki.iif.hu lehet? Nálam az ubul.kfki.hu-t adja vissza. Még próbaképpen írd be a
server lx.ujf.cas.cz -t.
Ez most biztosan elérhető. Ha ezzel sem megy, nem tudok más megoldást...
Mik
- A hozzászóláshoz be kell jelentkezni
Hát pedig így sem megy:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
lx.ujf.cas.cz .INIT. 16 u - 128 0 0.000 0.000 4000.00
2001:738:5001:: .INIT. 16 u - 128 0 0.000 0.000 4000.00
ojjektum.uhulin .INIT. 16 u - 128 0 0.000 0.000 4000.00
213.173.251.36 .INIT. 16 u - 128 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 41 64 377 0.000 0.000 0.001
Petya
- A hozzászóláshoz be kell jelentkezni
Nincs valami tűzfal, router, proxy egyéb hálózatos eszköz a hálózatodban ami ezt megfoghatja? IPv6-ból jól gondolom, hogy NIIF-hálózatból vagy? Alapesetben onnan mennie kell, viszont ott szerintem mindenhol van tűzfal is... Kifogytam az ötletekből...
Mik
- A hozzászóláshoz be kell jelentkezni
Üdv!
Igen, niif hálóról van szó. A tűzfalunk alapesetben semmi ilyesmit nem fog meg, az rdate time.kfki.hu pl. kiválóan megy.
Petya
- A hozzászóláshoz be kell jelentkezni
szerk: van valakinek ötlete?
Petya
- A hozzászóláshoz be kell jelentkezni
Nem lehet, hogy túl nagy az eltérés az elején? Ha jól emlékszem, van valami max eltérés, amit az ntpd megpróbál szinkronizálni. Ha annál nagyobb a difi, akkor nem próbálkozik. Indítása előtt ntpdate-tel állítsd be az időt (pl. ntpdate time.kfki.hu ), utána mehet az ntpd indítása.
- A hozzászóláshoz be kell jelentkezni
Üdv!
# /etc/init.d/ntp-server start
Starting NTP server: ntpd.néhány perc múlva:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
2001:738:5001:: .INIT. 16 u - 64 0 0.000 0.000 4000.00
rs12.lvs.iif.hu .INIT. 16 u - 64 0 0.000 0.000 4000.00
smtp.malepartus .INIT. 16 u - 64 0 0.000 0.000 4000.00
kremvax.pck.ner .INIT. 16 u - 64 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 28 64 17 0.000 0.000 0.001
# ntpdate time.kfki.hu
19 Dec 18:20:34 ntpdate[23939]: the NTP socket is in use, exiting
# /etc/init.d/ntp-server stop
Stopping NTP server: ntpd.
# ntpdate time.kfki.hu
19 Dec 18:20:51 ntpdate[23943]: no server suitable for synchronization foundMi lehet a baj?
Petya
- A hozzászóláshoz be kell jelentkezni
Egy sun-os fórumban találtam 2 érdekességet:
ntpdate -q -d -d -d -d time.kfki.hu
ill.
ntpq -pc rv 148.6.0.1
Ezekkel hátha sikerül valamit debuggolni.
Mik
u.i.
link
- A hozzászóláshoz be kell jelentkezni
Üdv!
Ez nagyon érdekes:
# ntpdate -q -d -d -d -d time.kfki.hu
19 Dec 19:28:20 ntpdate[27232]: ntpdate 4.2.0a@1:4.2.0a+stable-2-r Fri Aug 26 10:30:13 UTC 2005 (1)
transmit(2001:738:5001::1)
transmit to 2001:738:5001::1
transmit(2001:738:5001::1)
transmit to 2001:738:5001::1
transmit(2001:738:5001::1)
transmit to 2001:738:5001::1
transmit(2001:738:5001::1)
transmit to 2001:738:5001::1
transmit(2001:738:5001::1)
2001:738:5001::1: Server dropped: no data
server 2001:738:5001::1, port 123
stratum 0, precision 0, leap 00, trust 000
refid [2001:738:5001::1], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: c932adc8.1886bdf4 Tue, Dec 19 2006 19:28:24.095
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
19 Dec 19:28:25 ntpdate[27232]: no server suitable for synchronization found
# ntpq -pc rv 148.6.0.1
remote refid st t when poll reach delay offset jitter
==============================================================================
*cuckoo.kfki.hu .GPS. 1 u 204 1024 377 0.291 -0.010 0.061
-ntp0.nl.uu.net .GPS. 1 u 649 1024 377 53.270 10.848 4.472
-ntp1-rz.rrze.un 131.188.3.220 2 u 203 1024 377 22.708 0.165 0.135
+ntps1-1.cs.tu-b .PPS. 1 u 302 1024 337 34.357 -0.077 0.288
+193.204.114.233 .IEN. 1 u 299 1024 377 22.774 -0.052 1.207
NTP.MCAST.NET 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
assID=0 status=0674 leap_none, sync_ntp, 7 events, event_peer/strat_chg,
version="ntpd 4.1.1c-rc1@1.836 Wed Mar 5 12:33:58 MET 2003 (1)"?,
processor="sun4u", system="SunOS5.8", leap=00, stratum=2, precision=-14,
rootdelay=0.291, rootdispersion=21.919, peer=4716, refid=148.6.0.36,
reftime=c932ad0f.47ce2421 Tue, Dec 19 2006 19:25:19.280, poll=10,
clock=0xc932adf5.cd578964, state=4, offset=-0.010, frequency=16.600,
jitter=2.403, stability=0.005
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
2001:738:5001:: .INIT. 16 u - 1024 0 0.000 0.000 4000.00
rs13.lvs.iif.hu .INIT. 16 u - 1024 0 0.000 0.000 4000.00
salukes.opensou .INIT. 16 u - 1024 0 0.000 0.000 4000.00
gobio2.net .INIT. 16 u - 1024 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 6 64 377 0.000 0.000 0.001
- A hozzászóláshoz be kell jelentkezni
Hmm, csak 1 ötlet:
próbáld meg IPv6-ot kikapcsolni amíg tesztelsz:
mik:/home/mik# ntpdate -q 2001:738:5001::1
server 2001:738:5001::1, stratum 0, offset 0.000000, delay 0.00000
19 Dec 20:41:55 ntpdate[16893]: no server suitable for synchronization found
mik:/home/mik# ntpdate -q time.kfki.hu
server 2001:738:5001::1, stratum 0, offset 0.000000, delay 0.00000
server 148.6.0.1, stratum 2, offset -0.000182, delay 0.03027
19 Dec 20:42:07 ntpdate[16905]: adjust time server 148.6.0.1 offset -0.000182 sec
Az ntp.conf-be meg írd be a time.kfki.hu IP címét: 148.6.0.1 Amint látod, nálam is bepróbálkozik IPv6-al, de nálam az IPv4-et is megpróbálja, nálad meg úgylátom nem, és úgylátszik v6-ra nem válaszol ntp-vel.
Mik
- A hozzászóláshoz be kell jelentkezni
Üdv!
Lehet benne valami, mert:
# ntpq -p 148.6.0.1
remote refid st t when poll reach delay offset jitter
==============================================================================
*cuckoo.kfki.hu .GPS. 1 u 252 1024 377 5.552 2.681 2.724
-ntp0.nl.uu.net .GPS. 1 u 694 1024 347 56.513 12.415 12.548
+ntp1-rz.rrze.un 131.188.3.222 2 u 250 1024 377 23.307 -2.868 2.721
+ntps1-1.cs.tu-b .PPS. 1 u 40m 1024 374 34.449 -0.414 0.823
+ntp2.inrim.it .IEN. 1 u 335 1024 377 22.840 0.037 0.177
NTP.MCAST.NET 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
# ntpq -p localhost
remote refid st t when poll reach delay offset jitter
==============================================================================
2001:738:5001:: .INIT. 16 u - 1024 0 0.000 0.000 4000.00
rs13.lvs.iif.hu .INIT. 16 u - 1024 0 0.000 0.000 4000.00
salukes.opensou .INIT. 16 u - 1024 0 0.000 0.000 4000.00
gobio2.net .INIT. 16 u - 1024 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 25 64 377 0.000 0.000 0.001
Kipróbálom amit írtál.
Petya
- A hozzászóláshoz be kell jelentkezni
Üdv!
Ilyen nincs.. újra kellett indítanom a gépet az ipv6 miatt, de így már a service sem figyel a 123-as porton, és nem is fut... beírja a syslog-ba, hogy elindult, de utána már nem is létezik az a PID, ami a logban van. Mi a fene lehet ez?
szerk: megvan, ha a time.kfki.hu benne van a confban, akkor hibaüzenet és log bejegyzés nélkül elszáll az ntpd processz. Egyébként nem száll el, csak még mindig LOCAL-hoz szinkronizál.
ipv6 kikapcsolva.
most így néz ki:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
leesti.netinfor .INIT. 16 u - 1024 0 0.000 0.000 4000.00
etomsch.eu .INIT. 16 u - 1024 0 0.000 0.000 4000.00
mail2.tm-net.ru .INIT. 16 u - 1024 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 13 l 63 64 377 0.000 0.000 0.001
# ntpdate -q localhost
server 127.0.0.1, stratum 14, offset 0.000003, delay 0.02570
20 Dec 08:48:16 ntpdate[3640]: adjust time server 127.0.0.1 offset 0.000003 sec
tehát nem szinkronizál, de az ntpdate már jó, a gépemen fut a szerver.
dpalffy: köszi, akkor nem rdate-tel próbálkozom.
Petya
- A hozzászóláshoz be kell jelentkezni
Valakinek van ötlete?
# tcpdump -vv port 123
az.en gepem.ntp > rs12.lvs.iif.hu.ntp: [bad udp cksum f031!] NTPv4 client, strat 14, poll 6,.....
Mi okozhatja a rossz checksum-ot?
Petya
- A hozzászóláshoz be kell jelentkezni
Szerintem küldj 1 mailt az NIIF-es kollégáknak. Ha nem tudod az elérhetőségüket, privátban megadom.
Mik
- A hozzászóláshoz be kell jelentkezni
1. az rdate nem ntp-t hasznal, hanem a time szolgaltatast (37/tcp), ami csak masodpercre pontos; lasd inetd(8), de inkabb hasznalj ntpdate-et.
2. Egyertelmuen az ipv6-on szall el a time.kfki.hu fele a trace szerint. Par posttal elobb volt, hogy a -4 opcioval az ntp.conf-basn is ki lehet kapcsolni az ipv6-ot.
- A hozzászóláshoz be kell jelentkezni
fluxuskondenzátor esetleg?
------------------------------------
[Debian Sarge; ASUS P4T533-4; 2.4GHz CPU; 512MB RAM; XFree86; FluxBox]
- A hozzászóláshoz be kell jelentkezni
Üdv!
Új debian install, régi debian-ról /etc átmásolva.
Jelenség: ntp folymatosan fél órával előbbre állítja az órát a valós időnél.
Mi lehet ez?
--
- Hogyan lehet tanulni? - Jól kell tudni kérdezni. - Hogyan lehet jól kérdezni? - Ahhoz sokat kell tudni...
- A hozzászóláshoz be kell jelentkezni