orage stellt nicht auf Sommerzeit um

German Forum
Post Reply
User avatar
jpg153
Donor
Posts: 409
Joined: 23. Oct 2009, 15:43
Location: Marl/NRW/BRD/EU

orage stellt nicht auf Sommerzeit um

Post by jpg153 » 1. Apr 2019, 22:19

Hallo,

Orage zeigt die Sommerzeit nicht an, obwohl die richtige Zeitzone angezeigt wird.
Egal wie häufig ich die Zeitzone neu einstelle, es bleibt bei Winterzeit (UTC+1).

Hat wer eine Idee wieso und was ich wo ändern muss?
14.2 64bit Xfce

Danke.
Regards Gruß
jpg

galmei
Posts: 64
Joined: 1. Jun 2018, 21:54

Re: orage stellt nicht auf Sommerzeit um

Post by galmei » 2. Apr 2019, 20:01

jpg153 wrote:
1. Apr 2019, 22:19
Hat wer eine Idee wieso und was ich wo ändern muss?
Guten Abend,

das Ganze läuft automatisch ab. Eigentlich muss nichts geändert werden, es sei denn, zuvor wurde etwas "kaputt gemacht".
jpg153 wrote:
1. Apr 2019, 22:19
Orage zeigt die Sommerzeit nicht an, obwohl die richtige Zeitzone angezeigt wird.
Egal wie häufig ich die Zeitzone neu einstelle, es bleibt bei Winterzeit (UTC+1).
Wurden die Dateien rc.S, rc.0 oder rc.6 in /etc/rc.d manipuliert?

Besteht das Fehlverhalten auch nach einem Kaltstart weiterhin?

Zeigt das Kommando date die richtige Zeit an? Ist die Zeit richtig, dann kann die Ursache bei Orage oder GTK liegen. Ansonsten muss man an tieferliegenden Einrichtungen suchen.

User avatar
jpg153
Donor
Posts: 409
Joined: 23. Oct 2009, 15:43
Location: Marl/NRW/BRD/EU

Re: orage stellt nicht auf Sommerzeit um

Post by jpg153 » 9. Apr 2019, 21:15

N'Abend,

Danke für die Rückmeldung.

Am Ende war es die "Systemuhrzeit" - die richtig eingestellt, passt es nun.
Regards Gruß
jpg

galmei
Posts: 64
Joined: 1. Jun 2018, 21:54

Re: orage stellt nicht auf Sommerzeit um

Post by galmei » 12. Apr 2019, 05:20

jpg153 wrote:
9. Apr 2019, 21:15
Am Ende war es die "Systemuhrzeit" - die richtig eingestellt, passt es nun.
Die richtig Einstellung der Systemuhrzeit führt zur Anzeige der richtigen Daten zu Datum, Uhrzeit und Zeitzone, das ist richtig. Die Anfrage lautete aber orage stellt nicht auf Sommerzeit um und Hat wer eine Idee wieso und was ich wo ändern muss. Die jeweiligen Umstellungen zwischen Normalzeit und Sommerzeit erfolgen gewöhnlich automatisch. Dazu wird eine lokale Zeitzonendatenbank herangezogen. Eine manuelle Umstellung stellt die verlorengegangene automatische Umstellung nicht wieder her.

Vielleicht ist das nicht mehr so wichtig. Mit etwas Glück stellen die politischen Spinner im Oktober letztmals um. Trotzdem einige Worte zu Untersuchungs- und Fehlermöglichkeite.

Für Orage:
Wenn die Uhr in der Leiste ein Orage-Objekt ist, dann:
Orage-Kontextmenü > Eigenschaften
sonst:
Xfce-Menü (Salix) > Einstellunen > Einstellunen für Orage
Dort können grundlegende Funktionen eingestellt werden. Es würde mich aber wundern, wenn Orage die Systemuhrzeit verändern könnte.

Um die Orage-Einstellung überprüfen zu können, sieht man sich die Timezone-Zeile aus der Datei ~/.config/orage/oragerc an. Für Deutschland muss diese Zeile Timezone=posix/Europe/Berlin oder Timezone=Europe/Berlin lauten.

Für GTK:
Xfce-Menü (Salix) > System > Systemuhrzeit
Dahinter verbirgt sich gtkclocksetup.

Für das Betriebssystem:
Es sollte ein Zeitdienst laufen. In
Xfce-Menü (Salix) > System > Systemdienste sollte ein ntpd angehakt sein und mit

Code: Select all

ps ax | grep ntpd
sollte er dann auch in der Prozesstabelle sichtbar sein. Mit:

Code: Select all

sudo clocksetup
können Einstellungen an der Systemuhr erfolgen.

Wurde bei einer der Einstellmöglichkeiten das Gebiet Etc/ eingestellt, dann erfolgt eventuell keine Umstellung.

Damit alles laufen kann, müssen, hier speziell für die deutsche Zeitzone, folgende Dateien mit den angegebenen Verhältnissen existieren:

Code: Select all

-rw-r--r-- 1 root root /etc/localtime

lrwxrwxrwx 1 root root /etc/localtime-copied-from -> /usr/share/zoneinfo/Europe/Berlin
-rw-r--r-- 2 root root /usr/share/zoneinfo/Europe/Berlin

lrwxrwxrwx 1 root root /usr/share/zoneinfo/localtime -> /etc/localtime
-rw-r--r-- 1 root root /etc/localtime
Eine Fehlermöglichkeit für falsche Zeitzone, Datum und Uhrzeit entsteht noch durch uneinheitliche Installation des Kernels und seiner Umgebung. Der Kernel erstellt sich seine eigene interne Meinung zu den oben aufgezählten Zeitdaten. Wenn Kernel-Komponenten falsch gemischt wurden, wird es in vielerlei Hinsicht problematisch. Beispielsweise ist bei Salix-aktuellem Kernel zu diesem Zeitpunkt mindestens folgendes zusammengehörig:
kernel-huge-4.4.172-x86_64-1
kernel-modules-4.4.172-x86_64-1
kernel-headers-4.4.172-x86-1
kernel-firmware-20190118_a8b75ca-noarch-1

User avatar
jpg153
Donor
Posts: 409
Joined: 23. Oct 2009, 15:43
Location: Marl/NRW/BRD/EU

Re: orage stellt nicht auf Sommerzeit um

Post by jpg153 » 12. Apr 2019, 12:19

Ja,

ich gebe Dir recht, nur die Uhrzeit einstellen löst nicht das eigentliche Problem.
Allerdings kann ich nicht mehr genau nachvollziehen was jetzt verstellt war.

Die Zeitzonen waren richtig eingestellt (Orage und Systemuhr), ntpd läuft...

Die anderen Einstellungen sind soweit ich das überblicke auch ok.

Es hatte ja bei der letzten Zeitumstellung noch funktioniert.

Danke für die Mühe. Bei der nächsten Umstellung werde ich drauf achten was evtl. nicht funktioniert.
Regards Gruß
jpg

User avatar
jpg153
Donor
Posts: 409
Joined: 23. Oct 2009, 15:43
Location: Marl/NRW/BRD/EU

Re: orage stellt nicht auf Sommerzeit um

Post by jpg153 » 5. Nov 2019, 19:31

N'Abend,


und wieder nicht umgestellt.

Bis auf den letzten Teil deiner Antwort (etc/localtime und kernel) habe ich alles überprüft - ist alles ok und korrekt.

Am kernel werde ich jetzt nicht schrauben.

Was mich wundert, in allen Einstellungen wird die Zeitzone Europa/Berlin angezeigt. Und trotzdem gehts nicht...

Danke.
Regards Gruß
jpg

galmei
Posts: 64
Joined: 1. Jun 2018, 21:54

Re: orage stellt nicht auf Sommerzeit um

Post by galmei » 7. Nov 2019, 03:54

jpg153 wrote:
5. Nov 2019, 19:31
N'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:31
Bis 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:

Code: Select all

$ zdump -v /etc/localtime
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:31
Am 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:31
Was 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:

Code: Select all

Timezone=posix/Europe/Berlin
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.

Post Reply