In der Terminal-Ausgabe:
In der Skript-Ausgabe:write(1, "Mo 20. Sep 15:53:00 CEST 2021\n", 30) = 30
Wird die komplette Ausgabe trotzdem noch benötigt?write(1, "Thu Feb 14 11:12:09 CET 2019\n", 29) = 29
Gruss H.
In der Skript-Ausgabe:write(1, "Mo 20. Sep 15:53:00 CEST 2021\n", 30) = 30
Wird die komplette Ausgabe trotzdem noch benötigt?write(1, "Thu Feb 14 11:12:09 CET 2019\n", 29) = 29
Das zeigt im NAS-Terminal jetztTintom hat geschrieben:20.09.2021 15:47:47Weiter oben hat schon jemand geschrieben: Kannst du bitte einmal die Ausgabe von timedatectl (aus dem Terminal, nicht durch udev-Skript) posten?
Code: Alles auswählen
Local time: Mo 2021-09-20 17:17:06 CEST
Universal time: Mo 2021-09-20 15:17:06 UTC
RTC time: Mo 2021-09-20 15:17:06
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Der interessante teil ist wohl, was der unterschied von clock_gettime isthalo44 hat geschrieben:20.09.2021 17:16:22Wird die komplette Ausgabe trotzdem noch benötigt?
Gruss H.
Code: Alles auswählen
clock_gettime(CLOCK_REALTIME, {tv_sec=1550139129, tv_nsec=265725895}) = 0
Eine ganz banale Vermutung von mir: Du schreibst, du startest das System bei allen Änderungen neu. Kann es sein, dass das System die Uhrzeit beim Neustart vergisst (Batterie leer?)?
Dass die Batterie leer ist, kann ich ausschließen. Ich schalte mein NAS spätabends per Cronjob aus. Hierbei vermittle ich dem NAS, dass es am nächsten Tag um 17:05 Uhr neu starten soll:Tintom hat geschrieben:21.09.2021 12:15:38... Eine ganz banale Vermutung von mir: Du schreibst, du startest das System bei allen Änderungen neu. Kann es sein, dass das System die Uhrzeit beim Neustart vergisst (Batterie leer?)?
Nach dem Neustart beginnt das System zeitlich beim Urknall, hier also der 14.02. Diese Uhrzeit wird zunächst als Basis für die Systemzeit genommen. Während des Bootvorgangs wird dein udev-Skript abgearbeitet, wahrscheinlich jedoch bevor systemd-timesyncd sich die aktuelle Zeit aus dem Internet geholt hat. Sobald du dich eingeloggt hast, hat sich das System bereits eine Uhrzeit besorgt (siehe Ausgabe von timedatectl).
Was passiert, wenn du die Udev-Regel ausführst (d.h. den Stick einsteckst) nachdem du dich angemeldet hast und das System sich zeitlich synchronisiert hat (mit timedatectl vorher prüfen!)? Ändert das etwas?
Code: Alles auswählen
echo `date '+%s' -d 'tomorrow 17:05:00'` > /sys/class/rtc/rtc0/wakealarm
Code: Alles auswählen
Tue Sep 21 13:31:00 CEST 2021
Dieses falsche Datum zeigt sich im Terminal auch bei später gesteckten StickPrüfe ich die Datenpartitionen auf dem NAS auf mount- und prüf-Vorgänge, so zeigen alle Partitionen ebenfalls das Datum 14.02.2019, allerdings mit unterschiedlichen Uhrzeiten.
Code: Alles auswählen
root@NAS-01:~# tune2fs -l /dev/sda6 | egrep -i "Last"
Last mounted on: /Daten-2
Last mount time: Thu Feb 14 11:12:20 2019
Last write time: Thu Feb 14 11:12:20 2019
Last checked: Thu Feb 14 11:12:17 2019
Diese Werte werden nicht in Echtzeit aktualisiert. Hier mal mein System als Vergleich:Dieses falsche Datum zeigt sich im Terminal auch bei später gesteckten StickPrüfe ich die Datenpartitionen auf dem NAS auf mount- und prüf-Vorgänge, so zeigen alle Partitionen ebenfalls das Datum 14.02.2019, allerdings mit unterschiedlichen Uhrzeiten.Code: Alles auswählen
root@NAS-01:~# tune2fs -l /dev/sda6 | egrep -i "Last" Last mounted on: /Daten-2 Last mount time: Thu Feb 14 11:12:20 2019 Last write time: Thu Feb 14 11:12:20 2019 Last checked: Thu Feb 14 11:12:17 2019
Ich denke es liegt wirklich an einer falschen/fehlerhaften Initialisierung der Uhrzeit. Als Workaround bis die tatsächliche Ursache gefunden ist würde ich vorschlagen, du schaltest eine Serviceunit von systemd vor das eigentliche Bashskript. In die Serviceunit trägst du dann einDamit ist aber immer noch nicht geklärt, warum date nicht richtig arbeitet, wenn der Stick bereits gesteckt ist. Dies ist aber der Sinn der Sache, weil ich nicht unbedingt anwesend bin, wenn das NAS seine Aufgaben ausführen soll.
Diese Datei möchte ich nicht in voller Größe posten, kann aber einige Einträge anlisten, die mit der Problematik zu tun haben könnten. Zunächst hier fsck der Partition sda6. Das Checkdatum steht heute noch - wie gepostet - auf diesem Zeitpunkt.-- Logs begin at Thu 2019-02-14 11:12:02 CET, end at Sat 2020-02-29 19:30:59 CET. --
Noch merkwürdiger die letzte Zeile im Journal vom 14.02.2019:Feb 14 11:12:08 NAS-01 systemd-fsck[239]: Daten-2: Der Zeitpunkt des letzten Einhängens des Superblocks liegt in der Zukunft.
Feb 14 11:12:08 NAS-01 systemd-fsck[239]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr)
Danach folgt unmittelbarFeb 14 11:12:12 NAS-01 systemd-timesyncd[312]: System clock time unset or jumped backwards, restoring from recorded timestamp: Fri 2020-02-28 23:59:46 CET
In diesen Fehlern vermute ich die Ursache des Problems. Am 14.02.2019 ist etwas beschädigt worden, was beim Upgrade von Stretch zu Buster übernommen wurde und heute noch im System ist.Feb 28 23:59:47 NAS-01 kernel: audit: type=1400 audit(1582930786.476:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=319 comm="apparmor_parser"
Also habe ich im gefundenen Journal weiter gesucht und bin auch fündig geworden. Zunächst fand ich diese Einträgeuname hat geschrieben:22.09.2021 07:40:56Ich denke die richtige Stelle hast du immer noch nicht gefunden ...
Das kam mir irgendwie bekannt vor und in meinen Betriebssystem-Dokumentationen fand ich eine Notiz, die ich hier in Auszügen poste:Feb 29 00:00:01 NAS-01 exim[920]: 2020-02-29 00:00:01 1j75eZ-00012k-5b spool file write error while delivering: No space left on device
Feb 29 00:00:01 NAS-01 exim[920]: write failed on panic log: length=102 result=-1 errno=28 (No space left on device)
Feb 29 19:30:09 NAS-01 logrotate[918]: gzip: stdout: No space left on device
Feb 29 19:30:39 NAS-01 anacron[986]: 2020-02-29 19:30:39 failed to write to main log: length=79 result=-1 errno=28 (No space left on device)
Feb 29 19:30:39 NAS-01 exim[1299]: 2020-02-29 19:30:39 failed to write to main log: length=79 result=-1 errno=28 (No space left on device)
Feb 29 19:30:39 NAS-01 exim[1299]: write failed on panic log: length=104 result=-1 errno=28 (No space left on device)
Hier ist offensichtlich wegen Speichermangels einiges durcheinander geraten und hat auch den Neustart überlebt.Am 29.02.2020 stellte ich fest, dass am Vorabend die Sicherung der Datenpartitionen auf das NAS nicht durchgeführt wurde.
Ich konnte mich über ssh auf die Konsole des NAS einloggen, allerdings ließ sich das Journal nicht auswerten, es folgte die Meldung
"system.journal is truncated, ignoring file". Das Journal war defekt und ließ sich weder auslesen, reparieren noch kürzen.
Auf der Konsole zeigte df -h dass das Rootverzeichnis / zu 100% gefüllt war. Weiter fanden sich in /var/log/syslog.1 (14 GB)
und /var/log/daemon.log.1 (22 G) unmäßig viele Einträge den Dienst qcontrol betreffend: NAS-01 qcontrol[420]: (PIC 0x0) unknown command from PIC
Ich habe schließlich diese Dateien und das Verzeichnis Journal in /var/log gelöscht, wieder angelegt und das NAS neu gestartet.
Dann habe ich das Journal in eine Textdatei geschrieben und diese zum Desktoprechner übertragen, um sie dort auszuwerten.
Obwohl ich ja das Journal vor dem Neustart gelöscht hatte, begann dieses mit einem Bootvorgang vom 14.02.2019 11:12:02, endete dann aber
10 Sekunden später mit der Meldung "System clock time unset or jumped backwards, restoring from recorded timestamp: Fri 2020-02-28 23:59:46 CET".