[Georg]

Moin, moin!

Seit ein paar Tagen habe ich das Problem, daß nach dem ersten Start die Uhrzeit nicht stimmt. Es scheint jeweils die Uhrzeit gesetzt zu sein, zu der ich die MLD runtergefahren habe. Wenn ich dann über das OSD die MLD neu starte, stimmt die Uhrzeit.

Ich kann den Zeitpunkt, seit dem das Problem auftritt, nicht genau bestimmen. Ich erinnere mich aber nicht, das vor dem letzten Update beobachtet zu haben.

System: MLD 5.3/RasPi3

Ciao, Georg

[clausmuus]

Hi,

wenn das Problem auftritt, müsste im sysinit Log zu sehen sein, das es ein Problem mit dem Netzwerk gab, bzw. der Zeitserver (ntp) nicht abgefragt werden konnte. Wenn letzteres zutrifft, könntest DU es damit versuchen, das Du in der /etc/rc.config einen anderen Zeitserver einträgst.

Claus

[Georg]

Tritt derzeit nicht mehr auf. Da scheint ein NTP-Server aus dem Pool nicht funktioniert zu haben.

Ciao, Georg

[Georg]

Ist gerade wieder aufgetreten. Im Startup-Log steht für ntp ein failed. Ich hab mir eben das Script dazu angesehen (/etc/init.d/ntp). Das funktioniert so vermutlich nicht zuverlässig.

Code: [Select]

start)
echo "Starting ntp-client"
if ping -c 1 $BUSYBOX_NTP_URL &>/dev/null; then
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
;;

$BUSYBOX_NTP_URL wird im rc.config auf de.pool.ntp.org gesetzt. Die Namensauflösung liefert bei jedem Aufruf einen zufällig ausgewählten Server aus dem Pool. Damit prüft der ping in der Regel einen anderen Server, als der ntpd anschließend verwendet.

Allerdings sollte es mich wundern, wenn regelmäßig ein Server aus dem Pool ausfällt und ich den dann auch noch erwische. Ich vermute also eher das Problem im Netzwerk. Durch das network Script bin ich auf Anhieb nicht komplett durchgestiegen. Auf jeden Fall steht bei mir in /tmp/network.interface ein eth0. Das Script sollte also korrekt durchgelaufen sein.

Ich werde wohl in die beiden Scripte ein paar Debugausgaben einbauen, die mir die ermittelte IP-Adresse von eth0 und die Adresse des verwendeten NTP-Servers auswerfen.

Ciao, Georg

[Georg]

Weiter geht es hier: https://www.minidvblinux.de/forum/index.php/topic,9231.msg71836/topicseen.html

[mafe68]

Anderen Zeitserver habe ich auch schon eingetragen nur das brachte auch keine Änderung.

[baltic]

Hallo,

ich vermute stark, dass hier einfach ntp manchmal, trotz der eingebauten Sicherung, das "Rennen" gegen das Netzwerk gewinnt und daher scheitert.

Ich verzichte daher bei stationären Systemen konsequent auf DHCP, sondern verwende eine manuelle, statische Konfiguration. Außerdem lasse ich den Router Zeitserver spielen. Das ist schneller und zuverlässiger, zudem entlastet es die öffentlichen Server und das Netz.

Ansonsten könnte man in das Startscript einen sleep-Befehl einbauen und damit die Wahrscheinlichkeit, dass das Netzwerk korrekt initialisiert ist, wenn die Zeit gesetzt werden soll, deutlich steigern.
Gruß
Peter

[Walter]

Hallo,

..
Ich verzichte daher bei stationären Systemen konsequent auf DHCP, sondern verwende eine manuelle, statische Konfiguration. Außerdem lasse ich den Router Zeitserver spielen. ..

nutze ebenfalls immer feste IP's, mit dem Router als Zeitserver trat der Fehler weiterhin auf, das habe ich bereits getestet.

Unter der mld-5.1 gab es den Fehler hier nicht ein Mal, erst unter mld-5.4, die Version 5.3 habe ich nicht verwendet.

mfg

[baltic]

Hi Walter,

ich habe die 5.1 nie benutzt, daher kann ich nichts zu den Unterschieden sagen.

Aber wenn ich mal spekulieren darf: Es handelt sich hier um ein Problem, dass erst mit der Einführung von systemd entstanden ist, weil erst seitdem verschiedene Prozesse parallel gestartet werden. Da kann halt mal der eine, mal der andere gewinnen. 
Vllt. war das bei der 5.1 noch anders, aber da müssen Leute, die schon länger dabei sind, Auskunft geben.

Gruß
Peter

[mafe68]

Der npt Fehler ist bei mir auf einem  BPI 5.1 System.

[clausmuus]

Die MLD verwendet kein systemd, sondern ein eigenes init System, da es zur der Zeit als die MLD auf einen parallelen Start der init Prozesse umgestellt wurde, noch keine derartigen Systeme gab.
Wenn alles wie geplant funktioniert, sollte das ntp init Script erst dann ausgeführt werden, wenn das Netzwerk funktionsfähig ist. Meine Vermutung ist, dass dies nicht immer funktioniert. Deshalb hatte ich hier https://www.minidvblinux.de/forum/index.php/topic,9231.msg71824.html#msg71824 bereits vorgeschlagen, im ntp init Script mal ein paar echo Ausgaben einzubauen, um zu sehen ob das Netzwerk beim Aufruf des ntp init Scriptes bereits funktioniert. Erst dann wissen wir genauer was da schief geht und wo etwas korrigiert werden muss.

[Walter]

Hallo,

füge mal in der /etc/init.d/ntp hinter der Zeile mit dem "if ping ..." ein
Code: [Auswählen]
echo "get Time"
ein, um zu sehen, ob die im Fehlerfall ausgeführt wird.

habe das so schon eingefügt,
aber seit dem ist der Fehler noch nicht aufgetreten.

Starting nfsclient:
done
Starting ntp-client
get Time
ntpd: sending query to 193.175.73.151
ntpd: reply from 193.175.73.151: offset:+19537,060117 delay:0,030995 status:0x24 strat:1 refid:0x004d4853 rootdelay:0,000000 reach:0x01
ntpd: no valid datapoints, no peer selected
ntpd: poll:2s sockets:0 interval:1s
ntpd: sending query to 193.175.73.151
ntpd: reply from 193.175.73.151: offset:+19537,060277 delay:0,031375 status:0x24 strat:1 refid:0x004d4853 rootdelay:0,000000 reach:0x03
ntpd: current time is 2018-10-18 09:15:57.161308
ntpd: setting time to 2018-10-18 14:41:34.221585 (offset +19537,060277s)
done
Mounting filesystems

mfg 

[Walter]

Moin,
seit paar Tagen habe ich

ntpd -n -q -N -ddd -p $BUSYBOX_NTP_URL

in der /etc/init.d/ntp stehen.
Die Zeit war bisher immer korrekt...
mfg