Hallo zusammen,
auf einer (einzigen) Machine laeuft uns - wortwoertlich - die Zeit davon. Seit der letzten harten Zeitsynchronisation (`ntpdate <timeserver>` bei angehaltenem ntpd) vor ca 1.5 Stunden, ist die Uhr schon ueber 15 Minuten zu schnell gelaufen. Die Zeitdifferenz wird imemr groesser je laenger der Rechner laeuft. Seit wann das PRoblem existiert laesst sich im Moment nicht sagen. Alle Rechner haben bei uns denselben - neuesten - Patchlevel von CentOS 5.5 und dasselbe /etc/ntp.conf:
---------------------------------- # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 restrict -6 ::1
# Hosts on local network are less restricted. #restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server timeserver-1.embl.de server timeserver-2.embl.de server timeserver-3.embl.de
#broadcast 192.168.1.255 key 42 # broadcast server #broadcastclient # broadcast client #broadcast 224.0.1.1 key 42 # multicast server #multicastclient 224.0.1.1 # multicast client #manycastserver 239.255.254.254 # manycast server #manycastclient 239.255.254.254 key 42 # manycast client
# Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10
# Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. driftfile /var/lib/ntp/drift
# Key file containing the keys and key identifiers used when operating # with symmetric key cryptography. keys /etc/ntp/keys
# Specify the key identifiers which are trusted. #trustedkey 4 8 42
# Specify the key identifier to use with the ntpdc utility. #requestkey 8
# Specify the key identifier to use with the ntpq utility. #controlkey 8 [root@shelley ~]# ----------------------------------
Aus irgendeinem Grund synchronisiert dieser Host aber mit der lokalen Uhr (?) statt mit unseren Zeitservern:
[schlechter host]# ntpstat synchronised to local net at stratum 11 time correct to within 11 ms polling server every 1024 s [schlechter host]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== pbs-master2.emb 130.149.17.21 2 u 893 1024 377 0.292 -732094 123952. dns2.embl.de 131.188.3.220 2 u 832 1024 377 0.757 -615821 123543. *LOCAL(0) .LOCL. 10 l 26 64 377 0.000 0.000 0.001 [schlechter host]#
statt
[guter host]$ ntpstat synchronised to NTP server (192.54.41.96) at stratum 3 time correct to within 81 ms polling server every 1024 s [guter host]$ /usr/sbin/ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 10.1.104.79 130.149.17.21 2 u 36d 1024 0 0.244 0.129 0.000 *dns2.embl.de 131.188.3.220 2 u 785 1024 377 0.656 -1.405 0.772 LOCAL(0) .LOCL. 10 l 31 64 377 0.000 0.000 0.001 [guter host]$
Irgendeine Idee woran das liegen koennte oder wie man dem Problem auf die Schliche kommen koennte?
Gruss und Danke
frank
Frank Thommen wrote:
Irgendeine Idee woran das liegen koennte oder wie man dem Problem auf die Schliche kommen koennte?
Leere Batterien können sowas verursachen. Probier mal die zu tauschen. Für gewöhnlich sind das CR2032.
Am Wed, 23 Feb 2011 17:57:15 +0000 (UTC) schrieb Raphael Barabas raphi.b@gmx.de:
Leere Batterien können sowas verursachen. Probier mal die zu tauschen. Für gewöhnlich sind das CR2032.
Höchstens, wenn die Hardware zwischendurch stromlos ist.
Tobias Crefeld wrote:
Am Wed, 23 Feb 2011 17:57:15 +0000 (UTC) schrieb Raphael Barabas raphi.b@gmx.de:
Leere Batterien können sowas verursachen. Probier mal die zu tauschen. Für gewöhnlich sind das CR2032.
Höchstens, wenn die Hardware zwischendurch stromlos ist.
Ist sie aber nicht...
frank
Am Wed, 23 Feb 2011 14:16:01 +0100 schrieb Frank Thommen frank.thommen@embl-heidelberg.de:
auf einer (einzigen) Machine laeuft uns - wortwoertlich - die Zeit davon. Seit der letzten harten Zeitsynchronisation (`ntpdate
[..]
# Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. driftfile /var/lib/ntp/drift
Ist nur eine Vermutung, aber schau Dir mal Inhalt und insbesondere Rechte dieses Files an:
$ ls -l /var/lib/ntp/drift -rw-r--r-- 1 ntp ntp 8 24. Feb 10:05 /var/lib/ntp/drift
Aus irgendeinem Grund synchronisiert dieser Host aber mit der lokalen Uhr (?) statt mit unseren Zeitservern:
Dagegen spricht ja nichts, nur ist der Offset zu den Netzservern viel zu groß, um noch für eine Synchronisation genutzt werden zu können.
Irgendeine Idee woran das liegen koennte oder wie man dem Problem auf die Schliche kommen koennte?
syslog fragen? cat /var/log/messages |grep ntpd
Ansonsten noch: /etc/sysconfig/ntpd vergleichen mit einem "sauberen" Host. Ggf. dort temporär "-d" oder "-dd" zwecks geschwätzigerem Logging eintragen.
Gruß, Tobias.
Tobias Crefeld wrote:
Am Wed, 23 Feb 2011 14:16:01 +0100 schrieb Frank Thommen frank.thommen@embl-heidelberg.de:
auf einer (einzigen) Machine laeuft uns - wortwoertlich - die Zeit davon. Seit der letzten harten Zeitsynchronisation (`ntpdate
[..]
# Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. driftfile /var/lib/ntp/drift
Ist nur eine Vermutung, aber schau Dir mal Inhalt und insbesondere Rechte dieses Files an:
$ ls -l /var/lib/ntp/drift -rw-r--r-- 1 ntp ntp 8 24. Feb 10:05 /var/lib/ntp/drift
Inhalt: 0.000 auf dem abdriftenden Rechner, -32.889 und -15.508 auf zwei korrekt getimten Rechnern.
Die Rechte sind auf allen Rechnern genau wie von Dir beschrieben
Aus irgendeinem Grund synchronisiert dieser Host aber mit der lokalen Uhr (?) statt mit unseren Zeitservern:
Dagegen spricht ja nichts, nur ist der Offset zu den Netzservern viel zu groß, um noch für eine Synchronisation genutzt werden zu können.
Aber warum nimmt ntpd die lokale Uhr statt den Timeservern? Ich habe die Systemzeit gestern etwa zur Mittagszeit gesetzt. Unterdessen ist der Rechner fast zwei Stunden in der Zukunft.
Irgendeine Idee woran das liegen koennte oder wie man dem Problem auf die Schliche kommen koennte?
syslog fragen? cat /var/log/messages |grep ntpd
Leider nicht viel ausser den Mitteilungen beim Neustart von ntpd:
[...] Feb 23 15:21:10 shelley ntpd[994]: ntpd exiting on signal 15 Feb 23 15:24:26 shelley ntpd[2966]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Feb 23 15:24:27 shelley ntpd[2967]: precision = 1.000 usec Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface wildcard, 0.0.0.0#123 Disabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface wildcard, ::#123 Disabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface lo, ::1#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface eth0, fec0::c:218:8bff:fe7f:b332#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface eth0, 2002:d5b3:d122:c:218:8bff:fe7f:b332#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface eth0, fe80::218:8bff:fe7f:b332#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface lo, 127.0.0.1#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: Listening on interface eth0, 10.1.104.180#123 Enabled Feb 23 15:24:27 shelley ntpd[2967]: kernel time sync status 0040 Feb 23 15:24:27 shelley ntpd[2967]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Feb 23 15:27:46 shelley ntpd[2967]: synchronized to LOCAL(0), stratum 10 Feb 23 15:27:46 shelley ntpd[2967]: kernel time sync enabled 0001 Feb 23 15:40:56 shelley ntpd[2967]: ntpd exiting on signal 15 Feb 23 15:18:20 shelley ntpd[4048]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Feb 23 15:18:20 shelley ntpd[4049]: precision = 1.000 usec Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface wildcard, 0.0.0.0#123 Disabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface wildcard, ::#123 Disabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface lo, ::1#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface eth0, fec0::c:218:8bff:fe7f:b332#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface eth0, 2002:d5b3:d122:c:218:8bff:fe7f:b332#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface eth0, fe80::218:8bff:fe7f:b332#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface lo, 127.0.0.1#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: Listening on interface eth0, 10.1.104.180#123 Enabled Feb 23 15:18:20 shelley ntpd[4049]: kernel time sync status 0040 Feb 23 15:18:20 shelley ntpd[4049]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Feb 23 15:21:36 shelley ntpd[4049]: synchronized to LOCAL(0), stratum 10 Feb 23 15:21:36 shelley ntpd[4049]: kernel time sync enabled 0001 [...]
Ansonsten noch: /etc/sysconfig/ntpd vergleichen mit einem "sauberen" Host. Ggf. dort temporär "-d" oder "-dd" zwecks geschwätzigerem Logging eintragen.
/etc/sysconfig/ntpd uberall identisch:
------- # Drop root to id 'ntp:ntp' by default. OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no
# Additional options for ntpdate NTPDATE_OPTIONS="" -------
Mal schauen, was -dd bringt.
frank
Aus irgendeinem Grund synchronisiert dieser Host aber mit der lokalen Uhr (?) statt mit unseren Zeitservern:
Dagegen spricht ja nichts, nur ist der Offset zu den Netzservern viel zu groß, um noch für eine Synchronisation genutzt werden zu können.
Aber warum nimmt ntpd die lokale Uhr statt den Timeservern? Ich habe die Systemzeit gestern etwa zur Mittagszeit gesetzt. Unterdessen ist der Rechner fast zwei Stunden in der Zukunft.
Ich habe den Rechner unterdessen neu gebootet und im BIOS die Uhr korrekt gestellt (sie war etwa eine Stunden vor). Das hat aber nichts genuetzt. Die Uhr rennt immer noch davon.
[...]
Ansonsten noch: /etc/sysconfig/ntpd vergleichen mit einem "sauberen" Host. Ggf. dort temporär "-d" oder "-dd" zwecks geschwätzigerem Logging eintragen.
/etc/sysconfig/ntpd uberall identisch:
# Drop root to id 'ntp:ntp' by default. OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no
# Additional options for ntpdate NTPDATE_OPTIONS=""
Mal schauen, was -dd bringt.
Viel output, aber leider nichts, was fuer mich irgendwie verstaendlich waere ;-)
Ich musste aber feststellen, dass der Rechner (ein DELL OptiPlex 740 mit AMD Athlon X2, welcher sich nur mit 'noapic' ueberhaupt booten laesst) diverse andere Macken hat:
* Beim Starten von Xorg wird kurzfristig ein load z.T. bis fast 3 erzeugt und der Bildaufbau des gdmgreeters ist trotz nvidia-Treiber schnarchlangsam (Treppenstufen-Bildaufbau)
* Generelle "Langsamkeit" z.B. beim Starten von Terminals etc.
* ata/1 ist in top oft ganz oben
* Beim Shutdown gibt es machmal Kernel-Fehlermeldungen/crashes von tg3 (leider zu schnell weg, als dass man es abschreiben koennte)
Fuer mich ergibt sich daraus kein Bild, was da los sein koennte. Sieht jemand in diesen Symptomen etwas, wo man ansetzen koennte?
frank
Am Fri, 25 Feb 2011 14:26:01 +0100 schrieb Frank Thommen frank.thommen@embl-heidelberg.de:
Viel output, aber leider nichts, was fuer mich irgendwie verstaendlich waere ;-)
Laß doch mal ein "grep ntpd" drüber laufen und poste es. Wäre schon sehr microsoft-like, wenn sich weder daraus noch aus "dmesg" eine erhellende Info ergäbe.
BTW: Unterscheidet sich diese HW von anderen, funktionierenden Maschinen bei Euch?
Gruß, Tobias.
Tobias Crefeld wrote:
Am Fri, 25 Feb 2011 14:26:01 +0100 schrieb Frank Thommen frank.thommen@embl-heidelberg.de:
Viel output, aber leider nichts, was fuer mich irgendwie verstaendlich waere ;-)
Laß doch mal ein "grep ntpd" drüber laufen und poste es. Wäre schon sehr microsoft-like, wenn sich weder daraus noch aus "dmesg" eine erhellende Info ergäbe.
Der Output von etwa einer Stunde `ntpd -dd -u ntp:ntp -p /var/run/ntpd.pid` ist auf http://pastebin.de/15529 abgelegt. In dieser Zeit ist die Uhr ca. 45 Sekunden aus dem Ruder gelaufen. `dmsg`-Output ist in http://pastebin.de/15530.
BTW: Unterscheidet sich diese HW von anderen, funktionierenden Maschinen bei Euch?
Es ist in meinem Bereich der einzige OptiPlex 740, der einzige AMD-Rechner der mit Linux laeuft und der einzige, der 'noapic' braucht. Ansonsten sind mangels einer Policy bei uns fast alle Rechner individuell konfiguriert, d.h. fast jeder unterscheidet sich von fast jedem anderen in der Hardware zumindest ein bisschen.
lspci: [root@shelley ~]# lspci 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: nVidia Corporation C51 [GeForce 6150 LE] (rev a2) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02) [root@shelley ~]#
Gerade hat die Grafikkarte den Geist aufgegeben und ich arbeite mit vesa-Treiber und der Onboard-Grafik. Beim Einloggen schnellt der load auf 4.7 hoch....
Als Verzweiflungstat lasse ich jetzt erst mal einen Memtest uebers Wochenende laufen. ;-)
Gruss
frank