Neues X server Handling in der runvdr-extreme. Bitte um Tester.

Aktuell arbeite ich an meiner ersten großen Änderung der runvdr-extreme.

Bisher wurde ein System, welches auf einem X-Server ausgibt, vereinfacht so gestartet:

• runvdr-extreme liest die runvdr.conf und die Befehlszeilen-Parameter.
• Die fertige VDR-Befehlszeile wird in eine "Proxy-Datei" gespeichert (unter /tmp).
• Die erste runvdr-Instanz startet über xinit eine zweite runvdr-Instanz und übergibt den Pfad zur "Proxy-Datei"
• Die zweite Instanz liest die VDR-Befehlszeile und startet den VDR. Nun mit gestartetem X-Server.
• Die zweite Instanz schreibt dann die PID vom VDR wieder zurück in die Proxy-Datei um diese an die erse Instanz zu übermitteln.

Ein "systemd status" zeigt an, wieviele Prozesse hier involviert sind:

# systemctl status vdr
vdr.service - Video Disk Recorder
   Loaded: loaded (/usr/lib/systemd/system/vdr.service; enabled)
  Drop-In: /etc/systemd/system/vdr.service.d
           `-wait-for-devices.conf
   Active: active (running) since Tue 2013-10-29 16:54:09 CET; 2min 18s ago
 Main PID: 495 (runvdr)
   CGroup: /system.slice/vdr.service
           |-495 /bin/bash /usr/bin/runvdr
           |-603 xinit /usr/bin/runvdr --xserver-proxy=/tmp/runvdr-495 -- /us...
           |-604 /usr/bin/X :0 -nolisten tcp
           |-607 /bin/bash /usr/bin/runvdr --xserver-proxy=/tmp/runvdr-495
           `-618 /usr/sbin/vdr -g /tmp -l 2 --lirc -P softhddevice -a hw:NVid...

Mein neuer Code, den Interessierte hier finden können

http://projects.vdr-developer.…treme.git/tree/?h=noxinit

startet den X-Server selber, wartet selber bis dieser bereit ist, setzt dann eine DISPLAY-Variable und startet aus der gleichen Instanz den VDR. Diese Lösung ist nicht nur einfacher nachvollziehbar, und damit leichter wartbar, sondern auch potentiell schneller beim Aufstarten. Unter systemd sieht ein mit der neuen Variante gestarteter VDR so aus:

# systemctl status vdr
vdr.service - Video Disk Recorder
   Loaded: loaded (/usr/lib/systemd/system/vdr.service; enabled)
  Drop-In: /etc/systemd/system/vdr.service.d
           `-wait-for-devices.conf
   Active: active (running) since Tue 2013-10-29 16:57:49 CET; 2min 4s ago
  Process: 664 ExecStopPost=/usr/lib/vdr/bin/gen-sddropin (code=exited, status=0/SUCCESS)
 Main PID: 694 (runvdr)
   CGroup: /system.slice/vdr.service
           |-694 /bin/bash /usr/bin/runvdr
           |-770 /usr/bin/X -nolisten tcp
           `-774 /usr/sbin/vdr -g /tmp -l 2 --lirc -P softhddevice -a hw:NVid...

Ich wäre dankbar wenn einige die neue Variante testen könnten. Schön wäre, wenn auch Leute testen könnten, die garkeinen X-Server verwenden (Fullfeatured). Eigentlich sollte alles wie zuvor funktionieren.

Zu den Meldungen kann ich dir nichts sagen.

runvdr-extreme greift auf jedem Fall nicht auf SVDRP zu.

Was dein "Frontend starten" angeht kannst du auf "XSTARTUP" zurückgreifen (man runvdr oder die Example-Config danach durchsuchen). Das ist genau dafür gedacht. Mit "XSHUTDOWN" kannst du ggf. auch ein Frontend wieder abschießen. Ein Beispiel ist in der "example-Config" vorhanden.

Wobei es in deinem Fall wohl sogar noch einfacher geht: Starte softhddevice einfach nicht detached. Dann findet es seine Verbindung ganz alleine. Mache ich so.

Ein "exec" sollte da nicht rein, denn das würde die runvdr-extreme wohl recht zuverlässig abschießen

Versuche doch einfach mal nur "startfluxbox" dort hinzuschreiben. Und beachte, dass alles, was du dort hinschreibst, als "root" läuft. War mit deiner .xinitrc-Lösung aber auch schon so.

Um ein "XSHUTDOWN" musst du dich dann vermutlich garnicht kümmern, denn so wie ich den xinit-Source in Erinnerung habe, wird dort auch nicht aufgeräumt. Das "fluxbox" stirbt einfach deshalb weg, weil die X-Verbindung flöten geht.

Zum Thema ".xinit" ist mir noch eingefallen: Wenn du "/root/.xinit &" in die "XSTARTUP"-Funktion schreibst, dann sollte dein alter Stand wieder erreicht sein (.xinit wird wieder aufgerufen).

Was SVDRP angeht: Kann schon sein, dass es am Loglevel liegt. Dazu musst du unabhängig von runvdr-extreme suchen, denn die greift ganz sicher nicht auf SVDRP zu.

Die Verbindungen kommen von lokal. Hast du vielleicht vdradmin-am oder ähnliches laufen?

svdrpservice ist zuständig für SVDRP-Verbindungen von Plugins. Schon möglich, dass hier etwas mit reinspielt.

Sagen wir's so: Wenn man seinen VDR sowohl von der Hardware als auch von der Software her auf "Startgeschwindigkeit" getrimmt hat, dann kann die eine Sekunde doch schon einen fühlbaren und auch messbaren Unterschied machen.

Zum Problem von Copperhead habe ich Logdaten ausgewertet. Was genau passiert ist, kann nur noch schwer mit 100%iger Sicherheit reproduziert werden. Allerdings hat sich der VDR im Vorfeld mehrfach selbst über den Watchdog zerlegt. Da war also schon im Voraus etwas faul.

Die Fehlermeldung von X sagt dann letztlich aus, dass entweder schon eine Instanz läuft oder ein Lock-File unter /tmp liegen geblieben ist. Was von beiden der Fall war, ist natürlich nicht mehr nachvollziehbar. In welchen Situationen ein X-Server das "SIGTERM" ignoriert kann ich jetzt auch schlecht abschätzen. Fakt ist aber: Wenn man wirklich zum "SIGKILL" greifen muss, dann müsste man das besagte Lockfile in der runvdr wohl selber wegräumen.

Was ich aber aktuell überlege: Macht es denn Sinn es optional zu ermöglichen den X-Server unabhängig vom VDR stehen zu lassen? Also z.B. eine neue Konfigurations-Option, die, wenn gesetzt, nurnoch den VDR neustartet und den X-Server über die gesamte Laufzeit stehen lässt?

Gestartet kriegt man einen sauber konfigurierten X-Server eigentlich immer. Sollte also keine Fehlerquelle sein. Und ich kann mich aktuell an keinen Fall erinnern in dem ein X-Server-Neustart irgendein Problem gelöst hätte. Oder doch?

Und was die Anmerkung von seahawk1986 angeht: X server starten ist eines von vielen Features der runvdr-extreme. Man kann das nutzen, muss aber nicht. Die Idee ist es, eine einfache Lösung zu schaffen, um den VDR möglichst überall zu starten.

Nachtrag: Wenn der X-Server stirbt (simuliert), dann hat das durchaus negative Folgen für den VDR. Soll heißen: Nach kurzer Zeit gibt der VDR den Löffel ab (softhddevice). In der aktuellen Konstellation fängt die runvdr den Fall irgendwann auf und stellt wieder einen sauberen Stand her. Sollte also wohl besser so bleiben. Den Fehler, dass ein X-Server stehen bleibt und nicht wieder kommt, kann ich aktuell nicht reproduzieren, also an alle: Bitte weitertesten.

Tausche

XSERVER="/usr/bin/X -nolisten tcp :0 >> /var/log/vdr/runvdr.log 2>&1"

durch

XSERVER="/usr/bin/X -nolisten tcp :0"

Der String wird nicht mehr durch eine Shell interpretiert. Deshalb bitte keinerlei Shell-Syntax an der Stelle! Der X-Server loggt selber nach /var/log/Xorg.0.log. Du musst die Ausgabe also nicht weiterleiten!