Der Linux-Befehl "date -s" funktioniert nicht, um das Datum auf einem Server zu ändern

10851
nelaaro 
date +%T --set="12:19:06" 12:19:06 date Mon Nov 26 12:37:32 SAST 2012  date 112613232012 Mon Nov 26 13:23:00 SAST 2012 date Mon Nov 26 13:42:27 SAST 2012

Ich habe viele verschiedene Formen dieses Befehls ausprobiert, aber nichts scheint zu funktionieren. Das Ändern des Datums auf diesem Computerserver als VM funktioniert nicht.

Unsere Nachrichten zeigen Nachrichten wie diese an

ntpd [3496]: Zeitkorrektur von -1098 Sekunden überschreitet die Grenzwertgrenze (1000); Stellen Sie die Uhr manuell auf die korrekte UTC-Zeit ein.

Unser Server ist jetzt etwa 20 Minuten entfernt.

Es sieht so aus, als ob unser Server die Uhrzeit seit einigen Tagen nicht korrekt aktualisiert hat. 

22. November 19:29:23 Hostname ntpd [1818]: Zurücksetzen der Zeit auf -998.577519 s 22. November 19:32:34 hostname ntpd [1818]: synchronisiert mit LOCAL (0), Schicht 10 22. November 19:33:39 hostname ntpd [1818]: Synchronisiert mit 41.134.20.28, Schicht 1 22. November 19:52:30 Hostname ntpd [1818]: Zurücksetzen der Zeit auf -998.992426 s 22. November 19:55:47 hostname ntpd [1818]: synchronisiert mit LOCAL (0), Schicht 10 22. November 19:56:53 Hostname ntpd [1818]: Synchronisiert mit 41.134.20.28, Schicht 1 22. November 20:13:04 Hostname ntpd [1818]: Zurücksetzen der Zeit auf -999.374412 s 22. November 20:16:40 hostname ntpd [1818]: synchronisiert mit LOCAL (0), Schicht 10 22. November 20:17:44 Hostname ntpd [1818]: Synchronisiert mit 41.134.20.28, Schicht 1 22. November 20:32:02 Hostname ntpd [1818]: Zurücksetzen der Zeit auf -999.716832 s 22. November 20:35:28 hostname ntpd [1818]: synchronisiert mit LOCAL (0), Schicht 10 22. November 20:36:16 Hostname ntpd [1818]: Synchronisiert mit 41.134.20.28, Schicht 1 22. November 20:56:39 Hostname ntpd [1818]: Zeitkorrektur von -1000 Sekunden überschreitet die Vernunftsgrenze (1000); Stellen Sie die Uhr manuell auf die korrekte UTC-Zeit ein.
4
Laufen Sie diesen Linux auf Bare Metal? Oder es ist eine Art Gast in einer Virtualisierungsumgebung. Ist letzteres der Fall, werden Datum und Uhrzeit des Gasts möglicherweise mit dem Host synchronisiert. Es muss eine Option vorhanden sein, um ein solches Verhalten zu verhindern. Andrey Voitenkov vor 11 Jahren 0
@AndreyVoitenkov ist eine VM. Ich werde einen Blick darauf werfen, was ich herausfinden kann. nelaaro vor 11 Jahren 0

2 Antworten auf die Frage

3
nelaaro

http://www.linuxforum.com/threads/2154-Linux-ntp-time-Offset-on-Xen-VM-incorrect

Nach langem Suchen habe ich festgestellt, dass die Uhren der VM standardmäßig mit der HOST-Uhr synchronisiert werden, die in der Steuerungsdomäne ausgeführt wird, und nicht unabhängig voneinander geändert werden können. Dies war für mich überraschend, da NTP noch konfiguriert war und die Uhren synchronisieren konnte.

Fügen Sie der Datei /etc/sysctl.conf die folgende Zeile hinzu 

# Allow the VM to update it's own clock, and do not use the DOM host clock. xen.independent_wallclock=1

Starten Sie dann den Netzwerkdienst neu

/etc/init.d/network restart #for redhat, centos, fedora /etc/init.d/networking restart #debian, ubuntu

Jetzt können Sie das Datum mit einstellen date -s ...

Hier ist ein Link zu den offiziellen Xen-Dokumenten.
Hier ist ein Link zu den NTP-Dokumenten

Treffen Sie dieses Problem auf einem alten CentOS 5, das auf Rackspace ausgeführt wird. Sehr hilfreich Vielen Dank. rmarscher vor 9 Jahren 0
1
Paul Bichis

Für Mageia-Benutzer und seine Eltern (RedHat, Mandrake, Mandriva) installieren wir ntp und ntp-client mit dem urpmiBefehl:

# urpmi ntp ntp-client

Dann starten wir den Dienst und ermöglichen, dass er beim Neustart automatisch gestartet wird.

# systemctl start chronyd.service # systemctl enable chronyd.service

Jetzt überprüfen wir, ob für timedatectl die NTP-basierte Netzwerkzeitsynchronisation aktiviert ist:

# timedatectl status Local time: Wed 2016-12-07 13:39:04 EET Universal time: Wed 2016-12-07 11:39:04 UTC RTC time: Wed 2016-12-07 11:38:56 Timezone: Europe/Bucharest (EET, +0200) NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: no Last DST change: DST ended at Sun 2016-10-30 03:59:59 EEST Sun 2016-10-30 03:00:00 EET Next DST change: DST begins (the clock jumps one hour forward) at Sun 2017-03-26 02:59:59 EET Sun 2017-03-26 04:00:00 EEST # date Wed Dec 7 13:39:11 EET 2016 # timedatectl set-timezone Europe/Bucharest # date Wed Dec 7 13:39:48 EET 2016 #

Ohne Aktivierung der NTP-Synchronisierung ändert sich die Zeitzone / Zeit nicht.

Jetzt aktivieren wir die NTP-basierte Netzwerkzeitsynchronisation und stellen die neue Zeitzone ein:

# timedatectl set-ntp 1 # timedatectl set-timezone Europe/Bucharest # date Wed Dec 7 10:43:33 EET 2016 # timedatectl status Local time: Wed 2016-12-07 10:43:59 EET Universal time: Wed 2016-12-07 08:43:59 UTC RTC time: Wed 2016-12-07 08:43:59 Timezone: Europe/Bucharest (EET, +0200) NTP enabled: yes  NTP synchronized: yes RTC in local TZ: no DST active: no Last DST change: DST ended at Sun 2016-10-30 03:59:59 EEST Sun 2016-10-30 03:00:00 EET Next DST change: DST begins (the clock jumps one hour forward) at Sun 2017-03-26 02:59:59 EET Sun 2017-03-26 04:00:00 EEST
Willkommen bei Super User. Sie können Ihre eigenen Beiträge frei bearbeiten, dies muss jedoch zu Ihrem Schutz unter dem ursprünglichen Benutzerkonto erfolgen. Es sieht so aus, als hätten Sie ein zweites Konto erstellt, das sich auch auf Ihre Fähigkeit auswirkt, Ihre Antwort zu kommentieren. Unter [Meine Konten zusammenführen] (http://superuser.com/help/merging-accounts) können Sie Ihre Konten zusammenführen, um das Problem zu lösen. Die zwei Konten sind: http://superuser.com/users/672303/paul-bichis und http://superuser.com/users/672304/paul-bichis fixer1234 vor 7 Jahren 1

Verwandte Probleme