[Georg]

Heute war es endlich mal wieder soweit:

Code: [Select]

Init network
Starting DHCP connection for: eth0                                    done
                                                           Waiting for ntp

Starting ntp-client
Before NTP ok
                                                                    failed
After NTP ok

Das Ping auf den lokalen Server vor und nach dem ntp funktioniert also, der Ping auf den NTP-Server nicht. Um sicherzustellen, daß der Internetzugang funktioniert, baue ich gleich auch noch was in das Script ein. Ich glaub allerdings nicht, daß es da ein Problem gab.

Hier nochmal das Script dazu (schon mit dem Internet-Test):

Code: [Select]

echo "Starting ntp-client"
if ping -c 1 gbox.net &>/dev/null; then
echo "Internet ok"
fi
if ping -c 1 samwise.home.gbox.net &>/dev/null; then
echo "Before NTP ok"
fi
if ping -c 1 $BUSYBOX_NTP_URL &>/dev/null; then
echo "get Time"
if [ -e /etc/lasttime ]; then
# if the clock jumped backward, wait until the clock is set
ntpd -n -q -p $BUSYBOX_NTP_URL
fi
ntpd -p $BUSYBOX_NTP_URL
check_status
else
check_status 1
fi
if ping -c 1 samwise.home.gbox.net &>/dev/null; then
echo "After NTP ok"
fi

Ciao, Georg

[clausmuus]

Hm, mach mal zusätzlich nen ping auf google.com und außerdem auf eine IP Adresse im Internet. Und lass das "&>/dev/null" beiden pings weg.
Ich habe die Vermutung, dass die DNS Auflösung zu dem Zeitpunkt nicht klappt.

[Georg]

Laß dich nicht von den Namen täuschen. Die Domain gbox.net gehört mir. Der Rechner hinter gbox.net steht bei einem Hoster im Internet. Ich benutze home.gbox.net als lokale Domain in meinem Intranet und mein lokaler DNS-Server weiß, wie er damit umgehen muß. Wenn ich also samwise.home.gbox.net anpinge, bleibt das in meinem Intranet. Ein Ping auf gbox.net dagegen geht ins Internet.

Die lokale DNS-Auflösung hat definitiv funktioniert, der DNS-Server ist per DHCP also richtig zugewiesen worden. Daß die DNS-Auflösung bei meinem Provider genau in dem Moment nicht funktioniert, halte ich für sehr unwahrscheinlich. Könnte noch die Zuweisung des Gateway falsch sein. Das war bisher aber auch nie der Fall, denn ein anschließendes Holen der Zeit per ntp via SSH-Konsole hat immer funktioniert. Ich halte es für wahrscheinlicher, daß die Anfrage nach pool.ntp.org gelegentlich eine Adresse liefert, bei der der Server auf ein einzelnes Ping nicht oder nicht schnell genug antwortet.

Aber man weiß ja nie. Daher hier die Ausgabe des Scripts mit den Änderungen:

Code: [Select]

Starting ntp-client
PING gbox.net (88.198.46.204): 56 data bytes
64 bytes from 88.198.46.204: seq=0 ttl=57 time=20.796 ms

--- gbox.net ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 20.796/20.796/20.796 ms
Internet ok
Before NTP ok
PING de.pool.ntp.org (213.172.105.106): 56 data bytes
64 bytes from 213.172.105.106: seq=0 ttl=57 time=16.805 ms

--- de.pool.ntp.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 16.805/16.805/16.805 ms
get Time
ntpd: setting time to 2018-11-05 21:33:10.328151 (offset +43,050751s)
                                                                                            done
After NTP ok

Btw.: Ich hatte eben einen Durchgang, bei dem nicht die Meldung "ntpd: setting time to ..." kam, sondern der Text "alarm clock". Hat das schonmal jemand gesehen?

Und jetzt heißt es wieder warten ...

Ciao, Georg

[clausmuus]

meine Vermutung mit dem DNS ist, dass zwar die Lokale Namensauflösung funktioniert, aber die Nachfrage beim Externen DNS Server nach dem externen Namen scheitert.
Mit deiner jetzigen Anpassung sehen wir dann beim nächsten Fehler etwas genauer...

[Georg]

Ich hab gerade etwas experimentiert. Einfach ein Script, das in einer Schleife immer wieder ein Ping mit Namensauflösung auf pool.ntp.org macht. Das läuft in der Regel flott durch. Gelegentlich hakt es aber auch gewaltig. Gerade das extrem mit 18 Fehlern bei 99 Versuchen. Die DNS-Auflösung funktioniert, das Ping scheitert:

Code: [Select]

PING pool.ntp.org (161.53.131.231) 56(84) bytes of data.

--- pool.ntp.org ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

69: fail

Interessanterweise habe ich bei den 99 Versuche 18 mal diese nicht funktionierende Adresse zurückgeliefert bekommen. Das heißt, bei jedem Fehlversuch war es dieselbe Adresse.

Ich würde gerne die DNS-Auflösung vom Ping und dem ntpd-Aufruf trennen. Dann könnte man ein paarmal versuchen, einen pingbaren Server zu finden und dann damit die Zeit holen. Mit nslookup geht das aber nicht so einfach, das liefert nicht einfach nur die Adresse zurück.

Ciao, Georg

[clausmuus]

Du könntest ja beim ping die IP Adresse angeben.

[Georg]

Mit "dig +short <Name>" sollte das gehen. So liefert dig nur die IP-Adresse zurück. Damit kann man in einem Script arbeiten.

Ciao, Georg

[Georg]

Gerade noch was ausprobiert:

Code: [Select]

> ntpdate -q 161.53.131.231
server 161.53.131.231, stratum 3, offset 0.036042, delay 0.06802
 6 Nov 10:28:25 ntpdate[3796]: adjust time server 161.53.131.231 offset 0.036042 sec

Der Server antwortet nach wie vor nicht auf das Ping, als NTP-Server funktioniert er hingegen. Damit stellt sich die Frage, ob es überhaupt eine gute Idee ist, die Erreichbarkeit per Ping testen zu wollen. Eventuell solle man einfach den ntpd dafür benutzen. Was spricht dagegen?

Ciao, Georg

[clausmuus]

Wenn der Server nicht erreichbar ist kann es minutenlang dauern, bis der ntp Befehl abbricht und ein Fehler zurück gibt. Beim ping kann hingegen angegeben werden, wie lange höchstens gewartet werden soll.
Da aber einige andere Dienste (z.B. der VDR) erst nach dem ntp gestartet werden dürfen, würde sich der gesamte Bootvorgang dann um Minuten verlängern.

[baltic]

Daher nochmal meine Empfehlung: Wenn irgend möglich, nehmt einen Zeitserver aus dem LAN. Viele Router bieten ja entsprechende Möglichkeiten.

[clausmuus]

Ja, guter Vorschlag. Wer Probleme hat sollte wenn möglich einen lokalen ntp Server eintragen.

[Walter]

Hallo,
die Probleme traten auch mit einem lokalen ntp auf, habe ich bereits getestet.
Warum soll das an dem ntp Server liegen, unter Rasbian etc funtioniert es doch auch?
mfg

[Georg]

Moin Walter,

dann hast du aber ein anderes Problem als ich. Bei mir ist der lokale Server auch im Fehlerfall erreichbar.

Ciao, Georg

[clausmuus]

Beim Raspbian muss nicht auf den ntp gewartet werden. Beim VDR ist's aber wichtig, da der einen größeren Zeitsprung nicht mag.

[Georg]

@Claus: Kannst du "dig" noch in die MLD 5.3 aufnehmen? Oder machst du da nichts mehr dran?

Ciao, Georg