Wenn ich keinen triftigen Grund finde, es nicht zu tun, baue ich es ein.
- vdr-addon-lifeguard
- vdr-addon-acpiwakeup
Ich habe mir jeweils eine Alternative dazu geschrieben, die als Daemon läuft und damit allen Programmen zur Verfügung steht, die Aufwachzeitpunkte setzen (XBMC kann das ja mittlerweile auch über die PVR-Addons und ein Hilfsskript) oder eine Shutdown-Abfrage nutzen wollen:
https://github.com/seahawk1986/arch-lifeguard-ng
https://github.com/seahawk1986/arch-acpiwakeup-ng
Bis auf afp-Freigaben sollte der Funktionsumfang ähnlich zu den beiden vdr-addons sein, man braucht aber je nach Konfiguration für den Zugriff auf das dbus-Interface nicht zwingend root-Rechte um es zu nutzen.
Auf meiner TODO-Liste steht noch eine Status-Auswertung des VDR, damit automatisch ein systemd-Shutdown-Inhibitor gesetzt wird, wenn eine Aufnahme läuft oder ein Plugin eine wichtige Aktion durchführt, die nicht unterbrochen werden soll.
lifeguard-ng:
Naja, wenn schon Daemon, würde ich fast bevorzugen, dass es nur auf systemd-inhibit setzt.
Als Daemon gesetzte Inhibits (also außerhalb einer validen Session) gelten, soweit ich mich erinnere, für alle Programme.
Also vollkommen unabhängig vom VDR und dessen shutdown.sh
acpiwakeup-ng:
Im Grunde genommen setzt der VDR ja schon seine eigenen Aufwachzeiten über die shutdown.sh.
Ich versuche schon seit längerem den shutdown-wrapper loszuwerden und direkt im Service File den Timer zu setzen.
Da das nicht ohne weiteres zu funktionieren scheint und die runvdr-extreme auch schon etwas in die Jahre gekommen ist, wollte ich die sowieso etwas umschreiben
XBMC betrifft mich eher weniger, da sollten sich der entsprechende Paketmaintainer drum kümmern.
Alle beiden Addons klingen interessant, ich möchte aber im Sinne des "Arch Way", den VDR nicht von einem anderen Daemon abhängig machen.
Naja, wenn schon Daemon, würde ich fast bevorzugen, dass es nur auf systemd-inhibit setzt.
Ich prinzipiell auch, aber die einzige Lösung die mir in den Sinn gekommen ist und die nicht dauernd alle Kriterien durch polling überprüft wäre ein non-blocking Shutdown-Inhibitor, der dann ggf. einen blocking Shutdown inhibitor triggert - wobei ich noch nicht ausprobiert habe, ob das in der Praxis so funktionieren kann und dann noch das Problem bleibt, dass man den blocking Shutdown-Inhibitor wieder aufheben muss, damit der non-blocking Shutdown-Inhibitor erneut getriggert werden kann...
XBMC betrifft mich eher weniger, da sollten sich der entsprechende Paketmaintainer drum kümmern.
Alle beiden Addons klingen interessant, ich möchte aber im Sinne des "Arch Way", den VDR nicht von einem anderen Daemon abhängig machen.
Das will ich auch gar nicht für die vdr4arch-Pakete fordern. Die Freiheit des Users unter Arch Linux besteht ja unter anderem darin das System weitreichend eigenverantwortlich konfigurieren zu können, damit er möglichst das Verhalten bekommt, das er sich wünscht. Ist also eher ein bisschen wie "ich hab da mal was vorbereitet..." zu verstehen 
seahawk1986: Bekomme ich einen Pull-Request? 
Bei "lifeguard" wäre auch zu prüfen ob es ohne irgendwelche Abhängigkeiten auf VDR-Seite funktioniert. vdr-dbus-send funktioniert z.B. nicht ohne weitere Plugins. Hier gehört stattdessen ein "svdrpsend" hin, welches auch mit einem "plain VDR" funktioniert.
Davon abgesehen sieht das lifeguard-Script aber auf den ersten Blick garnicht so verkehrt aus. Vermutlich wäre das aber dann der richtige Zeitpunkt über eine möglichst schlanke Lösung für shutdown-hooks nachzudenken und diese in der shutdown.sh umzusetzen.
Auch du darfst gerne etwas beitragen. Im Gegensatz zu seahawk hast du sogar Push-Rechte.
Gesendet von meinem Galaxy Nexus mit Tapatalk 2
Bei "lifeguard" wäre auch zu prüfen ob es ohne irgendwelche Abhängigkeiten auf VDR-Seite funktioniert.
Aktuell gibt es da weder im vdr-addon-lifeguard noch in lifeguard-ng Abhängigkeiten zum VDR. Dem Vorbild des lifeguard-Addons folgend initiiert ja der VDR den Shutdown und im Shutdown-Skript wird nur zusätzlich auf andere Dienste/Abbruchbedingungen geschaut.
Hier gehört stattdessen ein "svdrpsend" hin, welches auch mit einem "plain VDR" funktioniert.
Dann halt so - auch wenn es langsamer und potentiell unzuverlässiger ist...
/usr/bin/svdrpsend mesg "$( echo "$ANSWER" | grep -o '\".*\"' )"Vermutlich wäre das aber dann der richtige Zeitpunkt über eine möglichst schlanke Lösung für shutdown-hooks nachzudenken und diese in der shutdown.sh umzusetzen.
Das kommt immer ein bisschen darauf an, wie man den VDR startet und ob man einen Shutdown-Wrapper nutzen will, der ein setuid(0) macht. Ich wollte da erst mal eine Lösung, die nicht auf die Verwendung mit dem VDR beschränkt ist und auch aus einer systemd-User Session des Users vdr heraus funktioniert.
Die smbstatus-Abfrage klappt z.B. nur als superuser/root, führt aber wohl mit einem reinen setuid(0) zu Problemen: Poweroff trotz SMB Lifeguard
Wie gesagt das ist mein Ansatz, der sich in den letzten Monaten auf meinem VDR gut bewährt hat, ich bin sicher dass ihr da noch auf eine schlankere Lösung kommt, die besser auf das Reinheitsgebot von vdr4arch zugeschnitten ist 
Ohh ja.
seahawk1986 vs. Mreimer
progressiv gegen konservativ
Wenn ihr das unter euch ausmachen würdet 
Mir ist das insgesamt egal. Hauptsache es wird nicht an den Depends des VDR gedreht.
Mal sehen, ich habe ja schon angesprochen, dass ich an der runvdr-extreme basteln möchte. Ich sehe da kein großes Problem, diese beim Stop auch acpiwakeup und lifeguard übernehmen zu lassen.
Die smbstatus-Abfrage klappt z.B. nur als superuser/root, führt aber wohl mit einem reinen setuid(0) zu Problemen: Poweroff trotz SMB Lifeguard
"Unser" Wrapper ist darauf vorbereitet:
https://github.com/CReimer/vdr…dr/shutdown-wrapper.c#L24
Und wenn das nicht reicht, dann erweitere ich den Wrapper gerne auch noch.
Und das hat garnichts mit "konservativ" zu tun. Ich bin nur froh, dass vdr4arch aktuell so übersichtlich ist und man, im Gegensatz zu so manch anderer Distribution, nicht wer weiß wieviele Verkettungen betrachten muss um einen VDR-Start oder gar einen sauberen VDR-Shutdown zu überblicken.
Zumindest ich sehe in vdr4arch eine Lösung die sich jeder selber so zusammenbaut, wie er gerne möchte. Schon weil es keine Distribution an sich ist sondern ein Angebot an Paketen. Aktuell sind die Abhängigkeiten zwischen den Komponenten noch sehr übersichtlich. So übersichtlich, dass sowohl Systeme mit als auch ohne X-Server ohne Probleme machbar sind. Und damit meine ich nicht nur Fullfeatured-Systeme sondern auch VDR-Server, welche ohne laufenden X-Server funktionieren sollten.
Rundum-Sorglos gibt es schon bei anderen Distributionen. Dort ist dann ein Paketsatz fest vorgegeben und vorgeschrieben. Wer etwas deinstalliert muss entweder wissen was er tut oder mit den Folgen leben.
Soll heißen: Für mich persönlich (sofern meine Meinung etwas zählt) spricht nichts gegen lifeguard, aber es muss auch möglich sein ihn wegzulassen ohne das dabei der VDR-Start oder -Shutdown irgendwie negativ beeinflusst wird.
Und im Shutdown-Script (das integraler Bestandteil eines lauffähigen VDR ist) sollte, wenn möglich, nur etwas stehen was ein Plain-VDR mitliefert. Eben damit auch ein VDR in Minimalkonfiguration möglich bleibt.
Wenn Interesse besteht schaue ich mir das Lifeguard-Addon gerne mal an. Meiner Ansicht nach muss dieses vor allem noch so erweitert werden, dass die ganzen dort verwendeten Tools OPTDEPENDS werden. Ich habe z.B. kein Samba auf dem VDR und werde es für lifeguard auch nicht installieren. Ohne Samba-Shares macht es auch keinen Sinn die nötigen Tools zu installieren um Zugriffe auf Samba zu ermitteln.
Und das hat garnichts mit "konservativ" zu tun. Ich bin nur froh, dass vdr4arch aktuell so übersichtlich ist und man, im Gegensatz zu so manch anderer Distribution, nicht wer weiß wieviele Verkettungen betrachten muss um einen VDR-Start oder gar einen sauberen VDR-Shutdown zu überblicken.
Ich sehe das genauso und will da auch nichts in den Paketen verkomplizieren (die runvdr-extreme ist eigentlich schon komplex genug und macht einem durch die starre Struktur einiges unnötig schwer).
Meiner Ansicht nach muss dieses vor allem noch so erweitert werden, dass die ganzen dort verwendeten Tools OPTDEPENDS werden. Ich habe z.B. kein Samba auf dem VDR und werde es für lifeguard auch nicht installieren. Ohne Samba-Shares macht es auch keinen Sinn die nötigen Tools zu installieren um Zugriffe auf Samba zu ermitteln.
Die optdepends habe ich eingetragen. Wenn man die Überprüfung von NFS und Samba in der Konfigurationsdatei nicht explizit aktiviert, werden die Abfragen gar nicht gemacht und damit werden showmount und smbstatus nicht genutzt.
Soll heißen: Für mich persönlich (sofern meine Meinung etwas zählt) spricht nichts gegen lifeguard, aber es muss auch möglich sein ihn wegzulassen ohne das dabei der VDR-Start oder -Shutdown irgendwie negativ beeinflusst wird.
Verstehe ich vollkommen, aktuell gibt es aber weder Shutdown-Hooks noch wird die shutdown.sh als Konfigurationsdatei bei einem Paketupdate geschützt, so dass es sowieso komplett am User hängen bleibt das den eigenen Bedürfnissen entsprechend anzupassen.
Und im Shutdown-Script (das integraler Bestandteil eines lauffähigen VDR ist) sollte, wenn möglich, nur etwas stehen was ein Plain-VDR mitliefert. Eben damit auch ein VDR in Minimalkonfiguration möglich bleibt.
Schon klar, mein Beispiel war einfach weitgehend aus meiner bestehenden Konfiguration gegriffen, die mit dem Start-Mechanismus von vdr4arch nicht mehr viel gemein hat (dafür aber den Standby erlaubt und einen erfolgreichen Start eines VDR mit Software-Frontend nicht vom vorangehenden Start des X-Servers abhängig macht - mit dbus2vdr und der Unterstützung für sd_notify kann der VDR direkt durch einen Sytemd-Service gestartet werden (die runvdr-extreme wird komplett überflüssig) und man kann sowohl über das Abhängigkeitssystem von systemd als auch durch die Auswertung der Statussignale über dbus zuverlässig weitere Dienste/Aktionen starten lassen, die einen bereits betriebsbereiten VDR erfordern. Das ist dann aber schon die intensivere Ausnutzung der schönen Freiheiten, die einem die vdr4arch-Pakete lassen
shutdown.sh als Konfigurationsdatei bei einem Paketupdate geschützt
Das ist ja das kleinste Problem.
Wenn Interesse besteht schaue ich mir das Lifeguard-Addon gerne mal an
Ja, das Interesse besteht.
runvdr-extreme ist eigentlich schon komplex genug und macht einem durch die starre Struktur einiges unnötig schwer
Das musst du mir bei Gelegenheit auch nochmal erklären.
Das ist ja das kleinste Problem.
Möglichkeiten gibt es hier gleich mehrere.
Man könnte die Datei ausnehmen. Dann werden zukünftige Anpassungen aber auch eher schwer verteilbar sein, oder?
Oder man überlegt sich mal konkret wie eine einfache Hook-Funktion aussehen könnte (also ein Verzeichnis mit Scripten die vor dem Shutdown ausgeführt werden).
Gerade im Zusammenhang mit Lifeguard ist hier die konkrete Vorgehensweise interessant. Entweder in die "shutdown.sh" fest eintragen oder direkt als "Shutdown-Hook" einbinden?
Und wenn Shutdown-Hooks: Kann man sowas so simpel anlegen, dass es jeder auf dem ersten Blick versteht und vor allem findet?
Zitat
Ja, das Interesse besteht.
Ich schaue da alsbald möglich mal drüber.
Soo, gemeinsam mit Mreimer habe ich jetzt vdr-addon-lifeguard portiert.
Wobei man hier wirklich portiert sagen muss. Archlinux kennt kein netstat z.B.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
