(gelöst) at, Job-Zeitpunkt

[fischig]

If you specify a job to absolutely run at a specific time and date in the past, the job will run as soon as possible

Daraus leite ich ab: Wenn der Rechner vor dem Ausführen eines Jobs ausgeschaltet wurde, wird der Job nach dem Wiedereinschalten des Rechners trotzdem ausgeführt, auch wenn der Rechner erst nach dem Job-Zeitpunkt wieder eingeschaltet wurde.

Wenn das zutrifft: Kann man das verhindern? Sprich: kann ich einstellen, dass ein Job nicht später als zum angegebenen Job-Zeitpunkt ausgeführt wird?

[JTH]

Nimm stattdessen einfach systemd-run. Jobs die damit angelegt werden, sind ausschließlich temporär, überstehen keinen Reboot. (Konnte nicht wiederstehen, systemd einzuwerfen )

Wenn das zutrifft: Kann man das verhindern? Sprich: kann ich einstellen, dass ein Job nicht später als zum angegebenen Job-Zeitpunkt ausgeführt wird?

Ja, interpretiere ich genauso wie du. Und nein, einen eingebauten Weg, dein Ziel zu erreichen, scheint es nicht zu geben. Mit nem kleinen Skript ließe sich das aber bestimmt leicht erreichen.

[DeletedUserReAsG]

Nimm stattdessen einfach systemd-run. Jobs die damit angelegt werden, sind ausschließlich temporär, überstehen keinen Reboot. (Konnte nicht wiederstehen, systemd einzuwerfen )

Entgegen der Smileys eine absolut vernünftige Empfehlung. Man mag dieses Initsystem sehen, wie man möchte – für einen Anwender erleichtert es Vieles nunmal enorm, und macht andere Sachen überhaupt erst möglich. Dazu kommt das im Großen und Ganzen konsistente Bedienschema über die verschiedenen Komponenten hinweg, das auch erheblich Komplexität rausnimmt.
Nicht zu vergessen ist auch die Masse an Doku und Unterstützung, nachdem das System nun seit einigen Jahren das Standardsystem der meisten Distributionen ist, und sich in geschätzt über 95% der Linuxinstallationen wiederfindet.

[JTH]

Entgegen der Smileys eine absolut vernünftige Empfehlung. Man mag dieses Initsystem sehen, wie man möchte – für einen Anwender erleichtert es Vieles nunmal enorm, und ermöglicht andere Sachen überhaupt erst.

Jo, seh ich auch so. Da fischig aber, meine ich, systemd-frei arbeitet, war mein Einwurf hier wahrscheinlich nicht zielführend – deshalb die Smileys.

[Meillo]

Da fischig aber, meine ich, systemd-frei arbeitet, war mein Einwurf hier wahrscheinlich nicht zielführend – deshalb die Smileys.

Ja.


Als Loesungsidee: Cron fuehrt verpasste Jobs nicht nachtraeglich aus. Du koenntest also einen generischen Cronjob einrichten, der in einem fixen Intervall laeuft und dieser prueft, ob die Zeit passt und fuehrt dann das Script aus. D.h. letztlich wuerdest du ein at nachbauen, bloss halt in der Weise, wie du es gerne haettest. Ich denke, das koennte man mit zwei Dutzend Zeilen Shellscript loesen. (Ob's was fertiges gibt, weiss ich nicht.)

[TRex]

Ja, nur wollte fischig das Gegenteil bewirken

[DeletedUserReAsG]

Als Loesungsidee: Cron fuehrt verpasste Jobs nicht nachtraeglich aus.

Aufpassen: wenn etwa anacron den Job auf der betreffenden Kiste tut, kann’s so Sachen tatsächlich wieder nachträglich ausführen.

Ansonsten: einfache Variante wäre ein popeliges Script, das die Zeit und den Job mitgegeben bekommt und dann in den Hintergrund geschickt wird. Das ist nach dem Reboot auf jeden Fall nicht mehr im RAM.
Bei heutigen Rechnern könnte man es gar Q&D machen, ohne sich um die verschwendeten Ressourcen groß Gedanken machen zu müssen: beim Aufruf errechnet es sich Differenz zwischen Ausführungszeitpunkt und Zielzeit, und legt sich dann mit einem sleep [errechneter Wert] schlafen.

[fischig]

Ich arbeite nicht ganz systemd-frei. Auf einer Maschine läuft es. Mal sehen, ob ich's da umsetze. Dummerweise betrifft mein konkreter at-Befehl den Shutdown. Und den setzt systemd seit geraumer Zeit auf dieser Maschine nicht zuverlässig um. Aus

Code: Alles auswählen

shutown -h now

(ich weiß, sollte man systemd-like anders machen) macht es gelegentlich, nicht immer, das, was

Code: Alles auswählen

shutdown -r now

tun sollte. Deswegen führe ich aus Faulheit diesen shutdown via at mehrfach durch, da ich nachts um drei weder Lust habe, nachzugucken, ob die Maschine nun tatsächlich aus ist, noch, zu ergründen, warum systemd den shutdown auf der Maschine als reboot verstanden hat. Ich versuche einstweilen andere Möglichkeiten. Wenn's mir zu lästig wird, komme ich auf euren Vorschlag (systemd-run) zurück. Danke!

[DeletedUserReAsG]

Code: Alles auswählen

shutown -h now

Du weißt aber schon, dass du das „now“ durch eine Zeit ersetzen kannst?

Edit:

warum systemd den shutdown auf der Maschine als reboot verstanden hat.

Vermutlich hat’s eher mit ACPI und so zu tun. Du solltest vielleicht nicht all deine Probleme auf systemd projizieren …

2. Edit:

Deswegen führe ich aus Faulheit diesen shutdown via at mehrfach durch, da ich nachts um drei weder Lust habe, nachzugucken, ob die Maschine nun tatsächlich aus ist, noch, zu ergründen, warum systemd den shutdown auf der Maschine als reboot verstanden hat.

Du möchtest also, dass das shutdown solange geschickt wird, bis die Kiste tatsächlich aus bleibt. Gleichzeitig möchtest du nicht, dass das shutdown wieder geschickt wird, sobald du die Kiste selbst angeschaltet hast – so richtig erfasst?

Denn in dem Fall stehst du vor dem Problem, feststellen zu müssen, ob die Kiste nun aufgrund des Fehlers wieder gestartet worden ist, oder aufgrund des Drucks auf den Power-Button – und das ist die Stelle, wo’s schwierig wird. Eigentlich gar unmöglich.

Ich würde nun zunächst im BIOS/EFI-Setup schauen: gibt es da die Option „restart on power loss“ oder ähnliche, auch mit der sinngemäßen Aussage, den alten Zustand nach einem Stromverlust wiederherzustellen? Solche Sachen waren schon erstaunlich oft die Ursache für einen Restart nach dem Shutdown …
Wobei – eigentlich wolltest du ja den Fehler nicht suchen. Sorry für den Einwurf o/

[Meillo]

Ja, nur wollte fischig das Gegenteil bewirken

Wie jetzt?

Er will doch, dass ein verpasster Zeitpunkt *nicht* nachgeholt wird. At holt ihn aber nach.

Bei Cron dagegen werden verpasste Ausfuehrungen uebersprungen. Wenn man nun mit Cron jede Minute ein Script startet, das prueft, ob es in der passenden Minute ist, um den Job auszufuehren, dann wird dieses ihn nur dann ausfuehren, wenn der Rechner in der Minute auch laeuft.

Als Loesungsidee: Cron fuehrt verpasste Jobs nicht nachtraeglich aus.

Aufpassen: wenn etwa anacron den Job auf der betreffenden Kiste tut, kann’s so Sachen tatsächlich wieder nachträglich ausführen.

Richtig, Anacron gibt's ja gerade deshalb, weil Cron verpasste Zeiten einfach auslaesst. Anacron verhaelt sich also so wie At, das standardmaessig tut. Man darf also keinen Anacron als Cron einsetzen.

Ansonsten: einfache Variante wäre ein popeliges Script, das die Zeit und den Job mitgegeben bekommt und dann in den Hintergrund geschickt wird. Das ist nach dem Reboot auf jeden Fall nicht mehr im RAM.

Mein Ansatz wuerde auch ueber Reboots hinweg funktionieren. Es kommt halt darauf an, wie die Anwendungsfaelle bei fischig sind. Da koennen wir nur raten.


(Edit: Nachdem hier schneller gepostet wird, als ich meine Beitraege schreiben kann, gehe ich jetzt nicht auch noch auf die letzten Posts ein, weil ich sonst womoeglich in einer Endlosschleife gefangen bin. )

[fischig]

Du solltest vielleicht nicht all deine Probleme auf systemd projizieren …

Hab' ich gar nicht gemacht. Ich sagte nur, dass ich im konkreten Fall keine Lust verspüre, es zu untersuchen.

@all
Da habe ich ja einige Spielmöglichkeiten!

[DeletedUserReAsG]

Ich sagte nur, dass ich im konkreten Fall keine Lust verspüre, es zu untersuchen.

da ich nachts um drei weder Lust habe, nachzugucken, ob die Maschine nun tatsächlich aus ist, noch, zu ergründen, warum systemd den shutdown auf der Maschine als reboot verstanden hat.

Keine Lust zu gucken woran es überhaupt liegt, aber systemd steht schonmal als Ursache fest – das war der Punkt, auf den ich mit dieser kleinen Spitze hinauswollte.

[JTH]

Mit nem kleinen Skript ließe sich das aber bestimmt leicht erreichen.

Ja, ließe sich

Da habe ich ja einige Spielmöglichkeiten!

Ich hab da noch eine: Das ganze abgespeichert nach /usr/local/bin/tempat, ein chmod +x /usr/local/bin/tempat hinterher und viel Spaß damit:

Code: Alles auswählen

#!/bin/sh
set -eu

runfile=$(mktemp /run/tempat.XXXXXXXXXX)
[ ! -t 0 ] || printf "tempat> "
read -r cmd
printf "%s" "rm '$runfile' >/dev/null 2>&1 || exit; $cmd" | at "$@"

Setzt voraus, dass /run ein tmpfs ist, was normalerweise der Fall ist.

[Meillo]

Da wir nun wissen, dass es nur um einen Shutdown zu einer bestimmten Zeit in der Zukunft geht, koennen wir uns das ganze At/Cron-Zeug komplett sparen, und, wie niemand schon angemerkt hat, ganz einfach `shutdown' direkt die gewuenschte Zeit mitgeben. So einfach loest man selten Probleme.

[fischig]

Ach niemand, nun lass doch mal die Kirche im Dorf! Ich wollte etwas zu at wissen und nicht zu systemd.

Und dass auf systemd-Systemen nun mal systemd das Ausschalten regelt/regeln soll, ist doch wohl unumstritten. dass bei meinen nebenbei erwähnten Unregelmäßigkeiten außer systemd noch etwas anderes eine Rolle spielen mag, will ich doch gar nicht bestreiten.

[DeletedUserReAsG]

Ach niemand, nun lass doch mal die Kirche im Dorf!

Du bist doch auf die nebenläufige Bemerkung angesprungen, statt auf die relevante Nachfrage zur Klarstellung des Szenarios einzugehen:

Du möchtest also, dass das shutdown solange geschickt wird, bis die Kiste tatsächlich aus bleibt. Gleichzeitig möchtest du nicht, dass das shutdown wieder geschickt wird, sobald du die Kiste selbst angeschaltet hast – so richtig erfasst?

[fischig]

Du möchtest also, dass das shutdown solange geschickt wird, bis die Kiste tatsächlich aus bleibt.

Jain. Ich wollte den Rechner zu einem at mitgegebenen Zeitpunkt ausschalten. Und wenn das nicht funktioniert, ist mir bisher in meiner Schlichtheit dazu nur eingefallen, dass wenn er's beim ersten Mal nicht tut, dann vielleicht fünf Minuten später beim nächsten oder dritten Mal. Auf die Idee mit cron/Zeitschleife hat mich dieser Thread erst gebracht.

`shutdown' direkt die gewuenschte Zeit mitgeben. So einfach loest man selten Probleme.

Für mich ist das so einfach nicht, da meine (unzuverlässigen) shutdowns gescriptet sind und da bot sich „now“ an. Wie ich die scripte nun sinnvoll ändern kann, darüber muss ich nachdenken. Aber ohne Frage: wenn ich ohne Ursachenklärung für die Unzuverlässigkeiten/Scriptänderungen weitermache, kann ich im hilfsweise benutzten at-Kommando now durch die konkrete Zeit ersetzen.

[DeletedUserReAsG]

Ich wollte den Rechner zu einem at mitgegebenen Zeitpunkt ausschalten. Und wenn das nicht funktioniert, ist mir bisher in meiner Schlichtheit dazu nur eingefallen, dass wenn er's beim ersten Mal nicht tut, dann vielleicht fünf Minuten später beim nächsten oder dritten Mal.

Wenn’s wirklich so schnell und schmutzig gelöst werden soll: Startscript schreiben, das beim Start schaut, ob die Kiste länger als fünf Minuten aus war, und wenn nicht, direkt wieder runterfährt.

Das fällt dir dann beim nächsten gewollten Start kurz nach dem Abschalten auf die Füße, indem’s die Kiste gleich wieder runterfährt, und wird dich so dran erinnern, dass vielleicht doch mal lieber nach der Ursache geschaut, und diese beseitigt werden sollte

[Meillo]

`shutdown' direkt die gewuenschte Zeit mitgeben. So einfach loest man selten Probleme.

Für mich ist das so einfach nicht, da meine (unzuverlässigen) shutdowns gescriptet sind und da bot sich „now“ an. Wie ich die scripte nun sinnvoll ändern kann, darüber muss ich nachdenken. Aber ohne Frage: wenn ich ohne Ursachenklärung für die Unzuverlässigkeiten/Scriptänderungen weitermache, kann ich im hilfsweise benutzten at-Kommando now durch die konkrete Zeit ersetzen.

Das verstehe ich nicht.

Ob du nun `at 01:00' mit dem Befehl `shutdown -h now' oder gleich `shutdown -h 01:00' aufrufst -- wo ist da der Unterschied?

Mit welchem Argument rufst du denn `at' ganz konkret auf?

Wenn der Shutdown gegebenenfalls unzuverlaessig ist (und du einen schnellen Fix suchst, bevor du dieses Problem richtig loest), dann kannst du ja auch einfach mehrmals shutdown queuen:

Code: Alles auswählen

shutdown -h 01:00
shutdown -h 01:10
shutdown -h 01:20

(Bzw. vielleicht besser `shutdown -P' verwenden, damit er auch wirklich ausschaltet.)

[fischig]

Ob du nun `at 01:00' mit dem Befehl `shutdown -h now' oder gleich `shutdown -h 01:00' aufrufst -- wo ist da der Unterschied?

Da gibt's keinen.

Aber eigentlich will ich ein script ausführen, an dassen Ende ein script ausgeführt wird, das

Code: Alles auswählen

shutdown -h now

ausführt. Das at-shutdown gab's nur, weil dieses Konstrukt in letzter Zeit nicht regelmäßig funktionierte, sprich den Rechner gelegentlich rebootete statt ihn auszuschalten.

at war 'ne Krücke. Wie ich die verbessere, weiß ich jetzt. Ich denk' jetzt erst mal drüber nach, wie ich die Krücke überflüssig mache - zunächst mal ohne systemd-run.

[tobo]

Er will doch, dass ein verpasster Zeitpunkt *nicht* nachgeholt wird. At holt ihn aber nach.

Bei Cron dagegen werden verpasste Ausfuehrungen uebersprungen. Wenn man nun mit Cron jede Minute ein Script startet, das prueft, ob es in der passenden Minute ist, um den Job auszufuehren, dann wird dieses ihn nur dann ausfuehren, wenn der Rechner in der Minute auch laeuft.

Der letzte Teilsatz ist eine wichtige Einschränkung, denn durch ein Suspend verpasster Job wird sehr wohl nachgeholt.

[fischig]

systemd-run wird's wohl werden. Ich kann das Kommando in einem script ausführen lassen? Zur Ursachenforschung ins BIOS/EFI komme ich z.Z. nicht. Der Rechner meldet sich beim Hochfahren als erstes als „Asrock“. Ich kenne die Tastenkombination nicht und ich habe z.Z. eine Scheiß-BT-Tastatur, die verzögert reagiert, habe auch keine Unterlagen zur Maschine mehr, von esc, del und f1-6,f12 alles durchprobiert.

[fischig]

Der Hinweis Meillos auf den Parameter -P beim shutdown-Kommando war wohl der zielführende. Ich benutze nach wie vor at.Wenn ich den Zeitpunkt, an dem ich ausgeschaltet haben möchte kenne, lasse ich zu diesem Zeitpunkt via sudo

Code: Alles auswählen

/sbin/shutdown -Ph now

ausführen. Kenne ich ihn nicht, dann läuft dieses script:

Code: Alles auswählen

[mein zeitaufwendiger Job]
auszeit=$(date -d "90 sec" +"%H:""%M")
sleep 10
aus2 "$auszeit"

aus2:

Code: Alles auswählen

sudo /sbin/shutdown -Ph $@

Bisher kein unerwünschtes Neustarten des Rechners mehr bemerkt.
Um systemd-run zu verwenden, müsste ich wohl entsprechende units schreiben.

Zugang zum BIOS funktioniert jetzt mit neuer Funk-Tastatur. Ich habe bisher nichts mir relevant Erscheinendes entdeckt.