Einmaliges Aussetzen des Shutdowns per Energieplan

Hinweis: Nach dem 31.12.2025 ist eine Registrierung nicht mehr möglich, nutze die verbleibenden Tage!
    • Neu

    Nein, keiner muss ins andere Forum wechseln. ;)


    Ich habe nun zunächst eine Quick'n'dirty Version fertig gestellt, da ist noch Optimierungspotential, aber ich habe eben wenig Zeit.

    Es sind auch noch einige überflüssige Zeilen drin da ich das meiste aus einem meiner anderen Skripte kopiert habe.

    Das Script ist im Codeblock und macht folgendes:

    Prüfen ob das Filesystem clean ist -> keine weitere Aktion außer Statusmail senden (Empfangs- und Senderadresse muss im oberen Teil selbst eingetragen werden).

    Wenn Filesystem nicht clean (d.h. z.B. rebuild oder resync) -> ändere den crontab Eintrag für den Shutdown auf den nächsten Tag.


    Rudimentär gestestet läuft es bei mir (d.h. der crontab Eintrag wird geändert).

    Trotzdem: keine Gewähr! Benutzung auf eigene Gefahr.


    Rückmeldungen erwünscht.

    Geplante Optimierung: Auslesen der Restzeit für rebuild/resync und dadurch ggf. keine Änderung der crontab oder Rückstellung auf den aktuellen Tag.

    Default ist device /dev/md1 , für alte NAS (CAT1) oder andere mdadm devices muss das Skript mit dem Parameter md0 oder md2 (oder allgemein mdX wobei X=Nummer des md devices) aufgerufen werden.


    Updates dazu nach Freischaltung in der Filebase. Sobald das Skript dort downloadbar ist, entferne ich hier den Codeblock!

    Mehrere md devices parallel werden derzeit nicht unterstützt. Theoretisch könnte man das Skript unter verschiedenen Namen mit dem jeweiligen md-Parameter eintragen und so auch mehrere md devices gleichzeitig prüfen, also z.B. in der crontab:


    10 10 * * * /etc/config/scrub_md1.sh md1

    10 12 * * * /etc/config/scrub_md2.sh md2


    Wobei scrub_mdX.sh jeweils dasselbe Skript ist (d.h. die Skript Datei ist unter beiden Dateinamen abgespeichert.

    Allerdings sehe ich hier das Risiko das bei unterschiedlichen Laufzeiten des Scrubbing/Rebuilds sich die Skripte gegenseitig stören.

    Auch kann eine Änderung in einer Datei evtl. in der anderen vergessen werden, also nicht zu empfehlen.


    Gruss


    P.S. Die Mailadresse im Script "nobody@somewhere.com" ist natürlich eine Fake Adresse und bewirkt nur, das KEINE Mail gesendet wird.

    Das hab ich eingebaut da ich nicht jedesmal beim Testen eine Mail senden will.

    In diesem Skript greift das aber (noch) nicht, da ich hier die Parameter Eingabe noch nicht umgesetzt habe.


    P.P.S. Wie angekündigt habe ich den Codeblock entfernt da das Skript in Kürze in der Filebase ist.

    Achtung: die gegenwärtige Version 1.0.0 hat noch einen Fehler im Trigger, bitte auf V1.2 warten.

    9 Mal editiert, zuletzt von FSC830 ()

    Danke 1
    • Neu

    Ich würde ein grep 'Resync' auf /proc/mdstat machen, da ist man unabhängig von einer Angabe des Devices.

    out = /bin/cat /proc/mdstat | grep 'Resync'

    • Neu

    Ok, danke, muss ich mal schauen. Ich habe gerade die 1.2 hochgeladen.

    Ich werde den Trigger evtl. noch mal ändern, denn die Restlaufzeit erhalte ich auch aus /proc/mdstat :

    Code
    md1 : active raid5 sda3[4] sdd3[7] sdc3[6] sdb3[5]
      5830677504 blocks super 1.0 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      [===============>.....]  resync = 76.2% (1482678548/1943559168) finish=131.0min speed=58616K/sec
      bitmap: 3/15 pages [12KB], 65536KB chunk

    Aber ich sagte ja, quick'n'dirty für den ersten Wurf. ^^

    Nur schade, das QNAP selbst nicht an sowas denkt und das NAS einfach runterfährt während ein solcher Prozess läuft. ?(


    Gruss


    P.S. Könntest Du v.1.0 bitte aus der Filebase rausnehmen? Nicht, das jemand gleich mit den buggy Teil anfängt.

    • Neu

    Mal sehen wie, eine Script Lösung ist m.E. eher "suboptimal", das gehört ordentlich eingepflegt, so wie in den Energieplan Einstellungen der Haken "Reboot verzögern wenn Backup aktiv".

    Aber das wird sicherlich nicht von heute auf morgen gehen.


    Gruss

    • Neu

    @all


    ich berichte natürlich, wenn sich da was ergeben hat/wenn ich Nachricht bekommen habe

    Eine allgemeingültige Lösung von QNAP in einer der kommenden FW's wäre natürlich erstrebenswert. Auch wenn es etwas dauert :)


    Gruß

    • Neu

    Zacharias

    In der Filebase ist demnächst die Version 1.4 des Scripts vorhanden.

    Damit sollte die Verzögerung des Shutdowns problemlos funktionieren, aber alle möglichen Kombinationen konnte ich bisher nicht testen.

    Das Script hat im Grunde zwei Modi:

    1. Der Shutdown wird auf den nächsten Tag verschoben (gleiche Uhrzeit)

    2. Das Taskende des Scrubbings wird rechnerisch ermittelt und liegt es später als der geplante Shutdown wird die crontab angepasst.


    Das Taskende ist aber dynamisch und differiert je nach NAS Auslastung, daher ist ein Puffer von +1 Stunde eingerechnet.

    Trotzdem empfiehlt es sich in diesem Modus das Script auch im Intervall laufen zu lassen, nicht nur 1x.

    Für Mail Benachrichtigungen muss man entweder im Script die Empfänger- und die Sendermailadresse eintragen oder gibt beides als Parameter mit, wenn man das Script nicht editieren will.

    Scriptaufruf -h liefert einen Hilfetext zu den Parametern.

    Bei Gelegenheit stelle ich eine passende Dokumentation dazu ein.


    Gruss

    • Neu

    Hallo FSC830

    danke erstmal für Deine Arbeit. Das was in #47 steht hört sich auf jeden Fall sehr gut an :)

    Zitat von FSC830

    Bei Gelegenheit stelle ich eine passende Dokumentation dazu ein

    Das werde ich auf jeden Fall brauchen, denn Stand jetzt ist mir als Linux-Amateur die Implementierung noch unklar (wohin mit dem Skript, Eintrag in den crontab ob und wie, ...)

    Parallel dazu werde ich aber auch noch die Antwort vom HelpDesk abwarten. Stand jetzt (14.02.2026 15:45) gibt es dazu leider noch keine Rückmeldung


    VG Zacharias :) :thumbup:

    • Neu

    Erledigt, V1.5 prüft nun auch noch ob ein Rebuild läüft und verschiebt dann ebenfalls den Shutdown.

    Eine PDF mit Erklärungen ist auch dabei, die hänge ich hier aber schon man an, wenn die Freischaltung erfolgt ist, nehme ich sie hier wieder raus.


    Gruss


    P.S. Morgen ist der ideale Tag zum testen: der 15. ;)


    Dateianhang entfernt, es ist nun alles in der Filebase zum Download bereit:

    Einmal editiert, zuletzt von FSC830 ()

    Gefällt mir 1 Danke 1
    • Neu
    Zitat von FSC830

    Morgen ist der ideale Tag zum testen: der 15.

    Soo schnell bin ich nicht mehr. Die RAID-Bereinigung hatte ich auch schon mal vorgezogen auf den 11. für alle drei. Sonst verliere ich noch den Überblick ;)

    Mir wäre die Antwort vom HelpDesk aber auch noch wichtig, bevor ich wieder rumschraube am crontab und neue Skripte drauf lade


    VG Zacharias

    • Neu

    FSC830 ich habe das Thema, und das was Du an Vorleistung gebracht hast, nicht vergessen :)

    Seit dem 13.01.2026 gibt's keine Rückmeldung mehr vom Entwicklerteam, warum auch immer

    Zwischenzeitlich habe ich mich mit meinem Raspi und der APC-USV beschäftigt. Ist auch noch nicht ganz fertig, aber immerhin kommunizieren die beiden schon mal

    V1.6 von Dir nehme ich zum Testen des Aussetzen des Shutdowns, dann vermutlich bis zum Wochenende


    VG Zacharias

    Moin,


    ich habe mich per Google mal durchgewühlt wg. kopieren/bearbeiten unter Linux, ... und das Skript nach /etc/config kopiert, sowie den crontab angepasst

    Zur Nachverfolgbarkeit hier ein Screenshot:


    pasted-from-clipboard.png


    Also muss morgen (28.02.2026) nach 10:00 Uhr beim shutdown eine "0" für Sonntag stehen. Falls die RAID-Bereinigung noch nicht fertig sein sollte, muss das Skript am Sonntag um 10:00 Uhr dann "1"=Montag reinschreiben. Allerdings hat meine RAID-Bereinigung noch nie länger als 24h gedauert


    P.S.: DeskHelp soll natürlich HelpDesk heißen. Zu spät gesehen

    Einmal editiert, zuletzt von Zacharias () aus folgendem Grund: Ein Beitrag von Zacharias mit diesem Beitrag zusammengefügt.

    • Neu

    Update 2

    FSC830

    Das Skript hat den crontab um 10:00 Uhr angepasst, aber eig.hätte ich als Wochentag eine "0" erwartet, so wie beim startup:


    pasted-from-clipboard.png


    Quelle: https://de.wikipedia.org/wiki/Cron

    Nochmals Danke für Deine Mühe. Die Lösung gefällt mir besser, als das von den Entwicklern. Das Skrip funktioniert ohne Änderung, auch wenn sich der Tag zur RAID-Bereinigung verschieben sollte :) :thumbup:

    Update 3

    FSC830:


    Da hat wohl der crontab die "7" als nicht gültig erkannt, und hat den shutdown "sicherheitshalber" am Samstagabend ausgeführt, oder?

    Danach sind die Tage für shutdown und startup wieder richtig gestellt worden (0 und 1, Sonntag Abend aus, Montag Morgen wieder ein). -> Kontrolliert vor dem Aufruf des skip_shutdown_v16.sh, also heute vor 10:00 Uhr


    pasted-from-clipboard.png



    Nach 10:00 Uhr gibt's da auch keine Änderung mehr. Könntest Du bitte nochmal nach der Korrektur des Tages schauen, siehe auch Screenshot in #52?

    Danke im Voraus :)

    Frage/Hinweis,


    pasted-from-clipboard.png




    müsste es nach der Definition vom cronab hier nicht heißen: Wenn nach dem Inkrement 7 rauskommt, dann wird der neue Tag 0?

    P.S.: Ich weiß, dass Schleifen manchmal anders konstruiert werden, als dann die Ausgaben. Aber ich habe nirgends ein Dekrement gefunden zumindest nicht mit meinen rudimentären Skriptkenntnissen


    VG Zacharias

    2 Mal editiert, zuletzt von Zacharias () aus folgendem Grund: Ein Beitrag von Zacharias mit diesem Beitrag zusammengefügt.

    • Neu

    Hi, nein, das stimmt schon.

    Für Sonntag kann man "0" oder "7" nehmen, das ist gleich.

    Im "einfachen" Modus wird der Shutdown um einen Tag verschoben, es wird also "1" zum aktuellen Eintrag addiert. Bei Dir läuft es Sonntags und der zugehörige date +%u Output liefet dafür die "7", nicht die "0". Daher ist der "neue" Tag 8 (den gibt es aber nicht) -> also wird daraus "1" für Montag.


    Gruss

    • Neu

    Moin,

    aber das NAS ist Samstag Abend runtergefahren, obwohl ja die 7 drin stand (Update2+3), und der Shutdown hat dann die 0 reingemacht für Sonntag.

    Ich mache den Test jetzt mal für heute, und stoße die RAID-Bereinigung nochmals an. Mal sehen, ob das NAS heute Nacht durchläuft. Dann ist der Überlauf ein Sonderfall


    Gruß, Zacharias

    • Neu

    Was steht denn im Log des Scriptes?


    Gruss


    Edit: Aber vom Screenshot her passt es. Der Scrub läuft Samstags, der Poweroff ist für Sonntag eingetragen.

    Sieht so aus, als ob die Änderung der Crontab ignoriert wird. :rolleyes:

    Das teste ich nochmals bei mir, bei mir lief das NAS durch und hat sich am nächsten Tag ausgeschaltet.

    • Neu

    Gerade gemacht. Ergebnis wie erwartet für shutdown/startup am Dienstag:


    pasted-from-clipboard.png


    EDIT: Habe ich heute morgen geschrieben, und vergessen abzuschicken. Hat mir jemand hier dazwischen gequatscht :rolleyes:

    In dem LOG stand: "Warning! Filesystem is NOT clean !", wenn ich das richtig ausgelesen habe

    -> Heute Abend also hoffentlich kein Shutdown (die RAID-Bereinigung lief immer noch oder wieder neu), morgen berichte ich


    Gruß Zacharias

    Einmal editiert, zuletzt von Zacharias ()

    • Neu

    Ich sehe es auch erst später, das Scrubbing startet erst noch.

    Ich habs auf zwei NAS konfiguriert, die sollten also heute durchlaufen und sich morgen ausschalten.


    Gruss

    • Neu

    Ach ja, wenn es interessiert: Immer noch keine Rückmeldung von den Entwicklern. Ticket ist noch offen (in Bearbeitung) :(

    Update:

    FSC830 Das ist bis jetzt wie gewollt gelaufen:

    - Der poweroff gestern Abend wurde nicht ausgeführt

    - RAID-Bereinigung ist heute Nacht beendet worden

    - Nach 09:00 Uhr steht poweroff immer noch auf Dienstag Abend

    -> Alles OK. Ich gehe dann mal von einem poweroff heute Abend aus


    Ich starte das Ganze nochmal am Samstag, wenn dann wieder die 7 als Wochentag reingeschrieben wird.


    Gruß Zacharias

    Poweroff und startup haben wie geplant stattgefunden. Mal sehen wie sich das am Samstag/Sonntag verhält

    2 Mal editiert, zuletzt von Zacharias () aus folgendem Grund: Ein Beitrag von Zacharias mit diesem Beitrag zusammengefügt.

    • Neu

    Update:

    FSC830


    Ich habe die RAID-Bereinigung wie angekündigt am Samstag um 08:00 Uhr gestartet. Der Aufruf vom Skript (skip_shutdown_v16.sh) über den crontab war um 09:00

    Der Eintrag (für poweroff) im crontab wurde dann auf: 45 21 * * 7 /etc/init.d/poweroff (21:45 Uhr, 7 (Sonntag)) geändert. Das NAS ist trotzdem am Samstagabend heruntergefahren. So wie ich das sehe, funktioniert der crontab mit der 7 statt der 0 für Sonntag nicht

    Gegenprobe: Wenn ich Raid-Bereinigung oder den Energieplan über das GUI am Sonntag aktiviere, steht im crontab immer die 0 für Sonntag

    Ich denke, ich werde die Abfrage für IF NEW_DAY == 8 in 7 ändern und weise dann NEW_DAY = 0 zu

    Betrift die Zeilen 142, 143/ 216, 217. Ich hoffe, ich habe nichts übersehen

    Letzten Dienstag hat das Skript erwartungsgemäß funktioniert. Wenn das jetzt auch noch geht, wenn die RAID-Bereinigung aufs WE fällt, dann ist es super. Vllt.kommt die Entwicklung auch mal auf die Idee, die RAID-Bereinigung beim Verzögern des poweroff noch reinzubringen


    Gruß Zacharias