rtcwake falsche Zeit

[phillow]

Hallo,

ich möchte meinen Server einmal pro Woche zu einer festen Zeit starten lassen, damit er sich ein Backup meines zweiten Servers zieht.
Das möchte ich mit rtcwake umsetzen.
Grundsätzlich funktioniert rtcwake, also mit

rtcwake -m off -s 300

fährt mein Server runter und startet nach 5 Minuten wieder.

Jetzt möchte ich mit

rtcwake -m no -l -t $(date +%s -d 'Sunday 10:00')

meinen Server am Sonntag um 10:00 Uhr starten.

Als Bestätigung bekomme ich aber

rtcwake: wakeup using /dev/rtc0 at Sun Nov 11 11:00:00 2018

Im Bios ist die korrekte Zeit hinterlegt, ebenso in Openmediavault.

Weiß jemand einen Rat?

 

[BlubbsDE]

Das Linux Zeitformat, bzw. die Linux Standardzeit ist der Grund.

 

[phillow]

Ich habe jetzt schon viel gesucht und endlich die Lösung gefunden.
Ein -u nach date löst das Problem.
Bin gespannt was bei der nächsten Zeitumstellung passiert.

 

[PolarSun]

Als best practice gilt eigentlich die RTC auf UTC zu setzen und die System clock sich um die lokale Zeit kümmern zu lassen (Zeitzone, Zeitumstellung). Das sollte dann - einmal korrekt eingerichtet - dauerhaft passen.

 

[phillow]

https://wiki.ubuntuusers.de/Systemzeit/

Ist es das was Du meinst?
Mich wundert nur dass die Systemzeit ja eigentlich passt ...

 

[PolarSun]

Ja genau.

Frage doch mal ab, wie die Einstellung bei Dir ist.

timedatectl | grep local

Dann wird dir angezeigt ob die RTC local ist oder nicht. Mit

timedatectl set-local-rtc 0

setzt Du die Hardware Clock auf UTC.

 

[phillow]

timedatectl | grep local
RTC in local TZ: no

Also nicht lokal.

timedatectl
 Local time: Sa 2018-11-10 20:40:53 CET
  Universal time: Sa 2018-11-10 19:40:53 UTC
        RTC time: Sa 2018-11-10 19:40:53
       Time zone: Europe/Berlin (CET, +0100)
       Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Müsste ich dann nicht

sudo timedatectl set-timezone Europe/Berlin

setzen um die Zeit korrekt einzustellen?
Ich bin etwas verwirrt.

 

[PolarSun]

Nein, alles super. Ist bei Dir schon so eingestellt wie es sein soll. Man muß nur berücksichtigen, wenn man nach UTC (= RTC) um 10.00 Uhr einschaltet, dann ist es bei uns lokal bereits 11.00 Uhr, weil für unsere Zeitzone gilt CET = UTC +1.

 

[PolarSun]

Nur noch mal zur Klarstellung, was das Problem mit Deiner Anweisung ist (fett hervorgehoben):

rtcwake -m no -l -t $(date +%s -d 'Sunday 10:00')

Wenn Du diese Option übergibst, sagst Du dem Kommando, Deine RTC läuft nach lokaler Zeit. Bei Dir läuft die RTC aber nicht nach lokaler Zeit, sondern nach UTC. Also einfach -l weglassen, denn sonst wird quasi doppelt korrigiert - einmal normal über die Systemzeit gemäß Deiner Zeitzoneneinstellung und dann noch einmal über die fälschlicherweise übergebene Option. (Im Ubuntu-Wiki ist das etwas mißverständlich formuliert. Falls Du Dich daran orientiert hast, kam es deshalb vielleicht zu dieser Unklarheit.)

 

[phillow]

Das heißt dass die Ausgabe durch die Zeitzonen versetzt ist?

rtcwake -m no -t $(date +%s -d 'Sunday 10:00')

liefert

rtcwake: wakeup using /dev/rtc0 at Sun Nov 11 09:00:00 2018

Startet der Server dann trotzdem um 10:00?

rtcwake -m no -t $(date -u +%s -d 'Sunday 10:00')

liefert

wakeup using /dev/rtc0 at Sun Nov 11 10:00:00 2018

Startet er hier ebenfalls um 10:00?

 

[phillow]

So jetzt hab ichs glaub ich:

rtcwake -m no -t $(date +%s -d 'next Sunday 10:00')

Mich hat nur die Ausgabe mit 09:00 Uhr verwirrt, aber so wie ich das verstehe liegt es daran dass die Bestätigung in UTC ausgegeben wird und ich dann +1:00 rechnen muss für unsere Zeitzone.
Wäre jetzt Sommerzeit würde dann die Bestätigung eigentlich mit 08:00 Uhr ausgegeben werden?

Das pack ich jetzt noch in eine crontab und lasse den Befehl jeden Sonntag um 10 Minuten nach 10:00 Uhr ausführen, ich hoffe das klappt.

 

[phillow]

Doch noch nicht.
Bei meinem Eigenbauserver klappt es jetzt wie oben beschrieben.
Bei meinem HP Server komischerweise nicht.

rtcwake -m no -t $(date +%s -d 'next Sunday 10:00')

liefert

rtcwake: set rtc wake alarm failed: Das Argument ist ungültig

 rtcwake -m no -t $(date +%s -d 'next Monday 10:00')

funktioniert hingegen.
Was mach ich falsch?

root@hpserver:~# timedatectl
      Local time: So 2018-11-11 14:10:03 CET
  Universal time: So 2018-11-11 13:10:03 UTC
        RTC time: So 2018-11-11 13:10:03
       Time zone: Europe/Berlin (CET, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no

Auf beiden Servern ist OMV 4 in der aktuellsten Version installiert.

Hoffe hier kann noch jemand weiterhelfen?

 

[PolarSun]

Hm, ich weiß nicht genau wie die Angaben des date Strings geparst werden. Vorstellbar wäre für mich nach Deiner Beschreibung, daß der "next Sunday" für das System heute ist, wenn zuerst eine Übereinstimmung mit dem Wochentag geprüft wird. Wird danach erst nach 10:00 geschaut, ergibt es eine Zeit/ein Datum in der Vergangenheit. Damit kann rtcwake jedoch nichts anfangen.

Versuche doch auch noch mal 'next Sunday 18:00" und schaue ob das Argument gültig wird.

 

[phillow]

Hi,
es scheint auf dem Microserver Gen8 ein Problem zu geben.
Ich kann ja auf zwei Servern parallel testen, auf dem Selbstbau NAS funktioniert es mit 'next Sunday', auf dem Microserver nicht.
Ich habe jetzt geschaut, was im Hintergrund läuft, und siehe da ...
Wenn ich

rtcwake -m no -t $(date +%s -d 'next Sunday 10:00')

in der Konsole eingebe, erscheint ja oben genannte Fehlermeldung.
Der Microserver meldet parallel im Hintergrund:

rtc_cmos 00:01: alarms can be up to one day in the future

Hast Du eine Idee was das sein kann?
Google bringt mich leider nicht weiter.
Kann es sein dass hier ein BIOS Update hilft?

 

[PolarSun]

Tut mir leid, da bin ich mit meinem Latein am Ende. CMOS-Batterie ist noch in Ordnung?

Falls es ein BIOS-Update gibt, kannst Du freilich mal schauen ob in diesem Zusammenhang so ein Punkt adressiert wurde.

Allerdings ist es tatsächlich so, daß nicht jede Hardware geeignet ist, einen Alarm weiter als einen Tag in die Zukunft zu setzen. Dies könnte bei dem Microserver der Meldung nach zutreffen und die Hardwarebeschränkung als solche kannst Du leider nicht aufheben.

Das könntest Du dann nur versuchen zu umgehen indem Du rtcwake jeweils innerhalb dieser Frist setzen läßt.

 

[lokon]

Der Microserver meldet parallel im Hintergrund:

alarms can be up to one day in the future

Bei Serverhardware ist die Limitierung nicht ungewöhnlich und es ist hardwareabhängig vom chipsatz/verwendeter RTC.

 

[phillow]

Ich habe jetzt ILO und BIOS aktualisiert, leider noch keine Änderung.
Ich lade grade noch das letzte Service Pack runter und aktualisier damit noch den Rest.
Falls es dann immer noch nicht geht, lass ich den Server jeden Tag Starten und am Sonntag läuft dann halt das Backup per rsync.
Als Alternative für mich auch in Ordnung.
Danke für Eure Hilfe.

 

[phillow]

Um das ganze abzuschließen, es scheint eine Hardwarelimitierung vorzuliegen.
Im Hardwareluxx-Forum war ein User so nett und hat mit seinem HP Gen8 die Befehle getestet und kam zum gleichen Ergebnis.
Schade, aber so lass ich den Server jetzt halt jeden Tag kurz aufwachen, wenn keine neue Daten verfügbar sind, legt er sich nach 30 Minuten wieder schlafen.
Danke nochmal für Eure Hilfe.

 

[phillow]

Ich bring das Thema nochmal vor nachdem ich jetzt eine Woche mit rtcwake rumgespielt habe.
Grundsätzlich funktioniert es jetzt, aber:
Kann es sein dass der rtcwake Alarm verloren geht wenn der Server zwischenzeitlich runter- und wieder hochgefahren wird?
Das ist nämlich die Beobachtung die ich gemacht habe.
Wenn ich den Alarm setze und der Server schaltet sich dann nachts aus, funktioniert der Alarm am nächsten Tag. Wenn ich aber den Server nach setzen des Alarms runter- und wieder hochfahre, ist der Alarm gelöscht.
Hat jemand von Euch die gleiche Erfahrung gemacht?

 

[lokon]

Kann das ein "Feature" oder ein Nebeneffekt sein von soetwas wie
beim mythpc ACPI wakeup via redhat Bugzilla

With most RTCs, the machine will not wake up if the hardware clock has been modified after the wakeup alarm has been set. To avoid this, it is necessary to disable the writing of the current system time to the RTC by the system shutdown scripts

bzw

I think some BIOS reset the wakealarm because they assume that if the time has changed then the alarm's not going to be at the right time anymore so it's better not to have it

Das sind vielleicht "Designentscheidungen" die in bestimmten Fällen sinnvoll/nicht sinnvoll sind und wegen "zuviel Dokumentation" einfach nicht für Endnutzer aufgeschrieben werden.