[gelöst] Problem mit extb-poweroff.pl

Hallo zusammen,
folgende Konfiguration:
c't VDR 4.5, Tobis VDR 1.3.41, Kernel 2.6, ein Extension-Board von TBE (FW 1.9), Plugin fürs Extb ist installiert .
Damit sollte es eigentlich möglich sein, einen Timer zu setzen, der beim Herunterfahren des VDR in den PIC auf dem Extb geschrieben wird und den VDR später wieder aufweckt.
Der Shutdown-Hook S91.extb sollte das Script extb-poweroff.pl aufrufen, das diese Aufgabe übernimmt.
Fahre ich meinen VDR jetzt mit gesetztem Timer herunter, werden die Daten leider nicht in den PIC auf dem Extb übertragen, so dass der VDR auch nicht aufwachen kann.
Im Log sieht man aber, dass er zumindest den Shutdown-Hook findet (executing shutdown-hook S91.extb).
Auszuführen scheint er ihn aber nicht.
Rufe ich nach dem setzen des Timers bei laufendem VDR die extb-poweroff.pl manuell ohne Pameter auf, setzt er den Timer korrekt im Extb, d.h. ich kann den VDR herunterfahren und er fährt um nächsten Timer automatisch hoch.
Also funktioniert das Script und die Kommunikation mit dem Extb ist auch ok.
Aber warum macht er es nicht automatisch?
Aufgefallen ist mir nur, dass selbst der eingeschaltete Debug-Mode in der extb-poweroff.pl keine Einträge im syslog hinterlässt.
Aufgefallen ist mir auch noch, dass er beim Shutdown-Hook S90.custom im syslog beim abarbeiten schreibt "executing shutdown-hook S90.custom as shell script", beim S91.extb aber nur "executing shutdown-hook S91.extb", das "as blabla" fehlt hier.
Die Rechte auf der S91.extb sowie der extb-poweroff.pl sind auf 755.
Die aufgerufenen Dateien sind auch alle am richtigen Platz.

Was zum Geier macht der VDR da mit mir?
Wäre für Tipps sehr dankbar...

MfG,
MadOne

P.S.
Logs kann ich erst später dazu stellen, bin im Moment auf der Arbeit...

Zitat

Original von ROW DY 1
Moin MadOne

Du hast das Extb Plugin bein c't VDR, zum laufen gebracht?
Hast Du es einfach per apt-get installiert oder hast Du es selber übersetzt.

Wenn Du es per Apt Installiert hast, könntest Du mal deine sources.list Posten? Ich habe mittlerweile fast alles durch, ohne durchschlagenden Erfolg

Und das selber übersetzen wollte ich vermeiden

Gruß

rowdy

Alles anzeigen

Sources.list folgt später, wenn ich zu Hause bin.
Und, ja, das Extb-Plugin läuft und wurde per apt-get installiert.

MfG,
MadOne

Ohne jetzt eine Grundsatzdiskussion anfangen zu wollen:
Bei so vielen Nebeneffekten des "Nicht-Root-VDR", wäre es da nicht geschickter gewesen, erstmal einen VDR-Testballon zu starten?
Aber OK, danke für den Tip, werde ich mal ausprobieren, hoffe dass es hilft.
Ansonsten gehen mir allmählich die Optionen aus ...

MfG,
MadOne

Ja, das mit der Reihenfolge habe ich mir auch schon überlegt ...
Wie ließe sich das denn beeinflussen?
Die Shutdown-Hooks führt er ja über diesen Shutdown-Wrapper aus ...
Und direkt nach dem Ausführen (laut Log ca. 5 sek) des Shutdown-Hooks jammert Lirc über einen "Error read ()" im syslog...
Sollte ich Lircd in den rcs erst später oder vielleicht gar nicht abschießen lassen?
Oder würde es im Shutdown-Hook selbst ne "programmierte Wartezeit" (wait oder so) von 10 oder 15 Sekunden auch tun, bevor er den Hook mit Exitcode 0 beendet?

MfG,
MadOne

Also, user=root bewirkt keine Lösung des Problems.
Ein "sleep 10" in der S91.extb verändert auch nichts an dem Problem.
Von Hand kann ich bei "Debug=0" in der extb-poweroff.pl den Timer übertragen, das geht.

So sieht es aus, wenn der VDR runterfährt:

Feb 16 23:30:35 localhost vdr: [4956] executing '/usr/lib/vdr/vdr-shutdown.wrapper 1140146400 17365 1 "Olympia mit Waldi & Harry" 1'
Feb 16 23:30:35 localhost vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.custom as shell script
Feb 16 23:30:35 localhost vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S91.extb
Feb 16 23:30:40 localhost lircd 0.7.1pre2[4142]: read() failed
Feb 16 23:30:40 localhost lircd 0.7.1pre2[4142]: Connection reset by peer 
Feb 16 23:30:40 localhost lircd 0.7.1pre2[4142]: removed client
Feb 16 23:30:40 localhost lircd 0.7.1pre2[4142]: removed client
Feb 16 23:30:40 localhost kernel: ppdev0: negotiated back to compatibility mode because user-space forgot
Feb 16 23:30:40 localhost kernel: ppdev0: unregistered pardevice
Feb 16 23:30:40 localhost lircd 0.7.1pre2[4142]: removed client
Feb 16 23:30:41 localhost shutdown[5210]: shutting down for system halt
Feb 16 23:30:41 localhost init: Switching to runlevel: 0
Feb 16 23:30:41 localhost udev[5214]: removing device node '/dev/vcs1'
Feb 16 23:30:41 localhost udev[5215]: removing device node '/dev/vcsa1'
Feb 16 23:30:41 localhost udev[5222]: removing device node '/dev/vcs2'
Feb 16 23:30:41 localhost udev[5226]: removing device node '/dev/vcsa2'
Feb 16 23:30:41 localhost udev[5230]: removing device node '/dev/vcs3'
Feb 16 23:30:41 localhost udev[5234]: removing device node '/dev/vcsa3'
Feb 16 23:30:41 localhost udev[5238]: removing device node '/dev/vcs4'
Feb 16 23:30:41 localhost udev[5241]: removing device node '/dev/vcsa4'
Feb 16 23:30:41 localhost udev[5245]: removing device node '/dev/vcs5'
Feb 16 23:30:41 localhost udev[5249]: removing device node '/dev/vcsa5'
Feb 16 23:30:41 localhost udev[5253]: removing device node '/dev/vcs6'
Feb 16 23:30:41 localhost udev[5257]: removing device node '/dev/vcsa6'
Feb 16 23:30:41 localhost udev[5261]: removing device node '/dev/vcs8'
Feb 16 23:30:41 localhost udev[5298]: removing device node '/dev/vcsa8'
Feb 16 23:30:42 localhost udev[5313]: creating device node '/dev/vcs8'
Feb 16 23:30:42 localhost lircd 0.7.1pre2[4142]: caught signal
Feb 16 23:30:42 localhost udev[5314]: creating device node '/dev/vcsa8'
Feb 16 23:30:44 localhost kernel: Kernel logging (proc) stopped.
Feb 16 23:30:44 localhost kernel: Kernel log daemon terminating.
Feb 16 23:30:44 localhost exiting on signal 15

Irgendjemand noch eine Idee oder einen Workaround?

MfG,
MadOne

Jo, er lief als "root".
Stand auch so im Syslog - "switching to user root"
Ging aber trotzdem nicht, schade. Probiere gerade noch eine Variante, mal sehen, was mit der passiert ...

So, hier noch meine Sources.list wegen der Anfrage von ROW DY:

deb [URL]http://ftp2.de.debian.org/debian[/URL] sarge main non-free contrib
deb [URL]http://security.debian.org/[/URL] sarge/updates main contrib non-free
deb [URL]ftp://ftp.nerim.net/debian-marillat[/URL] sarge main
deb [URL]http://e-tobi.net/vdr-experimental[/URL] sarge base backports addons vdr-multipatch
deb [URL]http://www.heise.de/ct/ftp/projekte/vdr45[/URL] updates/

MfG,
MadOne

So, jetzt scheint es zu funktionieren...
VDR läuft jetzt als Root, das scheint eine Grundvoraussetzung zu sein.
Außerdem waren in dem Script S91.extb die Rechte auf 644 zu setzen, und die erste Zeile zu entfernen (#!/bin/sh).
Danach hat die Timerfunktion zumindest einmal funktioniert, wenns beim zweiten Mal auch noch geht - atomsuperduperfreu.

MfG,
MadOne

Ich gebe zu, dass ich außer mit dem ct-VDR (der immer gleich nach der Installation auf Tobis Pakete umgestellt wurde ) keine Erfahrungen habe (Linux-Nub -> planloser Windozen-Uhsähr).
Mal sehen, ob er den nächsten Timer auch so schön frisst.
Ob der VDR rootet oder nicht, ist mir primär trötegal.
Habe den Grund für die plötzliche nichtmehrverwurzelung des VDR leider immer noch nicht verstanden.
Aus dem I-Net ist er sowieso nicht zu erreichen, zumindest müsste man dazu gleich drei Passwörter hacken...

MfG,
MadOne

Die Datei hatte original 644, hatte sie nur zum Testen auf 755 hochgedreht.
Mit 644 und VDR nicht als root ging sie aber trotzdem nicht.
Erst als ich zusätzlich zur Zeile USER=root in der /etc/default/vdr die /bin/sh - Zeile aus der S91.extb entfernt habe, tat das Script, was es soll.
Die Timer funktionieren jetzt, er frisst sie.
Danke für die Hilfe(n).

MfG,
MadOne