Probleme mit der Systemzeit im Zusammenhang mit LINBO und dem lmn-bionic-cloop

Clientpflege linbo
20

Hallo,

schon bei meinem virtuellen Ubuntuclient habe ich die Beobachtung gemacht, dass er ab und an im bootsplash hängen bleibt. Heute habe ich nun das Image an einem realen Rechner ausprobiert und feststellen müssen, dass der Fehler hier permanent auftritt. Ich vermute, dass er mit dem oben zitierten Workaround zusammen hängt: Lösche ich den entsprechenden Eintrag in der rc.local, dann funktioniert es, allerdings hat der Client dann eine um 2 Stunden falsche Zeit, zumindest über einen unbestimmten Zeitraum hinweg.
Also muss eine andere Lösung her. Ich habe mir folgenden thread angeschaut:

https://ask.linuxmuster.net/t/ntp-service-status-inactive-dead/

bin aber nicht schlau geworden, was ich nun letztendlich tun soll.

Viele Grüße

Wilfried

21

Hallo Wilfried!

Der Vollständigkeitshalber: Welcher NTP-Client ist auf dem System installiert?

Beste Grüße

Thorsten

22

Nachtrag bzw. Frage:

Dual-Boot oder nur Linux-Client?
Kennst Du schon: https://wiki.archlinux.org/index.php/System_time

23

Hallo Thorsten,

es geht nur um den Linux-Client, und was den NTP-Client angeht, scheint von allem etwas dabei zu sein. Allerdings kann ich das Problem insgesamt etwas relativieren, weil die Zeit - mal früher, mal später - korrigiert wird.
Ich habe mal die Situation vor der Korrektur überprüft und habe folgende Ausgaben bekommen:

root@r241-virtual2:/home/linuxadmin# service ntp status
● ntp.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)


root@r241-virtual2:/home/linuxadmin# systemctl status chrony
● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: e
   Active: active (running) since Fri 2020-06-05 13:05:03 CEST; 2min 9s ago
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
  Process: 1162 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=
  Process: 1135 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OP
 Main PID: 1160 (chronyd)
    Tasks: 1 (limit: 4681)
   CGroup: /system.slice/chrony.service
           └─1160 /usr/sbin/chronyd

Jun 05 13:05:03 r241-virtual2 systemd[1]: Starting chrony, an NTP client/server.

root@r241-virtual2:/home/linuxadmin#  timedatectl status
                      Local time: Fr 2020-06-05 13:13:19 CEST
                  Universal time: Fr 2020-06-05 11:13:19 UTC
                        RTC time: Fr 2020-06-05 11:13:19
                       Time zone: Europe/Berlin (CEST, +0200)
       System clock synchronized: no
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

Irgendwann korrigiert chrony die Zeit:

Jun  5 11:35:14 r241-virtual2 systemd[1]: Starting Time & Date Service...
Jun  5 11:35:14 r241-virtual2 dbus-daemon[975]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jun  5 11:35:14 r241-virtual2 systemd[1]: Started Time & Date Service.
Jun  5 09:36:32 r241-virtual2 chronyd[1117]: Selected source 10.16.1.1
Jun  5 09:36:32 r241-virtual2 chronyd[1117]: System clock wrong by -7199.677617 seconds, adjustment started
Jun  5 09:36:32 r241-virtual2 chronyd[1117]: System clock was stepped by -7199.677617 seconds

oder

Jun  5 12:02:35 r241-virtual2 Scratch2.desktop[2774]: adobe-air: Done
Jun  5 10:03:30 r241-virtual2 chronyd[1113]: Selected source 10.16.1.1
Jun  5 10:03:30 r241-virtual2 chronyd[1113]: System clock wrong by -7200.914989 seconds, adjustment started
Jun  5 10:03:30 r241-virtual2 chronyd[1113]: System clock was stepped by -7200.914989 seconds

und dann sehen die Ausgaben so aus:

root@r241-virtual2:/home/linuxadmin# service ntp status
● ntp.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

root@r241-virtual2:/home/linuxadmin# systemctl status chrony
● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-06-05 12:00:17 CEST; 1h 39min left
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
  Process: 1115 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 1088 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCESS)
 Main PID: 1113 (chronyd)
    Tasks: 1 (limit: 4681)
   CGroup: /system.slice/chrony.service
           └─1113 /usr/sbin/chronyd

Jun 05 12:00:16 r241-virtual2 systemd[1]: Starting chrony, an NTP client/server...
Jun 05 12:00:17 r241-virtual2 chronyd[1113]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYN
Jun 05 12:00:17 r241-virtual2 chronyd[1113]: Frequency 5.802 +/- 0.013 ppm read from /var/lib/chrony/chrony.drift
Jun 05 12:00:17 r241-virtual2 systemd[1]: Started chrony, an NTP client/server.
Jun 05 12:03:31 r241-virtual2 chronyd[1113]: Selected source 10.16.1.1
Jun 05 12:03:31 r241-virtual2 chronyd[1113]: System clock wrong by -7200.914989 seconds, adjustment started
Jun 05 10:03:30 r241-virtual2 chronyd[1113]: System clock was stepped by -7200.914989 seconds

root@r241-virtual2:/home/linuxadmin#  timedatectl status
                      Local time: Fr 2020-06-05 10:23:04 CEST
                  Universal time: Fr 2020-06-05 08:23:04 UTC
                        RTC time: Fr 2020-06-05 08:23:05
                       Time zone: Europe/Berlin (CEST, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

Da bei uns die meisten Rechner automatisch hochgefahren werden, wird das Problem nicht groß auffallen. Aber bei der Arbeit am Default-cloop kann es schon ärgerlich sein, wenn aufgrund des Zeitunterschiedes zu Beginn z. B. der Domänenbeitritt Schwierigkeiten macht.

Viele Grüße

Wilfried

24

Hallo,

das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.

Viele Grüße

Wilfried

25

Hallo Wilfried,

das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von
chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.

ich denke das Problem tritt bei mir nicht auf, weil ich dafür gesorgt
habe, dass linbo die Systemzeit (BIOS Uhr) korrekt setzt.
Leider macht linbo das nicht immer,weil der Dienst (Zeitserver) auf dem
Server immer mal „wakelt“.

Schau mal in diese Tread:

LG

Holger

26

Hallo Wilfried,

poste mal deine /etc/chrony/chrony.conf

LG

Thorsten

27

Hallo Thorsten,

bitte:

# /etc/chrony/chrony.conf
#
# thomas@linuxmuster.net
# 20181017
#

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.com        iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

server server.linuxmuster.lan

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3

@Holger: In linbo startet die Zeit auch ganz kurz falsch, wird aber sofort korrigiert.

Viele Grüße

Wilfried

28

Hallo Wilfried,

das ist das selbe Problem, das ich oben beschrieben habe. Linbo schreibt die Localtime in die RTC; für Windows ist das genau richtig, aber für Linux falsch. Da Linux die Zeit nicht direkt beim Systemstart aktualisiert, sondern nach einer zufälligen Zeit, funktioniert das SSO nicht, also keine Shares und keine Anmeldung am Proxy.
Solange das mit der Zeit nicht funktioniert, bleiben die Computer bei uns erstmal ungenutzt. :confused:

Ich hatte einen pull-request mit einer Korrektur gemacht, glaube aber, dass aktuell noch geprüft werden soll, wie Win10 mit UTC läuft (funktioniert mit einem Reg-Patch). In unserem aktuellen 7er-System wird durch linbo noch die Localtime geschrieben.

Ich würde das zum Testen gerne auf UTC umstellen, weiß aber nicht, woher sich der Server die Linbo-Umgebung holt - ich vermute, dass die vorkompiliert ist; ich konnte die Datei auf dem Server nicht finden.

Vielleicht wäre es sinnvoll, wenn Linbo die Systemzeit nicht direkt beim System-Init in die RTC schreibt, sondern vor/beim Start eines Betriebssystems und die Zeit dann Systemabhängig setzt. Das könnte man auf dem Server über die Gruppen vorgeben.
Übergangsweise schlage ich vor, die Code-Zeile, die die RTC schreibt auszukommentieren und den Nutzer darauf hinzuweisen, dass sich das gestartete OS um die korrekte Zeit kümmern muss. Man muss dann nur bei Inbetriebnahme eines Computers auf die korrekte Zeit achten, aber danach hätte man sowohl für Win10, als auch für Linux immer die korrekte Zeit.

Viele Grüße
Fabian

29

Hallo Fabian,

das wundert mich: ich meine linbo schreibt UTC (wie es alle machen …
außer Windows) un ddie Einigung war, dass man windows per regeintrag auf
UTC umbiegt.
Genau so habe ich es bei mir in der SChule: linux macht das richtig,
windows hat einen Regeintrag bekommen und tut jetzt auch. linbo schreibt
utc: alles fein bei mir jetzt.

Schau mal hier:

LG

Holger

30

Moin!

Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client ruft hwclock --systohc auf), bleiben soll? Ich habe halt die Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei denen die Zeit nicht stimmt.
Das sollte jetzt mal endgültig festgelegt werden.

Ich habe es oben schon geschrieben, der Linbo-Client nutzt dieselbe timezone wie der Server. Ändert man die TZ auf dem Server und ruft anschließend update-linbofs auf, hat man auf dem Client auch die TZ geändert.

VG, Thomas

31

Hallo Thomas,

Einigung war, dass man windows per regeintrag auf
UTC umbiegt.

Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client
ruft hwclock --systohc auf), bleiben soll? Ich habe halt die
Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei

ich meine (meine private Meinung: ich bin kein Entwickler), dass die
Sache so läuft:
Server steht auf UTC
Linbo setzt die BIOS Zeit beim starten auf dem Client auf UTC
Windows wird per regpatch auf UTC umgemünzt.

Dann sollte das doch für alle stimmen, oder?

Oder hab ich da was nicht verstanden?

LG

Holger

32

Nochmal: Linbo setzt die BIOS Zeit auf genau das, was auf dem Server eingestellt ist.

VG, Thomas

33

Hallo Thomas!

Auch auf die Gefahr hin das ich nerve, ich sage vorab schon einmal Entschuldigung dafür! :slight_smile:

Ich finde die Idee von

sehr charmant. Damit ließe sich das für alle Zeit einfach lösen, wie ich finde. Kein Reg-Patch, oder sonst was, hier wird jeder bedient wie er es mag. (gemeint ist natürlich das BS; steht so auch in PullRequest )

nur meine 1/2 Cent

lieben Gruß und bleib gesund

Thorsten

34

Hallo zusammen,

Ich habe das nicht verstanden:

was heißt denn das genau?

root@server(Humboldt):~# timedatectl status
                      Local time: Mi 2020-06-10 22:05:33 CEST
                  Universal time: Mi 2020-06-10 20:05:33 UTC
                        RTC time: Mi 2020-06-10 20:05:32
                       Time zone: Europe/Berlin (CEST, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: no
                 RTC in local TZ: no

Das sagt mir doch: meine Hardware läuft in UTC, nicht in lokaler Zeit.

Also, wenn ich das wörtlich nehme, dann setzt LINBO auf meinem Client erstmal die BIOS-Zeit (RTC) auch auf UTC.

Für die LinuxClients wäre das jetzt bei mir Stand der Dinge perfekt: dem muss man nur beibringen, dass die RTC auf UTC steht, wie üblich und dass die Zeitzone 2h daneben liegt. Übrigens würde ich chrony und ntp auf den clients verbannen und überall die systemd - timesyncd Variante verwenden. Nur der Einheit und des supports hier wegen.

Für die WIndowsCLients gäbe es zwei Möglichkeiten:

oder (so steht es doch alternativ im github issue):

  • wenn windows gestartet wird, dann patch LINBO die BIOS-Zeit (RTC) eben auf die localtime.

Vermutlich habe ich jetzt auch nur umformuliert, was @fkretzschmar und @MachtDochNix auch vorgeschlagen haben.

Für diese Alternative wäre ich auch.

35

Hi!

Ok, ist in linuxmuster-linbo7 2.3.63 ungesetzt.

VG, Thomas

36

Hallo Thomas,

nach dem Linbo-Update stimmt bei meinem virtuellen Client die Zeit von Beginn an. Danke für deine Arbeit.

Viele Grüße

Wilfried

37

Hi,
ich hab das in einen anderen Thread mit reingepackt … seit dem Einspielen von dem neuen Linbo komme ich auch mit Linux nicht mehr durch SSO ins Netz.
Der Befehl timedatectl status zeigt bei mir auf dem Server 3x die gleiche Zeit an, und die ist um 2 Stunden hinten.
Muss ich da die localtime um 2 vorstellen (siehen Bild Holger)? Wenn ja, wie, wo …

VG
Wolfgang

38

Hallo Wolfgang,

funktioniert jetzt alles bei mir - kein Trost für dich …

Hast du SSO in der OPENsense getestet?
Ich habe auf dem Linuxclient die Proxy-Einstellungen systemweit unter ‚Einstellungen > Netzwerk > Manuelle Proxy-Einstellungen‘ gemacht. Für realistische Tests muss dann auch der Client, sofern er zuvor eingetragen war, aus der ‚NoProyx-Gruppe‘ raus.

Viele Grüße

Wilfried

39

Hi,

nö - tröstet nicht :slight_smile:

Ich werde für Montag jetzt das „Notprogramm“ anlaufen lassen und alle Rechner erst mal in die noProxy Gruppe schieben. Da muss ich allerdings erst mal sehen, wo bzw. wann beim Linux-Client die Proxies gesetzt werden. Beim Windows-Client scheint es zu funktionieren - teste ich heute/morgen noch.

Ich bin sicher, dass es mit dem Zeitproblem zusammenhängt. Ich hab da einen Verdacht, muss das aber morgen noch checken …

VG
Wolfgang