Die meisten Menschen achten auf die Zeit. Wir stehen rechtzeitig auf, um unsere morgendlichen Rituale zu erfüllen und zur Arbeit zu gehen, eine Mittagspause einzulegen, Projektfristen einzuhalten, Geburtstage und Feiertage zu feiern, in ein Flugzeug zu steigen und so weiter.
Darüber hinaus: Einige von uns sind vom Zeitmanagement besessen. Meine Uhren werden solarbetrieben und beziehen die genaue Zeit vom National Institute of Standards and Technology () in Fort Collins, Colorado, über eine Langwellenradioverbindung. Die Zeitsignale werden mit Atomuhren synchronisiert, die ebenfalls in Fort Collins stehen. Mein Fitbit synchronisiert sich mit meinem Telefon, das sich mit dem Server synchronisiert, der letztlich mit Atomuhren synchronisiert wird.
Geräte achten ebenfalls auf die Zeit.
Es gibt viele Gründe, warum unsere Geräte und Computer eine genaue Zeitangabe benötigen. Zum Beispiel müssen im Bankwesen, an den Aktienmärkten und in anderen Finanzunternehmen Transaktionen ordnungsgemäß abgewickelt werden, wobei präzise zeitliche Abfolgen entscheidend sind.
Unsere Telefone, Tablets, Autos, GPS-Systeme und Computer erfordern eine exakte Zeiteinstellung. Ich möchte, dass die Uhr auf meinem Desktop-Computer die richtige Zeit anzeigt. Ich möchte, dass in meinem lokalen Kalender Erinnerungen zur richtigen Zeit erscheinen. Die richtige Zeit garantiert auch, dass Cron-Jobs und systemd zur richtigen Zeit gestartet werden.
Datum und Uhrzeit sind auch wichtig für die Protokollführung, da es erheblich einfacher ist, bestimmte Protokolle anhand von Datum und Uhrzeit zu finden. Zum Beispiel arbeitete ich einmal in DevOps (damals hieß es noch nicht so) und beschäftigte mich mit der Einrichtung eines E-Mail-Systems in North Carolina. Früher verarbeiteten wir mehr als 20 Millionen E-Mails pro Tag. Das Nachverfolgen von E-Mails über eine Reihe von Servern oder das Feststellen der genauen Reihenfolge von Ereignissen mithilfe von Protokolldateien auf geografisch verteilten Hosts kann viel einfacher sein, wenn die entsprechenden Computer zeitlich synchronisiert sind.
Es gibt viele Uhren, aber nur eine Zeit.
Linux-Hosts müssen beachten, dass es sowohl eine Systemzeit als auch eine RTC-Zeit gibt. RTC (Real Time Clock — Echtzeituhr) ist ein etwas merkwürdiger und nicht besonders präziser Begriff für die Hardwareuhr.
Die Hardwareuhr läuft kontinuierlich, auch wenn der Computer ausgeschaltet ist, und verwendet dazu eine Batterie auf dem Motherboard des Systems. Die Hauptfunktion der RTC besteht darin, die Zeit zu speichern, wenn keine Verbindung zu einem Zeitserver besteht. Zu Zeiten, als man nicht über das Internet mit einem Zeitserver verbinden konnte, musste jeder Computer über eine genaue interne Uhr verfügen. Betriebssysteme mussten beim Booten auf die RTC zugreifen, und der Benutzer musste die Systemzeit manuell über das Hardware-Setup der BIOS konfigurieren, um sicherzustellen, dass sie korrekt ist.
Die Hardwareuhr versteht das Konzept von Zeitzonen nicht; in der RTC wird nur die Zeit gespeichert, nicht die Zeitzone oder die Abweichung von UTC (Koordinierten Weltzeit, auch bekannt als GMT oder Greenwich Mean Time). Sie können die RTC mit einem Tool einstellen, das ich später in diesem Artikel vorstellen werde.
Die Systemzeit ist die Zeit, die das Betriebssystem auf den GUI-Uhren auf Ihrem Desktop, in der Ausgabe des Befehls date und in den Zeitstempeln der Protokolle anzeigt. Sie bezieht sich auch auf die Zeit der Erstellung, Änderung und Öffnung von Dateien.
Auf der Seite gibt eine vollständige Beschreibung der RTC und der Systemuhren.
Was ist mit NTP?
Computer auf der ganzen Welt verwenden NTP (Network Time Protocol), um ihre Zeit mit Standardreferenzuhren über das Internet über eine Hierarchie von NTP-Servern zu synchronisieren. Hauptzeitserver befinden sich auf Ebene 1 und sind direkt mit verschiedenen nationalen Zeitdiensten auf Ebene 0 über Satelliten, Radio oder sogar Modems über Telefonleitungen verbunden. Zeitdienste auf Ebene 0 können Atomuhren, einen Radioreceiver, der auf die von Atomuhren gesendeten Signale eingestellt ist, oder einen GPS-Empfänger sein, der hochgenaue Zeitsignale verwendet, die von GPS-Satelliten gesendet werden.
Auf den überwiegenden meisten Referenzservern sind mehrere tausend öffentlich zugängliche NTP-Server der Stratum 2 geöffnet, die für alle verfügbar sind. Viele Organisationen und Benutzer (einschließlich mir) mit einer großen Anzahl von Hosts, die einen NTP-Server benötigen, ziehen es vor, ihre eigenen Zeitserver zu installieren, sodass nur ein lokaler Host auf Stratum 2 oder 3 zugreift. Dann konfigurieren sie die verbleibenden Knoten im Netzwerk so, dass sie den lokalen Zeitserver verwenden. In meinem Heimnetzwerk handelt es sich dabei um einen Server der Stufe 3.
Verschiedene NTP-Implementierungen
Die ursprüngliche NTP-Implementierung ist ntpd. Dann kamen zwei neuere hinzu, chronyd und systemd-timesyncd. Alle drei synchronisieren die Zeit des lokalen Hosts mit einem NTP-Zeitserver. Der Dienst systemd-timesyncd ist nicht so zuverlässig wie chronyd, aber ausreichend für die meisten Zwecke. Wenn die RTC nicht synchronisiert ist, kann er die Systemzeit allmählich anpassen, um sich mit dem NTP-Server zu synchronisieren, wenn die lokale Systemzeit leicht abweicht. Der Dienst systemd-timesync kann nicht als Zeitserver verwendet werden.
ist eine NTP-Implementierung, die zwei Programme enthält: den Daemon chronyd und eine Befehlszeilenoberfläche namens chronyc. Chrony bietet einige Funktionen, die in vielen Fällen einfach unverzichtbar sind:
- Chrony kann sich erheblich schneller mit einem Zeitserver synchronisieren als der alte Dienst ntpd. Dies ist besonders vorteilhaft für Laptops oder Desktop-Computer, die nicht ständig laufen.
- Es kann Frequenzschwankungen ausgleichen, beispielsweise wenn ein Host in den Ruhezustand wechselt oder wenn die Taktfrequenz aufgrund plötzlicher Änderungen in der Frequenz, die bei geringer Last die Taktfrequenzen verlangsamen, variiert.
- Es löst zeitliche Probleme, die mit einer instabilen Netzwerkverbindung oder Netzwerküberlastung verbunden sind.
- Es regelt Verzögerungen im Netzwerk.
- Nach der initialen Zeitsynchronisation stoppt Chrony niemals die Uhren. Dies gewährleistet stabile und konsistente Zeitintervalle für viele Systemdienste und Anwendungen.
- Chrony kann sogar ohne Internetverbindung arbeiten. In diesem Fall kann der lokale Host oder Server manuell aktualisiert werden.
- Chrony kann als NTP-Server fungieren.
Noch einmal: NTP ist ein Protokoll, das auf einem Linux-Host mit Chrony oder systemd-timesyncd implementiert werden kann.
Die RPM-Pakete NTP, Chrony und systemd-timesyncd sind in den Standard-Repositories von Fedora verfügbar. RPM systemd-udev ist ein Ereignismanager des Kernels, der in Fedora standardmäßig installiert ist, aber nicht zwingend verwendet werden muss.
Sie können alle drei installieren und zwischen ihnen wechseln, aber das wird zusätzlichen Aufwand verursachen. Daher ist es besser, es zu vermeiden. Moderne Versionen von Fedora, CentOS und RHEL haben auf Chrony als Standardimplementierung umgestellt, und darüber hinaus verfügen sie über systemd-timesyncd. Ich finde, dass Chrony gut funktioniert, eine bessere Schnittstelle bietet als der NTP-Dienst, viel mehr Informationen bereitstellt und eine erhöhte Kontrolle ermöglicht, was Systemadministratoren sicher gefallen wird.
Deaktivierung der NTP-Dienste
Möglicherweise läuft bereits ein NTP-Dienst auf Ihrem Host. Falls dies der Fall ist, müssen Sie ihn deaktivieren, bevor Sie zu etwas anderem wechseln. Ich hatte chronyd laufen, also habe ich die folgenden Befehle verwendet, um ihn zu stoppen und zu deaktivieren. Führen Sie die entsprechenden Befehle für jeden NTP-Daemon aus, den Sie auf Ihrem Host verwenden:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Überprüfen Sie, ob der Dienst gestoppt und deaktiviert ist:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Prüfung des Status vor dem Start
Der Status der Systemzeitsynchronisierung zeigt an, ob der NTP-Dienst läuft. Da Sie NTP noch nicht gestartet haben, wird der Befehl timesync-status darauf hinweisen:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Eine direkte Statusabfrage liefert wichtige Informationen. Zum Beispiel führt der Befehl timedatectl ohne Argumente oder Parameter standardmäßig den Unterbefehl status aus:
[root@testvm1 ~]# timedatectl status
Lokale Zeit: Fr 2020-05-15 08:43:10 EDT
Universelle Zeit: Fr 2020-05-15 12:43:10 UTC
RTC-Zeit: Fr 2020-05-15 08:43:08
Zeitzone: Amerika/New_York (EDT, -0400)
Systemuhr synchronisiert: nein
NTP-Dienst: inaktiv
RTC in lokaler TZ: ja
Warnung: Das System ist so konfiguriert, dass die RTC-Zeit in der lokalen Zeitzone gelesen wird.
Dieser Modus kann nicht vollständig unterstützt werden. Es werden verschiedene Probleme
bei Zeitzonenänderungen und Anpassungen der Sommerzeit auftreten. Die RTC
Zeit wird niemals aktualisiert, sie ist auf externe Einrichtungen angewiesen, um sie
aufrechtzuerhalten. Wenn möglich, verwenden Sie RTC in UTC, indem Sie
'timedatectl set-local-rtc 0' aufrufen.
[root@testvm1 ~]#So erhalten Sie die lokale Zeit für Ihren Host, die UTC-Zeit und die RTC-Zeit. In diesem Fall wurde die Systemzeit auf die Zeitzone Amerika/New_York (TZ) eingestellt, die RTC-Zeit wurde auf die Zeit in der lokalen Zeitzone gesetzt, und der NTP-Dienst ist nicht aktiv. Die RTC-Zeit beginnt sich langsam von der Systemzeit zu entfernen. Das ist normal für Systeme, deren Uhren nicht synchronisiert wurden. Der Betrag der Abweichung auf dem Host hängt von der Zeit ab, die seit der letzten Systemsynchronisierung vergangen ist.
Wir haben auch eine Warnung erhalten, dass die RTC mit der lokalen Zeit verwendet wird – dies betrifft Zeitzonenänderungen und Sommerzeiteinstellungen. Wenn der Computer zu dem Zeitpunkt ausgeschaltet wird, wenn eine Änderung erforderlich ist, wird die RTC-Zeit nicht verändert. Aber für Server oder andere Hosts, die rund um die Uhr arbeiten, ist das im Allgemeinen kein Problem. Außerdem wird jeder Dienst, der die NTP-Zeit synchronisiert, die Zeit des Hosts bereits zu einem frühen Zeitpunkt im Startprozess korrigieren, sodass die Zeit nach dem Abschluss des Starts wieder korrekt ist.
Zeitzone einstellen
In der Regel geben Sie die Zeitzone während des Installationsvorgangs an, und Sie müssen sie später nicht mehr ändern. Es gibt jedoch Fälle, in denen es notwendig ist, die Zeitzone zu ändern. Es gibt mehrere Tools, die dabei helfen können. Um die lokale Zeitzone zu bestimmen, verwendet Linux Zeitzonendateien. Diese Dateien befinden sich im Verzeichnis /usr/share/zoneinfo. Standardmäßig trägt das System für meine Zeitzone Folgendes ein: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Aber Sie müssen solche Einzelheiten nicht wissen, um die Zeitzone zu ändern.
Das Wichtigste ist, den offiziellen Namen der Zeitzone für Ihren Standort und den entsprechenden Befehl zu kennen. Angenommen, Sie möchten die Zeitzone auf Los Angeles ändern:
[root@testvm2 ~]# timedatectl list-timezones | column
America/La_Paz Europe/Budapest
America/Lima Europe/Chisinau
America/Los_Angeles Europe/Kopenhagen
America/Maceio Europe/Dublin
America/Managua Europe/Gibraltar
America/Manaus Europe/HelsinkiJetzt können Sie die Zeitzone festlegen. Ich habe den Befehl date verwendet, um die Änderungen zu überprüfen, aber Sie können auch timedatectl verwenden:
[root@testvm2 ~]# date
Di 19. Mai 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Di 19. Mai 2020 01:48:23 PM PDT
[root@testvm2 ~]#Jetzt können Sie die Zeitzone Ihres Hosts wieder auf die lokale Zeit ändern.
systemd-timesyncd
Der systemd timesync-Daemon bietet eine leicht zu verwaltende NTP-Implementierung im Kontext von systemd. Er wird standardmäßig in Fedora und Ubuntu installiert. Er wird jedoch standardmäßig nur in Ubuntu gestartet. Ich bin mir über andere Distributionen nicht sicher. Sie können es selbst überprüfen:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfiguration von systemd-timesyncd
Die Konfigurationsdatei für systemd-timesyncd ist /etc/systemd/timesyncd.conf. Es handelt sich um eine einfache Datei mit weniger aktivierten Optionen als die alten NTP- und chronyd-Dienste. Hier ist der Inhalt dieser Datei (ohne zusätzliche Änderungen) auf meiner virtuellen Maschine mit Fedora:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048Der einzige Abschnitt, den sie enthält, abgesehen von Kommentaren, ist [Time]. Alle anderen Zeilen sind kommentiert. Es sind Standardwerte, die nicht geändert werden müssen (es sei denn, Sie haben einen bestimmten Grund dazu). Wenn Sie keinen NTP-Zeitserver in der Zeile NTP = definiert haben, wird standardmäßig in Fedora ein Backup-Zeitserver von Fedora verwendet. Ich füge normalerweise meinen Zeitserver hinzu:
NTP=myntpserverTimesync starten
So können Sie systemd-timesyncd aktivieren und starten:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Erstellter Symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Erstellter Symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#Einstellen der Hardwareuhr
So sieht die Situation nach dem Start von timesyncd aus:
[root@testvm2 systemd]# timedatectl
Lokale Zeit: Sa 2020-05-16 14:34:54 EDT
Universelle Zeit: Sa 2020-05-16 18:34:54 UTC
RTC-Zeit: Sa 2020-05-16 14:34:53
Zeitzone: America/New_York (EDT, -0400)
Systemuhr synchronisiert: ja
NTP-Dienst: aktiv
RTC in lokaler TZ: nein Ursprünglich beträgt der Unterschied zwischen RTC und lokaler Zeit (EDT) nicht mehr als eine Sekunde, und die Abweichung steigt in den folgenden Tagen um ein paar Sekunden. Da RTC keine Zeitzonen kennt, muss das Team von timedatectl einen Vergleich durchführen, um die erforderliche Zeitzone zu bestimmen. Wenn die RTC-Zeit nicht genau der lokalen Zeit entspricht, bedeutet dies, dass sie auch nicht mit der lokalen Zeitzone übereinstimmt.
Auf der Suche nach weiteren Informationen habe ich den Status von systemd-timesync überprüft und Folgendes gefunden:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Netzwerktimesynchronisation
Loaded: loaded (\/usr\/lib\/systemd\/system\/systemd-timesyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Erste Synchronisation mit Zeitserver 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Tasks: 2 (limit: 10365)
Memory: 2.8M
CPU: 476ms
CGroup: \/system.slice\/systemd-timesyncd.service
└─822 \/usr\/lib\/systemd\/systemd-timesyncd
May 16 09:57:24 testvm2.both.org systemd[1]: Starte Netzwerktimesynchronisation...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: Systemzeit nicht gesetzt oder zurückgesetzt, Wiederherstellung aus aufgezeichnetem Zeitstempel: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Netzwerktimesynchronisation gestartet.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Erste Synchronisation mit Zeitserver 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Beachten Sie die Protokollnachricht, in der steht, dass die Systemzeit nicht gesetzt oder zurückgestellt wurde. Der Timesync-Dienst stellt die Systemzeit basierend auf dem Zeitstempel ein. Zeitstempel werden vom Timesync-Daemon verwaltet und bei jeder erfolgreichen Synchronisation erstellt.
Das Kommando timedatectl kann den Wert der Hardwareuhr nicht aus der Systemuhr übernehmen. Es kann die Uhrzeit und das Datum nur aus dem an der Eingabeaufforderung eingegebenen Wert setzen. Sie können RTC auf denselben Wert wie die Systemzeit setzen, indem Sie den Befehl hwclock verwenden:
[root@testvm2 ~]# \/sbin\/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Lokale Zeit: Mon 2020-05-18 13:56:46 EDT
Universelle Zeit: Mon 2020-05-18 17:56:46 UTC
RTC-Zeit: Mon 2020-05-18 13:56:46
Zeitzone: America\/New_York (EDT, -0400)
Systemuhr synchronisiert: ja
NTP-Dienst: aktiv
RTC in lokaler TZ: jaDie Option —localtime zeigt an, dass die Hardwareuhr die lokale Zeit und nicht UTC anzeigt.
Warum brauchen Sie überhaupt RTC?
Jede Implementierung von NTP stellt die Systemuhr beim Start ein. Und wozu dann RTC? Es ist nicht ganz so: Dies geschieht nur, wenn Sie eine Netzwerkverbindung zu einem Zeitserver haben. Viele Systeme haben jedoch keinen ständigen Zugriff auf eine Netzwerkverbindung, daher sind die Hardware-Uhren nützlich, damit Linux basierend darauf die Systemzeit einstellen kann. Das ist besser, als die Zeit manuell einzustellen, auch wenn sie von der tatsächlichen Zeit abweichen kann.
Fazit
In diesem Artikel werden einige Werkzeuge zur Verwaltung von Datum, Uhrzeit und Zeitzonen behandelt. Das Tool systemd-timesyncd bietet einen NTP-Client, der die Zeit auf dem lokalen Host mit einem NTP-Server synchronisieren kann. systemd-timesyncd bietet jedoch keinen Serverdienst, weshalb Sie etwas anderes verwenden müssen, wenn Sie einen NTP-Server in Ihrem Netzwerk benötigen – z. B. Chrony, um als Server zu fungieren.
Ich bevorzuge es, eine einzige Implementierung für alle Dienste in meinem Netzwerk zu haben, daher verwende ich Chrony. Wenn Sie keinen lokalen NTP-Server benötigen oder es Ihnen nichts ausmacht, Chrony als Server und systemd-timesyncd als SNTP-Client zu verwenden. Es gibt keinen Grund, die zusätzlichen Funktionen von Chrony als Client zu nutzen, wenn die Funktionalität von systemd-timesyncd für Sie ausreichend ist.
Ein weiterer Punkt: Sie sind nicht verpflichtet, systemd-Tools für die NTP-Implementierung zu verwenden. Sie können eine ältere Version von ntpd, Chrony oder eine andere NTP-Implementierung verwenden. Systemd besteht aus vielen Diensten; viele davon sind optional, sodass sie deaktiviert und durch etwas anderes ersetzt werden können. Es ist kein riesiges monolithisches Monster. Man kann systemd oder Teile davon nicht mögen, aber man sollte eine fundierte Entscheidung treffen.
Ich mag die NTP-Implementierung in systemd, bevorzuge aber Chrony, weil es besser auf meine Bedürfnisse eingeht. Das ist Linux, Baby -)
Als Werbung
VDSina bietet , eine riesige Auswahl an Betriebssystemen für die automatische Installation, die Möglichkeit, jedes OS von Ihrem eigenen , bequeme eigene Entwicklung und tägliche Abrechnung. Denken Sie daran, dass wir unvergängliche Server haben, die der Zeit wirklich trotzen 😉
Quelle: habr.com
