117471
Apr 30, 2021
2873
13
1
Linux: cron-Job während des WOL-Zeitfensters
Hallo,
sicherlich ist jeder schon mal auf die Idee gekommen, den PC nachts per WOL zu starten, einen cron-Job laufen zu lassen und den Rechner dann wieder (automatisch) herunterzufahren.
Problem: Wenn unser Rechner absichtlich angelassen wurde, dann grätscht uns unser Shutdown irgendwo rein.
Meine Idee ist, beim Start zu prüfen, ob man sich im WOL-Zeitfenster befindet. Falls ja, wird der Rechner nach dem cron-Job heruntergefahren Ansonsten lässt man ihn halt laufen.
Das Verfahren habe ich hier beschrieben: https://www.altmetaller.de/linux-naechtliche-routinejobs-per-wol-wake-on ...
Wie findet Ihr das, so von der Idee / Umsetzung her?
Gruß,
Jörg
sicherlich ist jeder schon mal auf die Idee gekommen, den PC nachts per WOL zu starten, einen cron-Job laufen zu lassen und den Rechner dann wieder (automatisch) herunterzufahren.
Problem: Wenn unser Rechner absichtlich angelassen wurde, dann grätscht uns unser Shutdown irgendwo rein.
Meine Idee ist, beim Start zu prüfen, ob man sich im WOL-Zeitfenster befindet. Falls ja, wird der Rechner nach dem cron-Job heruntergefahren Ansonsten lässt man ihn halt laufen.
Das Verfahren habe ich hier beschrieben: https://www.altmetaller.de/linux-naechtliche-routinejobs-per-wol-wake-on ...
Wie findet Ihr das, so von der Idee / Umsetzung her?
Gruß,
Jörg
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 666273
Url: https://administrator.de/contentid/666273
Printed on: April 18, 2024 at 02:04 o'clock
13 Comments
Latest comment
Ich würde etwas anders herangehen.
Ausgangspunkt ist doch, dass der Linux-(Einzel)Rechner (eigentlich) aus ist und per WOL gestartet werden soll. Den WOL-Start veranlasst ein anderer Rechner. Dann bietet es sich doch an, nicht nur den WOL-Befehl abzusetzen, sondern das Script nicht über einen CronJob, sondern mit einem ausreichenden Offset von diesem Rechner aus (über ssh) zu starten. Das hat zumindest den Vorteil, dass der Startzeitpunkt variiert werden kann, ohne etwas auf dem Einzelrechner anpassen zu müssen. Der Startrechner muss ja ohnehin (ständig oder zur fraglichen Zeit) laufen, um den WOL absetzen zu können.
Bevor der Startrechner den WOL-Befehl absetzt, kann anhand eines Pings etc. geprüft werden, ob der Einzelrechner online ist und in Abhängigkeit wird das eigentliche Script mit unterschiedlichen Parametern gestartet.
Ist der Einzelrechner eine VM, dann kann das Ausführen des WOL-Befehls aber auch von einer Abfrage beim Hypervisor abhängig gemacht werden. Dabei wird natürlich kein WOL-Befehl abgesetzt, sondern die VM schlichtweg gestartet.
Anstelle des WOL-Befehls könnte auch ein automatischer Start im BIOS eingestellt werden. Dann braucht man keinen Startrechner. Gleichwohl verbliebe es natürlich beim CronJob und der prüft anhand der letzten Zeile aus dmesg, wie lange der Einzelrechner schon läuft. Ist das länger als das zeitgesteuerte Booten, dann gibt es eben keinen Aufruf von shutdown. So ließe sich das natürlich auch im Falle der Initialisierung von einem Startrechner aus machen.
Das wären meine spontanen Gedanken für etwaige alternative Lösungsansätze.
Viele Grüße
HansDampf06
Ausgangspunkt ist doch, dass der Linux-(Einzel)Rechner (eigentlich) aus ist und per WOL gestartet werden soll. Den WOL-Start veranlasst ein anderer Rechner. Dann bietet es sich doch an, nicht nur den WOL-Befehl abzusetzen, sondern das Script nicht über einen CronJob, sondern mit einem ausreichenden Offset von diesem Rechner aus (über ssh) zu starten. Das hat zumindest den Vorteil, dass der Startzeitpunkt variiert werden kann, ohne etwas auf dem Einzelrechner anpassen zu müssen. Der Startrechner muss ja ohnehin (ständig oder zur fraglichen Zeit) laufen, um den WOL absetzen zu können.
Bevor der Startrechner den WOL-Befehl absetzt, kann anhand eines Pings etc. geprüft werden, ob der Einzelrechner online ist und in Abhängigkeit wird das eigentliche Script mit unterschiedlichen Parametern gestartet.
Ist der Einzelrechner eine VM, dann kann das Ausführen des WOL-Befehls aber auch von einer Abfrage beim Hypervisor abhängig gemacht werden. Dabei wird natürlich kein WOL-Befehl abgesetzt, sondern die VM schlichtweg gestartet.
Anstelle des WOL-Befehls könnte auch ein automatischer Start im BIOS eingestellt werden. Dann braucht man keinen Startrechner. Gleichwohl verbliebe es natürlich beim CronJob und der prüft anhand der letzten Zeile aus dmesg, wie lange der Einzelrechner schon läuft. Ist das länger als das zeitgesteuerte Booten, dann gibt es eben keinen Aufruf von shutdown. So ließe sich das natürlich auch im Falle der Initialisierung von einem Startrechner aus machen.
Das wären meine spontanen Gedanken für etwaige alternative Lösungsansätze.
Viele Grüße
HansDampf06
Hallo,
Da liegt tatsächlich der Gedankenfehler - das WOL macht z.B. ein Router, da sind die Gestaltungs- und Scriptingmöglichkeiten eher begrenzt.
Zusätzlich wäre da eine SSH-Verbindung auf der Workstation erforderlich, was eine potentielle Sicherheitslücke ist. Auf Workstations ist i.d.R. nicht einmal ein SSH-Daemon installiert.
Korrekt, und das ist bei einigen Boards auch tatsächlich erforderlich - WOL funktioniert da "nur" aus dem S1 bis S4 und nicht bei S5. Was im Übrigen kein korrektes Verhalten ist.
Gruß,
Jörg
Zitat von @HansDampf06:
Ich würde etwas anders herangehen.
Den WOL-Start veranlasst ein anderer Rechner.
Ich würde etwas anders herangehen.
Den WOL-Start veranlasst ein anderer Rechner.
Da liegt tatsächlich der Gedankenfehler - das WOL macht z.B. ein Router, da sind die Gestaltungs- und Scriptingmöglichkeiten eher begrenzt.
Zusätzlich wäre da eine SSH-Verbindung auf der Workstation erforderlich, was eine potentielle Sicherheitslücke ist. Auf Workstations ist i.d.R. nicht einmal ein SSH-Daemon installiert.
Anstelle des WOL-Befehls könnte auch ein automatischer Start im BIOS eingestellt werden.
Korrekt, und das ist bei einigen Boards auch tatsächlich erforderlich - WOL funktioniert da "nur" aus dem S1 bis S4 und nicht bei S5. Was im Übrigen kein korrektes Verhalten ist.
Gruß,
Jörg
Zitat von @117471:
das WOL macht z.B. ein Router, da sind die Gestaltungs- und Scriptingmöglichkeiten eher begrenzt.
das WOL macht z.B. ein Router, da sind die Gestaltungs- und Scriptingmöglichkeiten eher begrenzt.
Das ist wohl zutreffend und könnte/müsste im Falle des Falls geprüft werden. ABER: Es ist zugleich eine wesentliche Einschränkung des Anwendungsfalls, die unerwähnt geblieben ist. Dass Deine Firewall das übernehmen soll, besagt schließlich nichts über das Nichtvorhandensein von Scriptfähigkeiten, wenn sie immerhin einen Scheduled Task ausführen kann. Jetzt ist das ja klar, so dass ein Teil meiner Überlegungen für diesen Fall in der Tat obsolet ist.
Aber wenn wir schon dabei sind, besondere Konstellationen zu betrachten, dann kommt in Bezug auf die von Dir beschriebene Unsicherheit des WOL-Befehls in Betracht, die Stromzufuhr des Einzelrechners als Trigger für das BIOS-veranlasste Booten zu verwenden. Voraussetzung ist allerdings, dass ein geeigneter Mechanismus (z.B. steuerbarer Zwischenstecker mit Leistungsmessung) vorhanden ist, bei dem nach dem Herunterfahren des Einzelrechners die Stromzufuhr getrennt wird. Zur fraglichen Zeit schaltet der Mechanismus die Stromzufuhr wieder ein und das automatische Booten wird ausgelöst. Alles andere erfolgt dann wie gehabt über den CronJob.
Ein solcher Mechanismus benötigt natürlich ebenso einen Initiator, der zur fraglichen Zeit aktiv ist. Der beispielhaft benannte Zwischenstecker könnte in einer ohnehin vorhandenen Hausautomation integriert sein. Zeitfunktionen sind dann jederzeit über deren Zentrale möglich.
Würde der Einzelrechner ein Raspberry Pi (4b oder vergleichbar) sein, dann ist das automatische Hochfahren beim Einschalten der Stromzufuhr eine typische Funktion. Dort könnte der Zwischenstecker durch eine entsprechende Relaissteuerung für die 5V-Versorgung ersetzt werden.
Es gibt also vielerlei Umsetzungsmöglichkeiten und sogar solche, bei denen unabhängig von einem Router/Firewall, einem Startrechner, einer Hausautomation oder ... ein Auslösen des automatischen Bootens verwirklicht werden kann, um den "unsicheren" WOL-Befehl zu meinden - zumindest wenn es in dieser Hinsicht um Funktionssicherheit geht.
Übrigens ist die Funktionssicherheit des WOL-Befehls virulent, wenn es bei regulärer Verwendung des Einzelrechners im Bereich des (menschlich) Möglichen liegt, den Einzelrechner "ungewollt" in den von Dir beschriebenen S5-Status zu schicken. In diesem Fall hilft es nichts, dass der WOL-Befehl eigentlich funktionieren müsste, wenn er es halt nicht macht. Ähnliches gilt für das Triggern über die Stromzufuhr, wenn deren irrige Abschaltung während eines bestimmten Energie(spar)zustandes des Einzelrechners unerwünschte Fehlerfolgen auslösen würde.
Ein weiterer Punkt für den WOL-Befehl ist die Frage, ob die Netzwerkkarte bei einer irregulären Stromunterbrechung einen solchen Befehl verarbeiten würde, wenn nicht zuvor der Einzelrechner einmal hoch- und heruntergefahren wurde.
Insgesamt ist also um das automatische Booten herum eine ganze Menge zu bedenken und gegebenenfalls auszuprobieren.
Zusätzlich wäre da eine SSH-Verbindung auf der Workstation erforderlich, was eine potentielle Sicherheitslücke ist. Auf Workstations ist i.d.R. nicht einmal ein SSH-Daemon installiert.
Auch das ist grundsätzlich richtig. Dennoch kommt es darauf an, welche tatsächliche(n) Aufgabe(n) nachts zu erledigen ist/sind und was an Software auf dem Einzelrechner ohnehin schon vorhanden ist. In Abhängigkeit davon existiert eine potentielle Sicherheitslücke vielleicht bereits, sodass das Script keine zusätzliche Relevanz entfaltet. Das gilt freilich neben dem beispielhaft benannten ssh ebenso für Alternativen eines extern veranlassten Scriptstarts.
Ungeachtet all dieser Detailüberlegungen ist Deine Anleitung natürlich sehr hilfreich als Anregung und Umsetzungshilfe, um in einer vergleichbaren Situation das Problem einer nächtlichen Aufgabenerledigung auf nicht durchlaufenden Einzelrechnern angemessen lösen zu können. Deine Anleitung ist in der Regel sofort umsetzbar und darauf kommt es letztlich an. Besonderheiten des Einzelfalls erfordern gegebenenfalls geeignete Anpassungen.
Einen schönen Abend
HansDampf06
Ich würde es nicht an der Uhrzeit festmachen sondern an der uptime der Maschine.
Wenn ihr den Rechner aufweckt, hat dieser ja beim Start des Scripts eine Uptime von nur wenigen Minuten - dann kann man ihn auch herunterfahren.
Wenn ihr den Rechner aufweckt, hat dieser ja beim Start des Scripts eine Uptime von nur wenigen Minuten - dann kann man ihn auch herunterfahren.
Hallo,
was für ein unglaublich cooler Einfall!
Gruß,
Jörg
was für ein unglaublich cooler Einfall!
Gruß,
Jörg
Zitat von @LordGurke:
Ich würde es nicht an der Uhrzeit festmachen sondern an der uptime der Maschine.
Ich würde es nicht an der Uhrzeit festmachen sondern an der uptime der Maschine.
Das ist genau das, was ich in meinem ersten Kommentar mit
der prüft anhand der letzten Zeile aus dmesg, wie lange der Einzelrechner schon läuft. Ist das länger als das zeitgesteuerte Booten, dann gibt es eben keinen Aufruf von shutdown.
meinte. Natürlich ist das ins Unreine gesprochen, weil die letzte Zeile eine Meldung enthalten kann, die schon länger her ist, so dass der bloße Sekundenwert am Anfang der letzten Zeile und ohne eine Referenz in die Irre führen könnte. Als Referenz müsste bei dmesg noch die erste Zeile hinzugezogen werden. Die erste Zeile würde sogar ganz allein ausreichen, also ohne die letzte Zeile, da in der ersten Zeile explizit die Systemstartzeit vermerkt ist. Weil die erste Zeile ein ganz bestimmtes Datenmuster hat und weil der Inhalt dieser Zeile bis auf die Systemstartzeit im Wesentlichen konstant ist/bleibt, kann die Systemstartzeit daraus durchaus sicher extrahiert werden.
Der Vorteil dieses Ansatzes gegenüber dem von @117471 ist, dass keine Datei / Daten auf den Datenträger geschrieben werden muss / müssen, um die Laufzeit zu ermitteln. Das kann gerade bei einem Raspberry Pi (oder dergleichen), der mit einer SD-Card läuft, sinnvoll und / oder vorzugswürdig sein.
Einen schönen Samstagabend
HansDampf06
Hallo,
der Vorteil meiner Methode: Sie ist kürzer als die Erklärung deiner Vorgehensweise
Russentechnik - Keep it simple, stupid
Gruß,
Jörg
der Vorteil meiner Methode: Sie ist kürzer als die Erklärung deiner Vorgehensweise
Russentechnik - Keep it simple, stupid
Gruß,
Jörg
Zitat von @117471:
der Vorteil meiner Methode: Sie ist kürzer als die Erklärung deiner Vorgehensweise
Russentechnik - Keep it simple, stupid
der Vorteil meiner Methode: Sie ist kürzer als die Erklärung deiner Vorgehensweise
Russentechnik - Keep it simple, stupid
Aaah jaaa! Ich gehe davon aus, dass das in sachlicher Hinsicht ernst gemeint ist. Mithin bietet es sich an, das doch näher zu untersuchen.
Fangen wir zunächst mit dem Ansatz an, die Frage, ob der Einzelrechner soeben erst gestartet wurde oder schon länger am Werkeln ist, mittels der Auswertung des Befehls dmesg zu beantworten. Wie bereits ausgeführt liefert allein die erste Zeile der von diesem Befehl zurückgegebenen Ausgabe die benötigte Information. Wollen wir hierbei annehmen, die erste Zeile könnte wie folgt lauten:
[ 0.000000] Linux version 5.4.0-72-generic (buildd@lcy01-amd64-019) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 (Ubuntu 5.4.0-72.80-generic 5.4.101)
Dann würden Deinem Script /root/scripte/at_night.sh drei Zeilen hinzugefügt und eine Zeile angepasst werden müssen, und zwar marginal so:
DMESGZ1=$(dmesg | sed -n '1 p' | cut -c 138-165)
stunde=$(date -d "$DMESGZ1" +"%-H")
minute=$(date -d "$DMESGZ1" +"%M")
if [ $stunde -eq 1 ] && [ $minute -ge 15 -a $minute -le 35 ]; thenDas Ergebnis für stunde und minute wären 19 und 35 bei der vorstehend angenommenen ersten Zeile - Passt!
Wird darüber hinaus noch etwas für die volle Funktionstüchtigkeit des Ansatzes mit dmesg benötigt? Ganz offensichtlich nicht! Funktioniert wegen des wohl immer vorinstallierten Pakets util-linux sogar out-of-the-box und das obendrein auf jeder x-beliebigen Linux-Maschine/-Device.
Wie sieht es demgegenüber bei Deinem originalen Script /root/scripte/at_night.sh aus? Es fehlen noch: die Installation des Startservices für Dein zusätzliches WOL-Script /root/scripte/wol_check.sh und die Ausführung des WOL-Scripts (= mindestens ein Neustart erforderlich) nebst dem Schreiben der Datei /tmp/wol_yes. Und dann bleiben da noch zwei brennende Fragen:
1. Kann der Startservice auf jedem Linux-Device realisiert werden? Zumindest ist es fraglich. Out-of-the Box ist es jedenfalls nicht!
2. Wie ist es eigentlich um sicherheitskritische Aspekte bestellt, wenn Daten nicht nur gelesen, sondern auch noch geschrieben werden müssen? Gilt nicht der Grundsatz, alles, was zusätzlich hinzugefügt werden muss, erhöht die Komplexität und somit die Fehleranfälligkeit?
Ähm ... Russentechnik ... Also wenn Du mich fragst ... Ich bin ganz bei Dir: KEEP IT SIMPLE, STUPID!
Gute Nacht
HansDampf06
Übrigens wurde bisher noch nicht erörtert, dass das Konzept derzeit zwei nicht unwesentliche Schwächen hat.
1. Schwäche:
Die auf die Tageszeit (Stunde und Minute) begrenzte Auswertung des Systemstarts ist nicht in jeder Hinsicht tauglich, eine sichere Entscheidung über das Herunterfahren im Anschluss an die nächtliche Aufgabe zu treffen. So ist es denkbar, dass der Einzelrechner zwar in der fraglichen (Tages)Zeit zwischen 1:15 Uhr und 1:40 Uhr gestartet wurde, aber schon seit 24 Stunden oder länger läuft und möglicherweise auch noch weiterhin laufen soll/muss. Indes kann diese Schwäche sehr leicht beseitigt werden, indem das Script /root/scripte/at_night.sh wie folgt abgeändert wird:
Wird auf die Auswertung der Tageszeit verzichtet, kann das Script insoweit abstrahiert / dynamisiert werden, dass ein Neustart des Einzelrechners in dem Zeitfenster 5 bis 25 Minuten vor dem Start des Scripts erfolgte. Dann muss bei einer Änderung der Startzeit in crontab nicht auch noch das Script angepasst werden.
2. Schwäche:
Der Einzelrechner ist nicht in der Lage zu erkennen, ob es sich um einen WOL-Start oder einen anderweitigen Start handelt, wenn er in das fragliche Zeitfenster fällt. Eine solche Informationen wird schlichtweg nicht überliefert. Selbst die Ausgabe des Befehls dmesg beinhaltet keine dahingehenden Daten, soweit ich das überblicke.
Konzeptionell könnte eine solche Information nur dann verwendet werden, wenn der Initiator des WOL-Befehls dessen Ausführungszeitpunkt und / oder den vom Initiator zuvor ermittelten Status des Einzelrechners übermittelt. Das müsste dann in der Konsequenz wohl dazu führen, dass der Initiator zugleich das Script /root/scripte/at_night.sh startet oder die zu übermittelnde Information irgendwo abrufbereit ablegt, so dass das Script darauf zugreifen kann.
Aller Voraussicht nach müsste dann ein "echter" Rechner als Initiator verwendet werden.
Einen schönen Sonntag
HansDampf06
1. Schwäche:
Die auf die Tageszeit (Stunde und Minute) begrenzte Auswertung des Systemstarts ist nicht in jeder Hinsicht tauglich, eine sichere Entscheidung über das Herunterfahren im Anschluss an die nächtliche Aufgabe zu treffen. So ist es denkbar, dass der Einzelrechner zwar in der fraglichen (Tages)Zeit zwischen 1:15 Uhr und 1:40 Uhr gestartet wurde, aber schon seit 24 Stunden oder länger läuft und möglicherweise auch noch weiterhin laufen soll/muss. Indes kann diese Schwäche sehr leicht beseitigt werden, indem das Script /root/scripte/at_night.sh wie folgt abgeändert wird:
DMESGZ1=$(dmesg | sed -n '1 p' | cut -c 138-165)
stunde=$(date -d "$DMESGZ1" +"%-H")
minute=$(date -d "$DMESGZ1" +"%M")
TSTARTUP=$(date -d "$DMESGZ1" +"%s")
TNOW=$(date +"%s")
TDIFF=$(($TNOW-$TSTARTUP))
if [ $stunde -eq 1 ] && [ $minute -ge 15 -a $minute -le 35 ]
then
if [ $TDIFF -le 1500 ] && [ $TDIFF -ge 300 ]
then
date | mailx -s "$HOST WOL Start, Rechner wird heruntergefahren" meine@email.adresse
sleep 60
/usr/sbin/shutdown -h now
else
date | mailx -s "$HOST lief bereits und bleibt eingeschaltet" meine@email.adresse
fi
else
echo "Start erfolgte außerhalb des WOL-Zeitfensters"
fiWird auf die Auswertung der Tageszeit verzichtet, kann das Script insoweit abstrahiert / dynamisiert werden, dass ein Neustart des Einzelrechners in dem Zeitfenster 5 bis 25 Minuten vor dem Start des Scripts erfolgte. Dann muss bei einer Änderung der Startzeit in crontab nicht auch noch das Script angepasst werden.
2. Schwäche:
Der Einzelrechner ist nicht in der Lage zu erkennen, ob es sich um einen WOL-Start oder einen anderweitigen Start handelt, wenn er in das fragliche Zeitfenster fällt. Eine solche Informationen wird schlichtweg nicht überliefert. Selbst die Ausgabe des Befehls dmesg beinhaltet keine dahingehenden Daten, soweit ich das überblicke.
Konzeptionell könnte eine solche Information nur dann verwendet werden, wenn der Initiator des WOL-Befehls dessen Ausführungszeitpunkt und / oder den vom Initiator zuvor ermittelten Status des Einzelrechners übermittelt. Das müsste dann in der Konsequenz wohl dazu führen, dass der Initiator zugleich das Script /root/scripte/at_night.sh startet oder die zu übermittelnde Information irgendwo abrufbereit ablegt, so dass das Script darauf zugreifen kann.
Aller Voraussicht nach müsste dann ein "echter" Rechner als Initiator verwendet werden.
Einen schönen Sonntag
HansDampf06
Hallo,
Nein. Einen Rechner, der bereits seit 24 läuft, kann man nicht ein zweites Mal starten
Ich habe das Zeitfenster mit 30 Minuten relativ großzügig gewählt. Je nach Größe des Zeitfensters und der Uhrzeit sinkt die Wahrscheinlichkeit jedoch signifikant. Wenn man das an die realen Umgebungen anpasst, kann man einen unbeabsichtigten Nebeneffekt nahezu ausschließen.
Du verhaspelst dich gerade "ziemlich" und denkst wie gesagt viel zu kompliziert. Was man übrigens auch an der Länge deiner Beiträge bemerkt
Wie gesagt: Russentechnik! Die Amerikaner forschen an Tinte, die auch in Schwerelosigkeit funktioniert. Und die Russen schießen einfach einen Bleistift in den Weltraum - finde den Fehler.
Man könnte natürlich auch die uptime auswerten; hätte dann aber nicht den "netten" Nebeneffekt, dass man die /tmp/wol_yes auch über andere Prozesse anlegen kann - z.B. im Anschluss an einen mehrtägigen cron-Job, wie ich es in meinem Blog beschrieben habe.
Gruß,
Jörg
Zitat von @HansDampf06:
So ist es denkbar, dass der Einzelrechner zwar in der fraglichen (Tages)Zeit zwischen 1:15 Uhr und 1:40 Uhr gestartet wurde, aber schon seit 24 Stunden oder länger läuft
So ist es denkbar, dass der Einzelrechner zwar in der fraglichen (Tages)Zeit zwischen 1:15 Uhr und 1:40 Uhr gestartet wurde, aber schon seit 24 Stunden oder länger läuft
Nein. Einen Rechner, der bereits seit 24 läuft, kann man nicht ein zweites Mal starten
Der Einzelrechner ist nicht in der Lage zu erkennen, ob es sich um einen WOL-Start oder einen anderweitigen Start handelt, wenn er in das fragliche Zeitfenster fällt.
Ich habe das Zeitfenster mit 30 Minuten relativ großzügig gewählt. Je nach Größe des Zeitfensters und der Uhrzeit sinkt die Wahrscheinlichkeit jedoch signifikant. Wenn man das an die realen Umgebungen anpasst, kann man einen unbeabsichtigten Nebeneffekt nahezu ausschließen.
Aller Voraussicht nach müsste dann ein "echter" Rechner als Initiator verwendet werden.
Du verhaspelst dich gerade "ziemlich" und denkst wie gesagt viel zu kompliziert. Was man übrigens auch an der Länge deiner Beiträge bemerkt
Wie gesagt: Russentechnik! Die Amerikaner forschen an Tinte, die auch in Schwerelosigkeit funktioniert. Und die Russen schießen einfach einen Bleistift in den Weltraum - finde den Fehler.
Man könnte natürlich auch die uptime auswerten; hätte dann aber nicht den "netten" Nebeneffekt, dass man die /tmp/wol_yes auch über andere Prozesse anlegen kann - z.B. im Anschluss an einen mehrtägigen cron-Job, wie ich es in meinem Blog beschrieben habe.
Gruß,
Jörg
@HansDampf06
Warum wühlst du so aufwendig in der dmesg herum?
Die Uptime in Sekunden kann einfach aus /proc/uptime ausgelesen werden, ohne dass man parsen müsste.
Zumal du bei längerer Systemlaufzeit nicht zwingend die erste dmesg-Zeile erhältst, wenn diese zwischenzeitlich zu voll wurde.
Der Fehler ist das in der Schwerelosigkeit herumfliegende Graphen aus den Bleistiften, welches elektrisch leitet und in die Schaltkreise kommt.
Deshalb ist das zwar immer gerne genommen für solche Metaphern, aber schlicht nicht wahr
Warum wühlst du so aufwendig in der dmesg herum?
Die Uptime in Sekunden kann einfach aus /proc/uptime ausgelesen werden, ohne dass man parsen müsste.
Zumal du bei längerer Systemlaufzeit nicht zwingend die erste dmesg-Zeile erhältst, wenn diese zwischenzeitlich zu voll wurde.
Wie gesagt: Russentechnik! Die Amerikaner forschen an Tinte, die auch in Schwerelosigkeit funktioniert. Und die Russen schießen einfach einen Bleistift in den Weltraum - finde den Fehler.
Der Fehler ist das in der Schwerelosigkeit herumfliegende Graphen aus den Bleistiften, welches elektrisch leitet und in die Schaltkreise kommt.
Deshalb ist das zwar immer gerne genommen für solche Metaphern, aber schlicht nicht wahr
Zitat von @117471:
denkst wie gesagt viel zu kompliziert.
denkst wie gesagt viel zu kompliziert.
Kann sein, muss nicht sein. Was dem einen kompliziert erscheint, ist für einen anderen eben ein Blick ohne Scheuklappen und / oder über den Tellerrand hinaus ...
Was man übrigens auch an der Länge deiner Beiträge bemerkt
Dafür kann mir wenigstens niemand vorwerfen, meine Kommentare wären holzschnittartig "dahingerotzt". Aber das liegt im Auge des Betrachters ...
Man könnte natürlich auch die uptime auswerten; hätte dann aber nicht den "netten" Nebeneffekt, dass man die /tmp/wol_yes auch über andere Prozesse anlegen kann - z.B. im Anschluss an einen mehrtägigen cron-Job, wie ich es in meinem Blog beschrieben habe.
Ja und? Bleibe doch einfach bei Deinen eigenen Vorgaben: Auswertung, ob ein Einzelrechner per WOL-Befehl in einem bestimmten Zeitfenster gestartet wurde.
Wenn Du hingegen Dein Script im Anschluss an einen anderen mehrtägigen CronJobs ausführen willst, braucht es dennoch Deine /tmp/wol_yes nicht - jedenfalls nicht zwingend. Hier bist Du zu sehr auf Deinen bisherigen Lösungsentwurf fixiert und verstellst Dir den Blick auf Alternativen.
Das gilt auch und erst recht für die am Ende Deines verlinkten Blogbeitrags erwähnte Spielerei. Denn dann, wenn im Anschluss an einen (sehr lange dauernden) anderen Job der Einzelrechner heruntergefahren werden soll, ist nicht wirklich ersichtlich, dass es dazu des Umweges über Deine /tmp/wol_yes bedarf. Entweder wird der shutdown-Befehl direkt angehängt oder Du rufst Dein Script mittels eines Parameters auf. Wie gesagt: Keep it simple, stupid!
Nein. Einen Rechner, der bereits seit 24 läuft, kann man nicht ein zweites Mal starten
...
Ich habe das Zeitfenster mit 30 Minuten relativ großzügig gewählt. Je nach Größe des Zeitfensters und der Uhrzeit sinkt die Wahrscheinlichkeit jedoch signifikant. Wenn man das an die realen Umgebungen anpasst, kann man einen unbeabsichtigten Nebeneffekt nahezu ausschließen.
...
Ich habe das Zeitfenster mit 30 Minuten relativ großzügig gewählt. Je nach Größe des Zeitfensters und der Uhrzeit sinkt die Wahrscheinlichkeit jedoch signifikant. Wenn man das an die realen Umgebungen anpasst, kann man einen unbeabsichtigten Nebeneffekt nahezu ausschließen.
Bist Du Dir da wirklich sicher, insbesondere wegen des "sehr" großzügigen Zeitfensters? Was ist beispielsweise, wenn das WOL-Signal zum Anfang des Zeitfensters den ersten Start auslöst und wenn danach während des großzügigen Zeitfensters ein außenliegendes Ereignis (z.B von der USV kommend) den Einzelrechner zum rechtzeitigen Neustart veranlasst, wobei wegen dieses Ereignisses nach einem dadurch ausgelösten Neustart länger dauernde Aufgaben zu erledigen sind?
Eine solche Konstellation magst Du zwar für Deinen Einzelrechner-Fall ausschließen können/wollen. Dennoch kann dieses nicht völlig fernliegende Szenario für andere durchaus beachtenswert sein, wenn sie Deinem bisherigen Lösungsentwurf nähertreten wollen. Oder?
Wie gesagt: Russentechnik! Die Amerikaner forschen an Tinte, die auch in Schwerelosigkeit funktioniert. Und die Russen schießen einfach einen Bleistift in den Weltraum - finde den Fehler.
Dann nimm doch den "Bleistift" und klammere Dich nicht an Deine "Tinte".
Viele Grüße
HansDampf06
Zitat von @LordGurke:
Die Uptime in Sekunden kann einfach aus /proc/uptime ausgelesen werden, ohne dass man parsen müsste.
Zumal du bei längerer Systemlaufzeit nicht zwingend die erste dmesg-Zeile erhältst, wenn diese zwischenzeitlich zu voll wurde.
Die Uptime in Sekunden kann einfach aus /proc/uptime ausgelesen werden, ohne dass man parsen müsste.
Zumal du bei längerer Systemlaufzeit nicht zwingend die erste dmesg-Zeile erhältst, wenn diese zwischenzeitlich zu voll wurde.
Stimmt! Dadurch wird es noch einfacher und schneller.
Viele Grüße
HansDampf06
PS:
Ganz ohne "parsen" wird es dabei leider doch nicht gehen, weil - bei Ubuntu, CentOS und mindestens einem Linux-Device - in der Datei /proc/uptime zwei Werte stehen. Nur der erste der beiden Werte ist der für unsere Diskussion relevante uptime-Wert.
