(gelöst) at, Job-Zeitpunkt

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Antworten
fischig
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

(gelöst) at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 09:02:42

man at hat geschrieben: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?
Zuletzt geändert von fischig am 20.11.2022 22:23:31, insgesamt 1-mal geändert.

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: at, Job-Zeitpunkt

Beitrag von JTH » 25.10.2022 09:26:21

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

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:02:42
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.
Manchmal bekannt als Just (another) Terminal Hacker.

DeletedUserReAsG

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 09:40:38

JTH hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:26:21
Nimm stattdessen einfach systemd-run. Jobs die damit angelegt werden, sind ausschließlich temporär, überstehen keinen Reboot. (Konnte nicht wiederstehen, systemd einzuwerfen :twisted: :wink: )
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.
Zuletzt geändert von DeletedUserReAsG am 25.10.2022 09:44:32, insgesamt 1-mal geändert.

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: at, Job-Zeitpunkt

Beitrag von JTH » 25.10.2022 09:43:56

niemand hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:40:38
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.
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: at, Job-Zeitpunkt

Beitrag von Meillo » 25.10.2022 09:56:53

JTH hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:43:56
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.)
Use ed once in a while!

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: at, Job-Zeitpunkt

Beitrag von TRex » 25.10.2022 10:02:50

Ja, nur wollte fischig das Gegenteil bewirken :D
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

DeletedUserReAsG

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 10:05:26

Meillo hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:56:53
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.
Zuletzt geändert von DeletedUserReAsG am 25.10.2022 10:09:54, insgesamt 1-mal geändert.

fischig
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 10:09:50

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

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 10:11:04

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:09:50

Code: Alles auswählen

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

Edit:
fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:09:50
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:
fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:09:50
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/
Zuletzt geändert von DeletedUserReAsG am 25.10.2022 10:22:01, insgesamt 3-mal geändert.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: at, Job-Zeitpunkt

Beitrag von Meillo » 25.10.2022 10:12:37

TRex hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:02:50
Ja, nur wollte fischig das Gegenteil bewirken :D
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.

niemand hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:05:26
Meillo hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:56:53
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.
niemand hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:05:26
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. ;-) )
Use ed once in a while!

fischig
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 10:21:40

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! :wink:

DeletedUserReAsG

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 10:26:10

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:21:40
Ich sagte nur, dass ich im konkreten Fall keine Lust verspüre, es zu untersuchen.
fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:09:50
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.
Zuletzt geändert von DeletedUserReAsG am 25.10.2022 10:28:54, insgesamt 1-mal geändert.

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: at, Job-Zeitpunkt

Beitrag von JTH » 25.10.2022 10:28:38

JTH hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 09:26:21
Mit nem kleinen Skript ließe sich das aber bestimmt leicht erreichen.
Ja, ließe sich :)
fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:21:40
Da habe ich ja einige Spielmöglichkeiten! :wink:
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.
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: at, Job-Zeitpunkt

Beitrag von Meillo » 25.10.2022 10:31:20

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. :-D
Use ed once in a while!

fischig
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 10:33:29

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

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 10:36:19

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:33:29
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:
niemand hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:11:04
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
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 11:05:35

niemand hat geschrieben: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.
Meillo hat geschrieben:`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

Re: at, Job-Zeitpunkt

Beitrag von DeletedUserReAsG » 25.10.2022 11:12:37

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 11:05:35
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 :mrgreen:

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: at, Job-Zeitpunkt

Beitrag von Meillo » 25.10.2022 11:14:02

fischig hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 11:05:35
Meillo hat geschrieben:`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.)
Use ed once in a while!

fischig
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 25.10.2022 11:27:23

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. :wink:

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. :wink: 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. :wink:

tobo
Beiträge: 1964
Registriert: 10.12.2008 10:51:41

Re: at, Job-Zeitpunkt

Beitrag von tobo » 25.10.2022 12:02:31

Meillo hat geschrieben: ↑ zum Beitrag ↑
25.10.2022 10:12:37
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
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 29.10.2022 12:21:36

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
Beiträge: 3601
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: at, Job-Zeitpunkt

Beitrag von fischig » 20.11.2022 22:22:04

Der Hinweis Meillos auf den Parameter -P beim shutdown-Kommando war wohl der zielführende. Ich benutze nach wie vor Debianat.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.

Antworten