ntp - unable to bind to wildcard socket address 0.0.0.0

[petrolman]

Hallo,
die Zeitsynchronisierung funktioniert mit ntp nicht. Ich habe bereits über Google nach einer Lösung gesucht, aber ich komme damit nicht klar.

Wenn ich ntp starte, erhalte ich folgende Meldung in syslog (auf einem alten Lenny System):

ntpd[15411]: ntpd 4.2.4p4@1.1520-o Sun Nov 22 16:14:34 UTC 2009 (1)
ntpd[15412]: precision = 1.000 usec
ntpd[15412]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
ntpd[15412]: Listening on interface #1 wildcard, ::#123 Disabled
ntpd[15412]: Listening on interface #2 lo, ::1#123 Enabled
ntpd[15412]: Listening on interface #3 eth1, fe80::21e:c9ff:feef:c086#123 Enabled
ntpd[15412]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
ntpd[15412]: Listening on interface #5 eth1, 192.168.2.17#123 Enabled
ntpd[15412]: kernel time sync status 0040

Wenn ich dann entsprechend dieser Anleitung https://wiki.ubuntuusers.de/Systemzeit ntpd -q -g -x -n aufrufe, erscheint in syslog

ntpd[18630]: ntpd 4.2.4p4@1.1520-o Sun Nov 22 16:14:34 UTC 2009 (1)
ntpd[18630]: precision = 1.000 usec
ntpd[18630]: unable to bind to wildcard socket address 0.0.0.0 - another process may be running - EXITING

Ich wüsste nicht, welcher Prozess das sein soll. Wenn ich den Daemon ntp stoppe gibt es keinen weiteren ntp Prozess.

Dann habe ich ntpdate installiert, ntpd gestoppt, und mit ntpdate -u 0.debian.pool.ntp.org die Zeit synchronisiert. Das funktioniert! ntpdate soll man aber nicht mehr verwenden. Also habe ich es wieder deinstalliert.

In der /etc/ntp.conf habe ich als einzige Änderung die Server eingetragen und alles andere so stehen lassen.
server 0.de.pool.ntp.org iburst dynamic
server 1.de.pool.ntp.org iburst dynamic
server 2.de.pool.ntp.org iburst dynamic
server 3.de.pool.ntp.org iburst dynamic

Was stimmt denn nicht?

[dufty2]

Du hast doch schon ntpd am laufen.
Dann versuchst Du ihn nochmal per "ntpd -q -g -x -n" zu starten und das gibt natürlich Kleinholz.

Der Befehl "ntpd -q -g -x -n" ist ähnlich wie ntpdate gedacht zum _einmaligen_ holen der Zeit von einem anderen Zeitserver.

Wenn Du Deinen ntpd abfragen willst, solltest Du
ntpq -np
benutzen.

[petrolman]

ntpq -np hatte ich auch mal eingegeben.

remote refid st t when poll reach delay offset jitter
==============================================================================
46.165.212.205 161.143.24.141 2 u 646 64 0 0.000 0.000 0.000
192.53.103.108 .INIT. 16 u - 1024 0 0.000 0.000 0.000
129.70.132.36 .INIT. 16 u - 1024 0 0.000 0.000 0.000
131.234.137.24 .INIT. 16 u - 1024 0 0.000 0.000 0.000

Aber die Zeit wird nicht synchronisiert. Nagios zeigt mir jetzt schon wieder einen Offset von über 8 Sekunden an.

/usr/local/nagios/libexec/check_ntp_time -H 0.de.pool.ntp.org -w 2 -c 3
NTP CRITICAL: Offset 8,971366525 secs|offset=8,971367s;2,000000;3,000000;

Deshalb habe ich die Zeit ja manuell synchronisieren wollen, um zu sehen, warum es nicht funktioniert und welche Fehler auftreten.

[dufty2]

Wenn Du manuell synchronisieren willst (also einmalig), musst Du zuvor Deinen ntpd(emon) stoppen:
/etc/init.d/ntp stop
Danach kannst Du ein ntpdate oder ein "ntpd -q -g -x -n" ausführen.

Ein "INIT" bei der "ntpq -np" zeigt an, dass der betreffende Server gar nicht erreicht wird:
iptables?, sonstige Netzwerkprobleme?, server ist aus, etc.

lenny, dann ist vermutlich schon ein etwas ältere Kiste?
Batterie schwach?
Wenn die Systemzeit sehr stark "davongaloppiert", gibt der ntpd irgendwann auf.

[petrolman]

ntp hatte ich natürlich gestoppt, als ich es manuell aufgerufen habe.

ntpd -q -g -x -n

Das Kommando hängt dann etwa 20 Sekunden und in syslog erscheint die Meldung
ntpd[23659]: no reply; clock not set

Das hätte ich schon im ersten Beitrag mit aufführen können. Auf dem Server (PE2950) ist kein iptable konfiguriert, da es ein interner Server, der hinter einem ipcop angeschlossen ist. ntp läuft auf den anderen Servern problemlos. Da sieht es nach dem Start in syslog so aus:

ntp[31518]: Starting NTP server: ntpd.
ntpd[31525]: proto: precision = 0.123 usec
ntpd[31525]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
ntpd[31525]: Listen and drop on 1 v6wildcard :: UDP 123
ntpd[31525]: Listen normally on 2 lo 127.0.0.1 UDP 123
ntpd[31525]: Listen normally on 3 eth0 192.168.2.10 UDP 123
ntpd[31525]: Listen normally on 4 lo ::1 UDP 123
ntpd[31525]: Listen normally on 5 eth0 fe80::3a2c:4aff:fec4:ef32 UDP 123
ntpd[31525]: peers refreshed
ntpd[31525]: Listening on routing socket on fd #22 for interface updates

Da ist nichts "disabled".

Also "no reply". Die Antwort sollte von den Zeitservern kommen, oder?

[rendegast]

Das ist aber kein virtualisierter Rechner (vServer),
bei dem evtl. die Host-Zeit davongaloppiert?

[petrolman]

Nein, ist es nicht. Ich habe nun openntpd installiert und es sieht so aus, als wenn ganz langsam die Zeit wieder angeglichen wird.

Meldungen von Nagios
NTP CRITICAL: Offset 12,02196074 secs|offset=12,021961s;2,000000;3,000000;
NTP CRITICAL: Offset 11,90743291 secs|offset=11,907433s;2,000000;3,000000;
NTP CRITICAL: Offset 11,82390499 secs|offset=11,823905s;2,000000;3,000000;
NTP CRITICAL: Offset 11,82037663 secs|offset=11,820377s;2,000000;3,000000;
NTP CRITICAL: Offset 11,81478238 secs|offset=11,814782s;2,000000;3,000000;
NTP CRITICAL: Offset 11,78782523 secs|offset=11,787825s;2,000000;3,000000;
NTP CRITICAL: Offset 11,77308595 secs|offset=11,773086s;2,000000;3,000000;
NTP CRITICAL: Offset 11,65764987 secs|offset=11,657650s;2,000000;3,000000;

Meldungen in syslog
ntpd[31376]: ntp engine ready
ntpd[31376]: peer 84.200.55.104 now valid
ntpd[31376]: peer 176.9.253.75 now valid
ntpd[31376]: peer 144.76.14.132 now valid
ntpd[31376]: peer 131.188.3.221 now valid
ntpd[31268]: adjusting local clock by 11.867997s
ntpd[31379]: adjusting local clock by 11.827175s
ntpd[31375]: adjusting local clock by 11.821788s
ntpd[31379]: adjusting local clock by 11.819661s
ntpd[31375]: adjusting local clock by 11.750413s
ntpd[31268]: adjusting local clock by 11.767473s
ntpd[31379]: adjusting local clock by 11.680533s
ntpd[31375]: adjusting local clock by 11.666696s

Wenn die Zeit "davongaloppiert", hat die Batterie auf dem Mainboard kein Saft mehr? Jetzt fängt auch noch der zweite PE2950 an...