Jeder PC hat normalerweise eine Batterie gepufferte Hardware-Uhr,
welche beim Start ausgelesen wird.
Wenn Linux läuft wird das Datum und die Zeit aus der Hardware-Uhr
mittels Hardware-Timer und Software in Linux fortgeführt.
Um am wenigsten Probleme zu haben,
wird es empfohlen die Hardware-Uhr nicht auf die lokale Uhrzeit zu stellen,
sondern auf die Weltzeit
wikipedia.org UTC - Coordinated Universal Time.
Entsprechend ist dann die Differenz zwischen lokaler Zeit und UTC
über die Zeitzone zu korrigieren.
Die Mitteleuropäische Zeit ist demnach
MEZ = UTC + 1 bzw. MESZ = UTC +2 für die Sommerzeit.
Sollte die Zeit korrigiert werden müssen,
ist es also erforderlich erst die Zeitzone zu überprüfen,
dann die (Software-)Systemzeit einzustellen
und dann die neue Zeit in die Hardware-Uhr zu übertragen.
Zum setzen der Zeitzone wurde tzconfig verwendet,
was nun veraltet ist und durch dpkg-reconfigure tzdata ersetzt wurde.
su tzconfig bash: tzconfig: command not found whereis tzconfig Pfad des Befehls? tzconfig: /usr/sbin/tzconfig /usr/sbin/tzconfig deb 10 möchte das anders... WARNING: the tzconfig command is deprecated, please use: dpkg-reconfigure tzdata
Warum der alte Befehl nicht mehr benutzt werden soll, kann ich nur erahnen.
Wer sich noch an die nicht graphische Einrichtung von Debian erinnert,
kann zumindest den Dialog wieder entdecken.
su dpkg-reconfigure tzdata interaktives Menü folgt
Am Ende des Dialoges wird dann das lokale Datum samt Uhrzeit ausgegeben.
Current default time zone: 'Europe/Berlin' Local time is now: Fri Oct 9 19:28:42 CEST 2020. Universal Time is now: Fri Oct 9 17:28:42 UTC 2020.
Eleganter finde ich den Befehl timedatectl (via SystemD),
welcher Alternativ verwendet werden kann.
su timedatectl list-timezones listet mögliche Zeitzonen timedatectl set-timezone Europe/Berlin setzt Zeitzone
Die Zeitzone ist nun eingestellt.
Zum Lesen und Setzen des Datums oder der Zeit wird z.B. date MMTThhmm verwendet,
wobei eine mögliche Schreibweise folgende Parameter enthält.
MM der Monat,
TT der Tag,
hh die Stunden und
mm die Minuten sind.
Da das Datum offensichtlich schon stimmt,
ist lediglich die Uhrzeit ein wenig nachzustellen.
su date -s 11:20 setzt neue lokale Zeit auf 11:20 Fri 9 Oct 11:20:00 BST 2020 hwclock -w -w Überträgt Zeit in die HW-Uhr
Ob die Übertragung klappte überprüft man mit den Parameter -r.
su
hwclock -r -r read local time from HW-clock
2020-10-09 11:26:53.527322+02:00 Ergebnis im ISO 8601 format
exit
cal
October 2020
Su Mo Tu We Th Fr Sa
1 2 3
4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Zum Anfang
Bei der Installation von KVM hatte ich mächtige Probleme.
Eine Detail-Nachricht sah beispielsweise wie folgt aus.
su journalctl -xe Oct 01 22:37:39 b41 systemd[1]: libvirtd.service: Failed with result 'exit-code' -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit libvirtd.service has entered the 'failed' state with result 'exit-co Oct 01 22:37:39 b41 systemd[1]: Failed to start Virtualization daemon. -- Subject: A start job for unit libvirtd.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit libvirtd.service has finished with a failure. -- -- The job identifier is 5909 and the job result is failed. Oct 01 22:37:58 b41 ntpd[1117]: Soliciting pool server 213.209.109.45 Oct 01 22:38:24 b41 ntpd[1117]: Soliciting pool server 131.188.3.221 Oct 01 22:38:32 b41 ntpd[1117]: Soliciting pool server 88.99.76.254 Oct 01 22:38:35 b41 ntpd[1117]: Soliciting pool server 46.165.252.57 Oct 01 22:39:02 b41 ntpd[1117]: Soliciting pool server 144.76.76.107 Oct 01 22:39:31 b41 ntpd[1117]: Soliciting pool server 213.209.109.44 Oct 01 22:39:36 b41 ntpd[1117]: Soliciting pool server 2a01:4f8:121:247::2 Oct 01 22:39:42 b41 ntpd[1117]: Soliciting pool server 85.10.201.104 Oct 01 22:40:07 b41 ntpd[1117]: Soliciting pool server 185.11.138.90
Siehe z.B. findip-address.com
213.209.109.45 = ntp1.wtnet.de
131.188.3.221 = ntp1.rrze.uni-erlangen.de
...
Offensichtlich hat DEB 10 über verschiedene Adressen versucht eine Uhrzeit zu bekommen,
was bei mir wegen einer speziellen Konfiguration der Fritzbox nicht klappen kann.
Siehe Fritzbox Konfiguration Firewall, UPnP, NTP & DNS.
Das heißt, die Fritzbox holt sich von außen die korrekte Zeit und bietet sie selbst als Zeit-Server an.
Aber der Zugriff von Innen (Intranet) nach Außen (Internet) über den ntp-Port (UDP 123, TCP 119) ist gesperrt.
Linux benötigt für viele Prozesse eine genaue Uhrzeit und
man erleichtert sich auch selber das Leben,
wenn z.B. in Log-Dateien verlässliche Zeitstempel enthalten sind oder
Dateien oder ein Backup das richtige Datum und Uhrzeit hat.
Eine mögliche Liste der ntp-Zeitserver findet man beispielsweise auf folgenden Seiten.
ntppool.org NTP Pool Project
ntp-server.de NTP Server Deutschland
Zum Anfang
/etc/ntp.conf: pool 0.europe.pool.ntp.org Europäischer ntp Pool-Server
pool 0.freebsd.pool.ntp.org freebsd Pool-Server
pool 0.debian.pool.ntp.org DEB Pool-Server
pool 0.de.pool.ntp.org Deutscher ntp Pool-Server
oder konkret als einzelner Server
server ptbtime1.ptb.de für die
ptb.de
Physikalisch-Technischen Bundesanstalt in Braunschweig
server fritz.box für den lokalen heimischen Router
Ein bischen Hintergrundwissen findet man z.B. auf der PTP-Seite oder
auf
itwissen.info NTP (network time protokol).
Beziehungsweise, aufgrund der bestehenden Schwächen des Protokolls,
ist man schon auf dem Wege einen Nachfolger zu entwickeln.
Siehe ostfalia.de IoT-Konferenz_Paper.pdf über NTS aus 2017.
Zum Anfang
In meinen speziellen Fall holen sich alle im Intranet befindlichen Computer von der Fritzbox die Zeit.
Das hat zum einen den Vorteil,
dass man nicht unbedingt die Adressen der jeweiligen Rechner dahinter sieht.
Und andererseits wird dafür nicht von Innen ein weiteres Loch (Port UDP 123 oder TCP 119)
in die Firewall gebohrt...
Die Installation ist schnell gemacht.
Zunächst wird der ntp-Daemon Parameter in der Datei /etc/default/ntp geändert.
Eine Übersicht der Parameter findet sich z.B. unter
eecis.udel.edu ntpd command line options.
su
apt install ntp 18.10.18 DEB 9, bei DEB 10 bereits vorhanden
apt install ntp-doc noch ganz sinnvoll
nano /etc/default/ntp
NTPD_OPTS='-g' ändern zu -g < 1000 s wird synchronisiert
-4 DNS IPv4 Auflösung des Namens
NTPD_OPTS='-g -4 -U 0' -U 0 statt dynamisch, wird alle 5 min sync.
In meinen Fall müssen noch die Quellen angepasst werden.
Das heißt ich habe als erste Adresse fritz.box eingepflegt und
den Rest auskommentiert.
su nano /etc/ntp.conf evtl. Quellen bearbeiten driftfile /var/lib/ntp/ntp.drift enth. Zeitdifferenz ... #server ntp.your-provider.example server fritz.box = 192.168.178.1 ... # pool: <http://www.pool.ntp.org/join.html> # pool 0.debian.pool.ntp.org iburst auskommentiert # pool 1.debian.pool.ntp.org iburst da nicht erreichbar # pool 2.debian.pool.ntp.org iburst # pool 3.debian.pool.ntp.org iburst ... Standard Beschränkung, nicht geändert restrict -4 default kod notrap nomodify nopeer noquery limited restrict -6 default kod notrap nomodify nopeer noquery limited ... restrict 127.0.0.1 Ausnahme IPv4 restrict -6 ::1 Ausnahme IPv6, -6 ergänzt ... falls 192.168.178.35 die Uhrzeit benötigt #restrict 192.168.178.35 mask 255.255.255.0 notrap nomodify nopeer ...
Zum Neustart des ntp-Daemons oder Synchronisation der lokalen Zeit mit einen Zeit-Server
gibt es verschiedene Möglichkeiten.
su
/etc/init.d/ntp restart Dienst via Init neu starten oder
[ ok ] Restarting ntp (via systemctl): ntp.service.
service ntp restart Dienst neu starten oder
die bevorzugte Methode
systemctl restart ntp ab DEB 9 via SystemD möglich
Sollte es eine Fehlermeldung geben wie folgende,
kann das daran liegen dass noch andere Zeit-Dienste in Betrieb sind.
Ich hatte z.B. nur apt install chrony eingegeben, was offensichtlich schon reicht...
su systemctl restart ntp Failed to restart ntp.service: Unit ntp.service is masked. apt remove chrony ntp alles entfernen systemctl stop systemd-timesyncd timesyncd stoppen & disablen systemctl disable systemd-timesyncd apt install ntp neu installieren mit neuen Pfaden nano /etc/default/ntp Konfiguration ging verloren systemctl restart ntp und Neustart geht wieder
Danach kann die Uhrzeit auf verschiedenen Arten synchronisiert werden
und in die HW-Uhr übertragen werden.
su
timedatectl set-ntp 1 lokale Zeit mit Zeit-Server synchronisieren oder
/usr/sbin/ntpd -gq -g sync auch bei > 1000 sec Diff.
-q set time & quit
10 Oct 00:28:45 ntpd[11830]: proto: precision = 0.100 usec (-23)
...
10 Oct 00:28:54 ntpd[11830]: ntpd: time slew +0.000063 s
ntpd: time slew +0.000063s
hwclock -w --systohc Zeit in die HW-Uhr schreiben
Mit der ntpd -g Option kann man eine Synchronisation forcieren,
obwohl die lokale Zeit außerhalb der Toleranz von 1000 sec. ≈ 17 min. ist.
Zum Anfang
Statt die aktuellste Zeit einmalig in die Hardware-Uhr zu übertragen,
ist es viel eleganter sich in Zukunft immer die Zeit aus der Fritz-Box zu holen.
Damit der ntp-Server auch nach dem nächsten Booten gestartet wird, ist er noch zu Aktivieren.
su systemctl enable ntp ab DEB 9 möglich Synchronizing state of ntp.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable ntp
Zum Anfang
Unter Umständen kann es noch erforderlich sein den UDP Port 123 in beide Richtungen zu öffnen.
su iptables -A INPUT -p udp --sport 123 -j ACCEPT iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
Zum Anfang
Am eigenen Leibe habe ich feststellen müssen, das natürlich nicht alles so glatt läuft,
wie etliche mehr oder weniger voneinander abgeschriebene Anleitungen
aus dem Internet suggerieren möchten.
Daher hier eine Liste der möglichen Fehler.
ps -ef | grep ntpd root 12372 5289 0 00:58 pts/1 00:00:00 grep ntpd
Obige Zeile zeigt lediglich den eigenen Befehl statt, dass der ntp-Daemon läuft (wie unteres Beispiel).
Mögliche Ursachen:
/etc/ntp.conf.ps -ef | grep ntpd ntp 12703 1 0 18:01 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -4 -U 0 -u 117:124 root 12711 10964 0 18:02 pts/1 00:00:00 grep ntpd
oder zusätzlich mit dem Parameter -c /run/ntp.conf.dhcp.
ps -ef | grep ntpd ntp ... /usr/sbin/ntpd -p /var/run/ntpd.pid -g -4 -U 0 -c /run/ntp.conf.dhcp -u 116:122 root ... grep ntp
su systemctl status ntp ● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-10-10 01:14:25 CEST; 2min 53s ago Docs: man:ntpd(8) Process: 12555 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS) Main PID: 12561 (ntpd) Tasks: 2 (limit: 4915) Memory: 2.1M CGroup: /system.slice/ntp.service └─12561 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -4 -U 0 -u 117:124 Oct 10 01:14:25 b41 ntpd[12561]: proto: precision = 0.151 usec (-23) Oct 10 01:14:25 b41 ntpd[12561]: restrict: ignoring line 41, mask '::' unusable. Oct 10 01:14:25 b41 ntpd[12561]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature Oct 10 01:14:25 b41 ntpd[12561]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2020-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 Oct 10 01:14:25 b41 ntpd[12561]: Listen and drop on 0 v4wildcard 0.0.0.0:123 Oct 10 01:14:25 b41 ntpd[12561]: Listen normally on 1 lo 127.0.0.1:123 Oct 10 01:14:25 b41 ntpd[12561]: Listen normally on 2 enp37s0 192.168.178.35:123 Oct 10 01:14:25 b41 ntpd[12561]: Listening on routing socket on fd #19 for interface updates Oct 10 01:14:25 b41 ntpd[12561]: kernel reports TIME_ERROR: 0x6041: Clock Unsynchronized Oct 10 01:14:25 b41 ntpd[12561]: kernel reports TIME_ERROR: 0x6041: Clock Unsynchronized
Ohne su fehlt der untere Teil (ab Oct 10 01:14:25 b41 ntpd[12561]:...)
Immerhin läuft der ntp-Daemon nun.
Aber es ist noch ein Fehler in Zeile 43 oder 42 von enthalten,
je nachdem ob auf 32 Bit DEB 10 (buster) oder 64 Bit DEB 10 gestartet ist.
Also daran denken, die -6 in der Original-Datei /etc/ntp.conf fehlt.
Richtig sollte es heißen restrict -6 ::1.
Und die Daten aus /etc/ntp.conf werden unter Umständen,
nach Neustart von systemctl restart ntp nicht sofort übernommen.
Siehe Beschreibung in /run/ntp.conf.dhcp "Any changes...next DHCP event".
Die Bezeichnungen TIME_ERROR: und Clock Unsynchronized sind sehr unglücklich.
Besser wäre es von "TIME_INACCURACY" und "adjusting Clock" zu sprechen.
In dem Sinne sind folgende Meldungen harmlos.
Siehe "There's a comment in ntpd/ntp_loopfilter.c, at line 403"
linuxquestions.org
Antwort von Petri Kaukasoina...
0x6041 PLL,UNSYNC,NANO, FLL statt PLL verwendet
0x2041 PLL,UNSYNC,NANO
0x2001 PLL,-, NANO
0x0041 PLL,UNSYNC
Leider steht in der entsprechenden man page
z.B. man7.org "...constants used for ntp_adjtime() is a bit mask..."
nicht die Zuordnung der Variablen zu den Bits.
Aber man adjtimex verrät im Abschnitt --print für Linux kernels 2.0 bis 2.6, mehr ;-).
Leider ist sie mit Dezimal-Zahlen...
Mit der Tabelle in Hexadezimal-Zahlen,
wie hier passend zur Fehlermeldung, lässt sich mehr anfangen.
0x0001 PLL updates enabled 0x0002 PPS freq discipline enabled 0x0004 PPS time discipline enabled 0x0008 frequency-lock mode enabled 0x0010 inserting leap second 0x0020 deleting leap second 0x0040 clock unsynchronized 0x0080 holding frequency 0x0100 PPS signal present 0x0200 PPS signal jitter exceeded 0x0400 PPS signal wander exceeded 0x0800 PPS signal calibration error 0x1000 clock hardware fault 0x2000 resolution (0 = us, 8192 = ns) 0x4000 mode (0 = PLL, 16384 = FLL) 0x8000 clock source (0 = A, 32768 = B) Ich hoffe nun ist das Rätsel gelöst...
Zum Anfang
ntpq -pn ntpq: read: Connection refused
Ob nun fritz.box oder 0.debian.pool.ntp.org,
in beiden Fällen erzeugt ntp-Query diese Fehlermeldung.
Warum erklärte sich nach Stunden langen suchen...
Siehe auf der Canonical Seite bugs.launchpad.net.
ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
Eine Meldung wie folgende (ohne *), bedeutet auch keine Verbindung zu einen ntp-Server.
Auffällig ist es auch dass delay, offset und jitter Null sind.
ntpq -pn4 -4 only IPv4
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.178.1 134.71.66.21 2 u 84 128 377 0.261 0.976 0.338
Der * zeigt an, dass dieser Server 192.168.178.1 = fritz.box zur Zeit genutzt wird.
Ändert man nun /etc/ntp.conf, hat das jedoch keinen Einfluss.
Eine Erklärung fand ich in /run/ntp.conf.dhcp...
Unterbinden läßt sich das, indem man in /etc/default/ntp explizit den Pfad rein schreibt.
z.B. NTPD_OPTS='-g -4 -U 0 -c /etc/ntp.conf' .
Zum Anfang
su
/usr/sbin/ntpd -gqd -g sync auch bei > 1000 sec Diff.
-q set time & quit
-d Increase debug verbosity level
17 Oct 23:26:50 ntpd[14821]: ntpd 4.2.8p12@1.3728-o (1): Starting
17 Oct 23:26:50 ntpd[14821]: Command line: ntpd -gqd
17 Oct 23:26:50 ntpd[14821]: proto: precision = 0.100 usec (-23)
Finished Parsing!!
config_access: top-level node 0x55ddb97ea300: ippeerlimit -1
hack_restrict: op RESTRICT_FLAGS addr 0.0.0.0 mask 0.0.0.0 ippeerlimit -1 mflags 00000000 rflags 00000bd0
config_access: top-level node 0x55ddb97ea4b0: ippeerlimit -1
hack_restrict: op RESTRICT_FLAGS addr :: mask :: ippeerlimit -1 mflags 00000000 rflags 00000bd0
config_access: top-level node 0x55ddb97ea560: ippeerlimit -1
hack_restrict: op RESTRICT_FLAGS addr 127.0.0.1 mask 255.0.0.0 ippeerlimit -1 mflags 00000000 rflags …
config_access: top-level node 0x55ddb97ea610: ippeerlimit -1
hack_restrict: op RESTRICT_FLAGS addr 192.168.178.1 mask 255.255.255.255 ippeerlimit -1 mflags 00000000…
config_access: top-level node 0x55ddb97ea6e0: ippeerlimit -1
restrict source template ippeerlimit -1 mflags 4000 rflags 380
hack_restrict: op RESTRICT_FLAGS addr (null) mask (null) ippeerlimit -1 mflags 00004000 rflags 00000380
17 Oct 23:26:50 ntpd[14821]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
17 Oct 23:26:50 ntpd[14821]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2020…
event at 0 0.0.0.0 c01e 0e TAI 37 leap 201701010000 expires 202012280000
move_fd: estimated max descriptors: 1024, initial socket boundary: 16
17 Oct 23:26:50 ntpd[14821]: Listen and drop on 0 v6wildcard [::]:123
17 Oct 23:26:50 ntpd[14821]: unable to bind to wildcard address 0.0.0.0
- another process may be running - EXITING
nur welcher Prozess stört?
Siehe auch in /var/log/daemon.log
Ok, Fehler gefunden.
Ich habe versäumt vorher zu stoppen und danach wieder zu starten.
Richtig lautet es also wie folgt:
su systemctl stop ntp /usr/sbin/ntpd -gqd systemctl start ntp
Zum Anfang
ntptrace localhost: stratum 3, offset 0.000058, synch distance 0.954127 192.168.178.1: timed out, nothing received
Egal welcher Zeitserver in /etc/ntp.conf verwendet wird,
die IP-Adresse 192.168.178.1 bleibt bestehen (siehe weiter oben /run/ntp.conf.dhcp).
Das Time out ist noch nicht geklärt...
cat /var/lib/ntp/ntp.drift -11.202
Der Wert scheint sich nicht zu verkleinern oder zu verändern.
Doch ;-) Es dauert...
Zum Anfang
ntpstat bash: ntpstat: command not found whereis ntpstat ntpstat: su apt install ntpstat exit ntpstat synchronised to NTP server (192.168.178.1) at stratum 3 time correct to within 47 ms polling server every 256 s
Sieht eigentlich gut aus...
Zum Anfang
su apt install net-tools netstat -tulpen | grep -i :123 udp 0 0 192.168.178.35:123 0.0.0.0:* 0 278317 14387/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 0 278315 14387/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 0 278311 14387/ntpd
Ob das nun gut oder schlecht ist?
Der Ordner /var/log/ntpstats/ ist leer...
Forsche vielleicht ein anderes Mal...
Zum Anfang
ntpdate ist veraltet und verwendet zwar auch das ntp-Protokoll,
ist aber keine wirkliche Alternative zu einen echten ntp-Daemon.
Man kann es aber benutzten um einmalig die lokale Uhr und die HW-Uhr einzustellen und
ist hier daher der Ausführlichkeit aufgeführt.
su apt install ntpdate ntpdate is deprecated -> sntp
In Synaptic kann man es nochmals lesen:
It is not sufficient, however, for maintaining an accurate clock in the long run.
An der Konfigurations-Datei muss nichts verändert werden und steht hier nur zur Info.
su nano /etc/default/ntpdate NTPDATE_USE_NTP_CONF=yes Daten kommen von /etc/ntp.conf NTPSERVERS="0.debian.pool.ntp.org 1.deb..."
Da mit den "yes" bereits auf /etc/ntp.conf verwiesen wird,
wird die folgende Zeile mit den ntp-Server ignoriert.
Testweise kann sich der Client (lokale PC) die Zeit direkt von der Fritzbox holen.
Leider fehlt wieder der Pfad zum Befehl, was ich dann erst nachholen muss...
su ntpdate fritz.box bash: ntpdate: command not found echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PATH=$PATH:/usr/sbin
Vor dem Aufruf von ntpdate sollte der ntp-Daemon abgeschaltet sein
und danach wieder eingeschaltet werden.
su systemctl stop ntp ntpdate fritz.box 17 Oct 16:38:38 ntpdate[11539]: the NTP socket is in use, exiting systemctl start ntp
Zum Anfang
timesyncd ist eine weitere abgespeckte Möglichkeit zu einen ntp-Daemon.
Da diese Lösung inkompatibel zum ntp-Daemon ist, ist er (ntp) vorher zu entfernen.
Alle übrigen hier erwähnten Daemons, sollten natürlich auch vorher entfernt sein.
su apt remove ntp Konfig. bleibt erhalten nano /etc/systemd/timesyncd.conf Kommentar raus nehmen & URL eintragen ... [Time] NTP=fritz.box FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org ... #RootDistanceMaxSec=5 ...
Der Service kann auf verschiedene Arten gestartet werden und nach dem Neustart erhalten bleiben.
su
timedatectl set-ntp true
oder bevorzugt via
systemctl start systemd-timesyncd jetzt starten
systemctl enable systemd-timesyncd nach Neustart wieder aktiv
Die Überprüfung schlug fehl, da ich versäumt habe ntp zu entfernen...
su
systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Condition: start condition failed at Fri 2020-10-09 20:06:29 CEST; 3min 27s ago
└─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
Docs: man:systemd-timesyncd.service(8)
Oct 08 22:22:55 b41 systemd[1]: Condition check resulted in Network Time Synchronization being skipped.
Oct 09 20:06:29 b41 systemd[1]: Condition check resulted in Network Time Synchronization being skipped.
Beziehungsweise folgender Test zeigt, dass der Service inaktiv ist.
timedatectl status
Local time: Mon 2020-10-19 01:25:45 CEST
Universal time: Sun 2020-10-18 23:25:45 UTC
RTC time: Sun 2020-10-18 23:25:46
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
Alles wieder stoppen geht mit folgenden Befehlen.
su systemctl stop systemd-timesyncd systemctl disable systemd-timesyncd
Zum Anfang
Eigentlich dachte ich, so langsam ist ja mal gut - mich verlässt,
nach der vielen Fehlersuche und dem Graben im Indernet, die Geduld...
Doch dann stieß ich auf folgende Seite.
debian.org Paket: chrony
Sie suggeriert das bei Debian dies der default-Daemon ist.
Ich wäre am liebsten geneigt einfach auf die entsprechende Seite zu referenzieren,
aber nichts ist beständiger als die Veränderung.
Daher hier noch eine Kurzanleitung.
Auch chrony duldet keine weiteren Daemons neben sich und
man sollte sie sicherheitshalber vorher de-installieren.
su apt install chrony Inastallation erzeugt konfig. Datei nano /etc/chrony/chrony.conf pool 2.debian.pool.ntp.org iburst -> fritz.box logdir /var/log/chrony zur Info systemctl start chronyd Start systemctl enable chrond nach Neustart beständig chronyc tracking Test
Start und Test habe ich nicht mehr durchgeführt...
Zum Anfang
Zum Anfang