ein paar Bemerkungen, Fragen und Vorschläge zu den ebuilds

hauptsächlich mad
Hi,

linuxdvb-1.0.0.20030427, eine Kleinigkeit:
mir ist aufgefallen, dass, wenn der logger angehalten wird, automatisch auch der dvb-Treiber entladen wird. Wird zwar vom vdrwatchdog wieder nachgeladen, und so oft startet stoppt man den syslog auch nicht manuell, aber das muss ja nicht sein;-). Vielleicht ersetzt du das "need logger" besser durch ein "use logger".

Tja - und danach hat sich mein vdr aufgehängt und der watchdog hat's nicht gemerkt. Syslog wurde pro Sekunde 1x mit "vdr[3289]: switching to channel 1" zugemüllt. Konnte das jetzt allerdings nicht mehr reproduzieren.

Ansonsten: großes Lob für die Ebuilds - hat wirklich gut geklappt.
Nur: wo ist der Unterschied zwischen vdr (von mir benutzt) und vdr-wo? Habe auf die Schnelle nix darüber gefunden.

Habe die Installation allerdings so umgemodelt, dass der vdr unter einer eigenen uid läuft.
Kurz zusammengefasst, ohne Anspruch auf Vollständigkeit:
- user+group vdr angelegt, Rechte von /etc/vdr geändert,

- /etc/devfsd/dvb:
----------
REGISTER ^dvb$ PERMISSIONS root.vdr 0755
REGISTER ^dvb/adapter[0-1]$ PERMISSIONS root.root 0755 # vielleicht statt [0-1] besser [0-9] oder .? - das habe ich mir nicht genauer angesehen
REGISTER ^dvb/adapter[0-1]/.*$ PERMISSIONS root.vdr 0660
----------
- shutdown.sh mit visudo eingetragen
/etc/conf.d/vdr (komische Sache, das mit dem Quoten):
SHUTDOWN="\"/usr/bin/sudo /usr/local/bin/vdrshutdown.sh\""

- "vdr" hinter das "su" beim Aufruf des daemons im Initscript eingetragen (gibt es einen besonderen Grund dafür, dass du den daemon mit einem su startest? - und ebenso: warum nicht mit start-stop-daemon?

Wie wär's mit einer Variablen in /etc/conf.d/vdr für den user, unter dem der vdr gestartet werden soll? Dann sollte man neue Ebuilds für den Zweick einfach so übernehmen können.

Und dann habe ich micht noch gefragt, ob /etc/vdr, da der vdr ja schreibend darauf zugreift, nicht defaultmäßig besser irgendwo unter /var/ aufgehoben wäre.

grüße

metrio

Hi,

emerge -s expat sagt mir, dass das ein xml-parser ist. Du meinst expect, oder? Habe dann pexpect (für python) gefunden, und nach einem kurzen Versuch scheint es ziemlich problemlos zu sein, da ne Abfrage zu machen.
Aber zwei Dinge: Was tun, wenn der port belegt ist? Zusätzlich noch mit netstat (oder womit sonst?) nachgucken?

Und bei dem Fehler, den ich hatte, hat, wenn ich ich recht erinnere, svdrp sogar noch reagiert und versucht, den Kanal umzuschalten. Allerdings ohne Erfolg. Bisher auch nicht mehr vorgekommen.
Also wenn du meinst, dass es dennoch Sinn macht, dann kann ich gerne noch ein wenig dran rumfeilen. input welcome!

Dann ist mir aufgefallen, dass der Timeout des Watchdogs bei 8 Sekunden liegt. Irgendwo hier im Forum hieß es, dass 60 Sekunden angemessen wären, weil vdr zuweilen auf nen Epg-scan warten muss.. aber evtl. bei neuen Versionen nicht mehr. Sind die 8 sec. in Ordnung?

thx für die Info über die Versionen. Glaube, der vanilla reicht für meine Zwecke erst mal:-)

Das mit dem wiki geht klar. Mag aber noch ne Woche dauern.

> Die komischen Quotes liegen daran das das Script (init) nicht davon ausgeht das blanks in der Konfig sind.

schon klar, aber ich war froh, dass ich das mit der Variablen hingekriegt habe - im Gegensatz zu meinen Modifikationsversuchen im Script selbst;-)

> Zu start-stop-daemon kann ich nur sagen. Versuchs und sag mir BITTE wie!!
nene - lass mal. Hatte mir schon so was gedacht;-)
Bleibt noch die Frage warum das "su" an sich da drin ist. Wenn es seinen Grund hat, dann wüsste ich das gerne - um was zu lernen:-).

> User von VDR in conf.d/vdr würde etwas gegen die Art des Konfigfiles sprechen. (da sind nur übergabeparameter von vdr drin). Ist ja nicht mal das richtige config.
Versteh ich nicht. So ganz naiv, ohne weitere Recherche, habe ich mir gedacht, in /etc/conf.d/* ist dafür gut, die Startscripte mit Variablen zu füttern?

> Wenn aber allgemein VDR unter einem anderen User läuft
> kann man das mal richtig mit in die Ebuilds einbauen.
Ist da von Klaus Schmidinger was geplant, oder wie meinst du das?

> Configs im /var .... hmmm.... ja richtig aber ... hmmmm .... so richtig schreibend ja auch nicht. ZUmindest in dem Sinne des VAR Verzeichnisses. Und dann müsste da alles ins var da vdr da nicht unterscheiden kann und 95% der Configs sind ro.
Würde ich gerne noch ein paar Meinugen zu abwarten.

War mir auch schon durchn Kopf gegangen. Aber timers.conf und setup.conf wären imo im var-verzeichnis sehr gut aufgehoben. Evtl. noch channels.conf. Sind schon mehr als 5 %;-). Genauso gehört svdrphosts.conf nach /etc. Ist so oder so nicht sauber, aber da kann man wohl als user nix dran ändern:-(.

grüße

metrio

Ich mag python weil die Syntax ziemlich klar ist (im Gegensatz zu perl oder bash), und es im Grunde genommen ein Lisp-Dialekt ist:-). Hab' in python aber auch nur ein paar Grundkenntnisse.

Stimmt - dumme Frage, das mit den Sekunden..

Gut - ich ich mach das mal mit dem pexect. Also: du rufst das script über den Watchdog auf, und spätestens nach 60 Sekunden beendet sich das Script und gibt entweder 0=ok oder was anderes zurück?

> VDR unter einen anderem User ist ebuild sache. VDR kann es, nur um das als default ins Gentoo reinzubekommen müsste das ebuild geändert werden.

Das hatte ich doch vorgeschlagen!? Wie schon im ersten Posting gesagt: ne Variable für den user wäre schon mal n Anfang und würde das normale Ebuild nicht stören. Könnte dann ein Readme dazu schreiben/aus dem wiki übernehmen. Hm - user+group vdr per ebuild anlegen wäre bestimmt auch nicht schlimm, und die Files für den dvfsd dürften ebenfalls nicht stören. Werde mir bei Gelegenheit mal deine Anleitung zu den ebuilds genauer ansehen. Aber erst mal die anderen Sachen machen.

Die devices waren waren nach dem emergen/laden des Treibers vorhanden. [0-9] klingt vernünftig. Ja - nur wegen der Rechte. Ohne ging's erwartungsgemäß nicht, und ne Vorlage für 1 device hatte ich irgendwo ergoogelt.

grüße

metrio

Hi,

ein erster Ansatz. geht auch ohne externes telnet und pexpect ganz gut.
Habe mal jedem expect einen timeout von 60 Sekunden gegeben.
Von einem definierten Zeitkontingent nach jedem Befehl was abzuziehen dürfte sich als schwierig erweisen, und es macht wohl auch wenig Sinn.
Was stört: bei jedem connect ein Eintrag im syslog

Und es ist vielleicht geschickter, das ganze innerhalb von python in einer Endlosschleife (Parameterübergabe sekunden) zu verpacken, und es nur dann aussteigen zu lassen, wenn ein Fehler aufgetreten ist.

Am besten wäre es wohl, einen Kanal umzuschalten, und dann auf die Ausgabe zu warten. Aber wie macht man das, ohne dass es den Benutzer evtl. stört?

Abfrage von netstat braucht LANG=en. Kann man das bei einem Aufruf im Initscript als gegeben annehmen?

#!/usr/bin/env python
''' checks if a vdr running on localhost accepts commands via svdrp
    needs netstat (gentoo: sys-apps/net-tools)
    '''
import telnetlib, sys, commands, re


hostname = 'localhost'
if len(sys.argv) > 1 :
        port = sys.argv[1]
else:
        port = '2001'
if  re.search('\ntcp(\s+\S+){2}\s+\S+:' + port + '\s+ESTABLISHED', \
                commands.getstatusoutput('netstat -nt')[1]) == None :
    try:
        tn = telnetlib.Telnet(hostname, port)
        if tn.expect(['220.*\r\n'], timeout = 60)[0] == -1 :
                sys.exit(3) # couldn't get initial prompt
        for test in [['stat disk\n', ['250.*%\r\n']], \
                          ['chan\n', ['250.*\r\n']]] :
                         # ['quit\n', ['221.*\r\n']]] :
                tn.write(test[0])
                if tn.expect(test[1], timeout = 60)[0] == -1 :
                        sys.exit(2) # no satisfying answer within timeout period
    except telnetlib.socket.error:
        sys.exit(1) # socket error
#else:
#       sys.exit(0) # can't test: port used by other application

grüße

metrio

Hi,

habe gestern das portage-update [edit] und baselayout [/edit]
gemacht, und seitdem(?) funktioniert vdrwatchdog.sh nicht mehr. Lenke ich die Ausgabe der dvb/vdr start/stop/zap-Aufrufe um, bekomme ich dies:
/sbin/runscript.sh: line 27: /softlevel: No such file or directory
/sbin/runscript.sh: line 384: wrap_rcscript: command not found
/sbin/runscript.sh: line 385: eerror: command not found

kann das noch jemand beobachten? Riecht nach fehlenden Umgebungsvariablen, denn von der Kommandozeile aus funktionieren die Aufrufe ganz normal.

Außerdem gibt es noch /lib/init.d/started/vdr. Killt man den vdr, dann wird das nicht gelöscht, und ein erneutes
/etc/init.d/vdr start
* WARNING: "vdr" has already been started.
/etc/init.d/vdr stop
* Stopping vdr (1.1.30) - The Video Disk Recorder...
* Failed to stop vdr.
usw...
Wird das beim/vorm Aufruf des wachtog abgefangen, oder sollte man die started-files in vdrwatchdog.sh löschen?
Da ich mir das genauer ansehen wollte, bin ich überhaupt erst auf die Sache mit runscript.sh gestoßen.

grüße

metrio

Hi,

ah - und ich hatte mich schon gefragt, wofür dieses "zap" gut ist "Kanal umschalten??" und nix gefunden. - jetzt weiß ich es;-).
Mal gespannt, ob du den Fehler jetzt auch hast....

grüße

metrio

xerxes root # epm -q portage
portage-2.0.48_pre6
xerxes root # epm -q baselayout
baselayout-1.8.6.7

Warum habe ich höhere Versionen?

Am überpfüfen vom vdr liegt das ja nicht mal - dein Watchdog versucht, die Initscripts aufzurufen, und scheitert daran, dass /etc/runscript.sh dabei Funktionen nicht findet, die in /sbin/functions.sh definiert sind - wahrscheinlich weil die Variable RC_GOT_FUNCTIONS in /etc/init.d/vdrwatchdog implizit exportiert und an vdrwatchdog.sh übergeben wird, die Funktionen selbst aber nicht den Weg über vdrwatchdog.sh nehmen. Irgendwas in der Art.

: ganz oben in funscript.sh steht:
[ "${RC_GOT_FUNCTIONS}" != "yes" ] && source /sbin/functions.sh

War das vorher anderst? Mal die Variable in vdrwatchdog.sh unsetten. Kann aber im Moment aber nix probieren, da ne Aufnahme läuft.

grüße

metrio

hi,

ah - daher komen diese Versionen. Aber wenn man das ~x86 nicht drin hat, dann gib's doch keine systemspezifischen builds, oder habe ich da was falsch verstanden?

ähm, tja - ich meinte runscript.sh

Und ich wollte schon fast schreiben, dass ich nicht mal weiß, ob der Name deines Rechners in der Aufnahme schon vorkommt oder nicht;-).

Bin mal grad' am gucken, wie ich nen kompletten watchdog in python hinbekomme. Also falls du noch irgendwelche Vorschläge hast....

grüße

metrio

hi,

wenn in vdrwatchdog.sh ganz am anfang

unset RC_GOT_FUNCTIONS RC_GOT_SERVICES \ RC_GOT_DAEMON

einfüge, dann geht's.

Kann wohl nix schaden, wenn du das in den ebuild übernimmst.

grüße

metrio

Hi,

ok - dann werde ich den Ratschlag von euch beiden mal beherzigen und ~x86 aus meinen Kisten rausmachen:-).

Auf meinem Display sehe ich bei den Connects nichts. Also grün.

Ich mache ne Konstante/Übergabeparameter für die Wartezeit in Sekunden nach jedem prozess-check, und nen Multiplikator für das Telnet. Andernfalls würde es etwas trickreich werden. Also nach jedem nten prozess-check wird ein Telnet gemacht - und erst mal abgewartet, timeout ebenfalls einstellbar.

Wenn währenddessen der vdr abschmiert, dann liefert der Telnet-Check direkt nen Fehler - gerade ausprobiert.

grüße

metrio

Hi,

im Anhang (hoffe mal, der kommt rüber) der Watchdog. Scheint ganz gut zu laufen: Habe mal die "seconds" auf 0,5 runtergesetzt und drei Watchdogs gleichzeitig gestartet (neustart-funktion natürlich auskommentiert): svdrp-mäßig gibt das keine Probleme. Vielleicht sind auf dem ein oder anderen System noch n paar Parameteränderungen angebracht.

Also: Tester gesucht;-)

grüße

metrio