jpg153 wrote: ↑5. Nov 2019, 19:31N'Abend,
und wieder nicht umgestellt.
Einmal kaputt, immer kaputt.
Auch einen guten Abend!
Mir fällt direkt keine Ursache für das Problem ein. Wenn sonst niemand eine Idee hat, kann man zwischen einer fehlerhaften Benutzereinstellung und einer fehlerhaften Systemeinstellung unterscheiden und so getrennt systematisch danach suchen. Voraussetzung hierfür ist, dass noch keine Veränderungen stattfanden, d.h., das System immer noch Sommerzeit verwendet. Meine bisherigen Gedanken hierzu (das wird jetzt etwas länger):
1. Zuerst alle Dateiinhalte und Dateisystemdaten vergleichen.
Meine Zeitumstellung funktioniert automatisch und richtig. Deshalb zeige ich folgend einige Inhalte und Begleitdaten (Eigentümer, Zugriffsrechte, Datumsangaben) zum Vergleichen aus meiner Installation, welches ein aktuell gehaltenes Salix64 Xfce 14.2 ist. Die Zeitzone ist auf Berlin und die Sprache ist auf Deutsch eingestellt. In der Orage-Konfiguration ist das "Timezone=posix/Europe/Berlin", Der Text ""posix/Europe/Berlin" ist eventuell nur in der Orage-Umgebung zu finden.
jpg153 wrote: ↑5. Nov 2019, 19:31Bis auf den letzten Teil deiner Antwort (etc/localtime und kernel) habe ich alles überprüft - ist alles ok und korrekt.
Na 'mal sehen!
Der Inhalt der Binärdatei /etc/localtime lässt sich mittel Kommando
zdump darstellen. In meiner Installation sind für das Jahr 2019 folgende Einträge enthalten:
Code: Select all
$ zdump -v /etc/localtime | grep 2019
/etc/localtime Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 01:59:59 2019 CET isdst=0 gmtoff=3600
/etc/localtime Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 03:00:00 2019 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 02:59:59 2019 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 02:00:00 2019 CET isdst=0 gmtoff=3600
Die Ausgabe von:
beginnt dabei mit:
Code: Select all
/etc/localtime -9223372036854775808 = NULL
/etc/localtime -9223372036854689408 = NULL
und endet mit:
Code: Select all
/etc/localtime 9223372036854689407 = NULL
/etc/localtime 9223372036854775807 = NULL
kann aber nicht sagen, ob das von Bedeutung ist.
Meine Datei ist dabei wie folgt beschrieben:
Code: Select all
$ stat /etc/localtime
Datei: '/etc/localtime'
Größe: 2326 Blöcke: 8 EA Block: 4096 reguläre Datei
Gerät: 801h/2049d Inode: 918012 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2019-11-05 22:47:03.406000803 +0100
Modifiziert: 2019-02-07 18:23:16.826552638 +0100
Geändert : 2019-02-07 18:23:16.826552638 +0100
Geburt : -
$
$
$ file -k /etc/localtime
/etc/localtime: timezone data, version 2, 9 gmt time flags, 9 std time flags, no leap seconds, 145 transition times, 9 abbreviation chars\012- data
$
Der Inhalt lässt sich auch nach Texten durchsuchen.
Code: Select all
$ strings /etc/localtime
TZif2
LMT
CEST
CEMT
TZif2
LMT
CEST
CEMT
CET-1CEST,M3.5.0,M10.5.0/3
$
Neben /etc/localtime gibt es hier noch /etc/localtime-copied-from :
Code: Select all
$ stat /etc/localtime-copied-from
Datei: '/etc/localtime-copied-from' -> '/usr/share/zoneinfo/Europe/Berlin'
Größe: 33 Blöcke: 0 EA Block: 4096 symbolische Verknüpfung
Gerät: 801h/2049d Inode: 919299 Verknüpfungen: 1
Zugriff: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2019-11-06 17:00:22.209830342 +0100
Modifiziert: 2017-09-02 07:11:08.862278843 +0200
Geändert : 2017-12-23 00:31:13.738338893 +0100
Geburt : -
$
Dann sind da noch die Informationsdateien zu den Zeitzonen /usr/share/zoneinfo/* . In meiner Installation zeigt der Aufruf von:
Code: Select all
$ zdump -v /usr/share/zoneinfo/Europe/Berlin | grep 2019
folgende Ausgabe:
Code: Select all
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 01:59:59 2019 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 03:00:00 2019 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 02:59:59 2019 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 02:00:00 2019 CET isdst=0 gmtoff=3600
$
Bei mir stimmen diese Inhalte mit denen aus /etc/localtime überein.
jpg153 wrote: ↑5. Nov 2019, 19:31Am kernel werde ich jetzt nicht schrauben.
Dieser wurde ja auch erst erneuert. Aber
Code: Select all
slapt-get --search '^kernel-*' | grep '\[inst=Ja]'
sollte mindestens
Code: Select all
kernel-firmware-20190821_c0fb3d9-noarch-1 [inst=Ja]: kernel-firmware (Firmware for the kernel)
kernel-headers-4.4.190-x86-1 [inst=Ja]: kernel-headers (Linux kernel include files)
kernel-huge-4.4.190-x86_64-1 [inst=Ja]: kernel-huge (a fully-loaded SMP Linux kernel)
kernel-modules-4.4.190-x86_64-1 [inst=Ja]: kernel-modules (Linux kernel modules)
liefern, sofern zum Zeitpunkt des Lesens Kernelversion 4.4.190 noch aktuell ist.
jpg153 wrote: ↑5. Nov 2019, 19:31Was mich wundert, in allen Einstellungen wird die Zeitzone Europa/Berlin angezeigt. Und trotzdem gehts nicht...
Sollte es doch an Orage liegen:
Mein Orage hat Version 4.12.1.
Vor einigen Monaten hatte ich einmal an Orage einige Veränderungen ausprobiert. Dabei ist mir aufgefallen, dass ~/.config/orage/oragerc vorher die Einstellung "Timezone=posix/Europe/Berlin" enthielt, nachher aber der Teil "posix/" fehlte. Da ich vorsichtig bin, hatte ich diesen Text nach einem Neustart in Runlevel 1 manuell nachgetragen, obwohl ich gelesen hatte, dass dieser Vorsatz nicht mehr zeitgemäß sein soll.
Code: Select all
grep Timezone ~/.config/orage/oragerc
gibt Gewissheit. Auf meinem System ist es nach wie vor:
Beachten sollte man noch, dass es "Europe" lautet, nicht "Europa" daraus machen. Ist es verändert, würde ich "posix/" wieder einfügen, denn was vielleicht für aktuelle Linux-Distributionen gilt, muss für Salix jetzt noch nicht richtig sein. Zwar hat Orage diese Änderung vorgenommen, man kann aber nicht sagen, ob sich das mit dem restlichen System verträgt.
Für mein Orage läuft nur folgender Prozess, solange noch kein Orage-Fenster geöffnet wurde:
Code: Select all
$ ps ax | grep -i orage
1220 ? S 0:05 /usr/lib64/xfce4/panel/wrapper-1.0 /usr/lib64/xfce4/panel/plugins/liborageclock.so 5 12582957 xfce4-orageclock-plugin Orage-Uhr Wieviel Uhr und welches Datum ist jetzt?
$
Diese Ausgabe ist eine einzige Zeile.
Dateien aus obriger Ausgabe:
Code: Select all
$ stat /usr/lib64/xfce4/panel/wrapper-1.0
Datei: '/usr/lib64/xfce4/panel/wrapper-1.0'
Größe: 27472 Blöcke: 56 EA Block: 4096 reguläre Datei
Gerät: 801h/2049d Inode: 663963 Verknüpfungen: 1
Zugriff: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2019-11-06 05:30:14.667657477 +0100
Modifiziert: 2016-06-04 00:45:58.000000000 +0200
Geändert : 2017-12-23 00:35:33.543329945 +0100
Geburt : -
$
$ stat /usr/lib64/xfce4/panel/plugins/liborageclock.so
Datei: '/usr/lib64/xfce4/panel/plugins/liborageclock.so'
Größe: 70080 Blöcke: 144 EA Block: 4096 reguläre Datei
Gerät: 801h/2049d Inode: 664007 Verknüpfungen: 1
Zugriff: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2019-11-06 05:30:15.064729461 +0100
Modifiziert: 2016-02-25 19:57:51.000000000 +0100
Geändert : 2017-12-23 00:35:33.709329940 +0100
Geburt : -
$
2. Ziel ist es, festzustellen, ob in einem niedrigen Runlevel noch alles richtig ist und evtl. erst in höherem Runlevel etwas schief geht. Wenn beim Starten das System in Runlevel 1 (1) gebracht wurde, kann man sich zuerst als gewöhnlicher Benutzer und danach auch als Root-Benutzer anmelden. In beiden Fällen: Zeigen die Ausgaben von "date" die tatsächliche Uhrzeit an und entsprechen sie sich?
3. Falls so, in Runlevel 3 wechseln, am besten über einen Neustart. Dann wieder die Ausgaben für den gewöhnlichen Benutzer und danach auch für Root-Benutzer ansehen.
4. Ändert sich gegebenenfalls etwas daran in Runlevel 4 in einem tty-Terminal (Alt-Strg-F2)? In einem pts-Terminal?
5. Es sollte überprüft werden, ob es am Benutzer- oder am System liegt. Es könnten ja die Benutzereinstellungen ungünstig verändert sein. Wenn ein weiterer Benutzer existiert, dann beim Booten als dieser anmelden und sehen, wie die Zeitangaben nun aussehen. Dies für obrige Runlevel und auch mit Orage im Runlevel 4. Wenn man einen weiteren Benutzer hat, der noch nicht benutzt wurde oder der vor jetziger Fehlfunktion noch richtiges Datum und Uhrzeit hatte, sollte man überprüfen, ob dieser nun auch die falsche Uhrzeit hat. Ist kein weiterer geeigneter Benutzer angelegt, dann einen anlegen und Passwort vereinbaren, z.B. mit:
Code: Select all
sudo useradd -m otto
sudo passwd otto
Dann über alle genannten Runlevel booten und mit dem neu angelegtem Benutzer anmelden und die Uhrzeit mit der realen Uhrzeit vergleichen. Durch den Schalter '-m' werden alle Dateien aus dem Gerüstverzeichnis, das die Dateien und Verzeichnisse enthält, die in das Home-Verzeichnis des Benutzers gehören, kopiert. Der neue Benutzer hat also unverfälschte Konfigurationsdateien. Ist die Uhrzeit dieses neuen Benutzers bereits in Runlevel 1 falsch, dann würde ich von einem Fehler im System ausgehen. Der Kernel kann dann evtl. eine der Dateien nicht erreichen. Wenn bis dahin alles gut ist, dann soll dieser Benutzer Orage für sich Orage einrichten. Dann Funktion überprüfen. Man kann für alle Test das "Internet abklemmen", denn der Vorgang der Zeitumstellung muss selbstverständlich auch ohne ntp-Server funktionieren.
6. Damit es am kommenden Wochenende nicht langweilig wird, noch einen scharfen Gedanken. Die Hardwareclock kann im BIOS auf "localtime" oder UTC eingestellt sein. Dies geschieht einfach über die entsprechende Zeitangabe im zuständigen Eingabefeld. Der Kernel erfährt welche dieser Zeiten es ist über den Inhalt von /etc/hardwareclock. Hat man nur
ein System auf dem Rechner, dann ist es egal, welche Einstellung gewählt wird. Wichtig ist dann nur, dass der Inhalt von /etc/hardwareclock zur Angabe im BIOS passt. Hat man aber mehrere bootbare Systeme auf dem Rechner, dann ist es sehr empfehlenswert, UTC in jedem BS auf dem Rechner einzustellen und die dazu passende UTC-Zeit im BIOS zu verwenden. Das gilt meiner Ansicht nach auch, wenn Virtualisierungen auf einem BS verwendet werden (wieviele sind es noch?). Ich sehe das auch für Chroot-Umgebungen so (wie viele sind das noch?). Mit richtigen Einstellungen kann man sich viel Ärger sparen. Auf meinem Salix-Rechner verwende ich keine Virtualisierungen oder komplexe Chroot-Anwendungen. /etc/hardwareclock enthält bei mir "localtime". Der Kernel verändert bei jedem Zeitwechsel die BIOS-Uhr. Ich habe kein Problem damit. Wie sieht das wohl auf einem Rechner aus, auf dem noch weitere diverse Linux-Systeme, Virtualisierungen (Linux, IBM OS/2 oder ähnlich, fliegende Windaugen) und komplexe Chroot-Anwendungen um die BIOS-Uhr konkurieren? Da ändert der eine Kernel die Uhrzeit und der nächste unter Umständen auch, usw., usf. Jedenfalls kann hier auch der Fehler verborgen sein.
Bei Interesse kann ich auch meine Dateien zum Vergleichen veröffentlichen.
----
1) Runlevel 1 ist bei Verwendung von Lilo als Betriebssystemlader erreichbar über die Eingabe von: Salix 1<cr>
auf der Kernel-Kommandozeile. Bei Bedarf werden nach der Eins noch weitere Parameter angefügt.