VDR Upstart Script bei yavdr unstable-vdr

  • Ich habe mir in einer Raring Testinstallation den vdr aus dem yavdr unstable repo installiert. Beim Booten wurde vdr jedoch nicht gestartet. Das Upstart Script selbst funktionierte. Nachdem ich im Script "start on [...] stopped networking" auf "started networking" geändert habe, läuft es auch beim Booten hoch. Jetzt meine Frage: Warum steht da "stopped networking". Rein intuitiv macht das für mich nicht so viel Sinn.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    Einmal editiert, zuletzt von Flachzange () aus folgendem Grund: präzision

  • Moin!


    "networking" ist der Upstart-Job, der das Netzwerk konfiguriert, d.h. sobald der beendet ist, sind alle Netzwerkschnittstellen fertig eingerichtet.
    http://upstart.ubuntu.com/cookbook/#standard-idioms


    Wie sieht denn deine /etc/default/vdr aus? Ist da der Job aktiviert?
    Was hast du an dem PC für Netzwerkschnittstellen? Ist da vielleicht irgendwas anders (statisch) konfiguriert, so dass "networking" vielleicht nicht richtig arbeitet?


    Lars.

  • MOD: Ich habs mal nach Debian und Derivate verschoben. :)


    Flachzange:
    stopped networking ist schon ganz richtig - wie sieht denn bei dir status networking aus ?


    Hintergrund: /etc/init/networking macht ein ifup -a - was alle interfaces die in /etc/network/interfaces konfiguriert sind hochbringt.
    in /etc/network/if-up.d/upstart wird beim letzten Gerät dann ein initctl emit --no-wait static-network-up gemacht. Also ist wenn das signal static-network-up da ist oder der Task networking gestoppt ist das Netzwerk fertig. Ich vermute das es nicht das besagte event ist was den Unterschied gemacht hat ... wenn man nichts anderes konfiguriert hat, sollte zumindest lo da drin stehen.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • hepi
    Nicht hilfreich!


    @Rest
    Danke für eure Antworten.


    Wie sieht denn deine /etc/default/vdr aus? Ist da der Job aktiviert?


    Ja, sonst würde das Script auch bei manuellem Aufruf nicht starten


    Was hast du an dem PC für Netzwerkschnittstellen? Ist da vielleicht irgendwas anders (statisch) konfiguriert, so dass "networking" vielleicht nicht richtig arbeitet?


    /etc/network/interfaces:

    Code
    # The loopback network interface
    auto lo
    iface lo inet loopback
    
    
    # The primary network interface
    auto eth0
    iface eth0 inet dhcp



    Flachzange:
    stopped networking ist schon ganz richtig - wie sieht denn bei dir status networking aus ?


    Code
    # sudo initctl list | grep network
    network-interface (lo) start/running
    network-interface (eth0) start/running
    network-interface-security (network-interface/eth0) start/running
    network-interface-security (network-interface/lo) start/running
    network-interface-security (networking) start/running
    networking start/running
    network-interface-container stop/waiting


    Networking läuft also weiter. Das ist ja auch der Grund, warum meine Änderung auf "started networking" funktioniert. Ich werden also mal bei "/etc/network/if-up.d/upstart" weiterschauen

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Da gab es ein Missverständnis bei mir: Du schreibst im Thread-Titel "yavdr unstable". Es gibt ein Launchpad-PPA namens unstable-yavdr. Ich dachte, das meinst Du in diesem Thread. Du meinst aber das PPA unstable-vdr. Das habe ich falsch verstanden.


    Okay, sorry für die Verwirrung. Tatsächlich habe ich das unstable-yavdr eingebunden, aber ich beziehe mich natürlich hier nur auf den vdr.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Networking läuft also weiter. Das ist ja auch der Grund, warum meine Änderung auf "started networking" funktioniert. Ich werden also mal bei "/etc/network/if-up.d/upstart" weiterschauen


    Zur Not ein paar Logmeldungen in den Upstart-Job einbauen.
    Upstart zu Debuggen ist nicht einfach, das wird erst mit Upstart 1.8 besser.


    Lars.

  • Hintergrund: /etc/init/networking macht ein ifup -a - was alle interfaces die in /etc/network/interfaces konfiguriert sind hochbringt.
    in /etc/network/if-up.d/upstart wird beim letzten Gerät dann ein initctl emit --no-wait static-network-up gemacht. Also ist wenn das signal static-network-up da ist oder der Task networking gestoppt ist das Netzwerk fertig. Ich vermute das es nicht das besagte event ist was den Unterschied gemacht hat ... wenn man nichts anderes konfiguriert hat, sollte zumindest lo da drin stehen.


    Müsste networking dann nicht stoppen, wenn ich manell "initctl emit --no-wait static-network-up" mache? Das tut es nämlich nicht

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Wenn Du das PPA unstable-yavdr eingebunden hast (was nicht notwendig ist für die Installation des VDR-Paketes + Plugins aus unstable-vdr), stelle sicher, dass Du von dort keine Pakete installierst wie beispielsweise yavdr-essential oder yavdr-base. Denn sonst wird der Default-Upstart-Job des VDR-Paketes komplett ausgehebelt, siehe mein Link auf's Git oben.


    Gruß
    hepi

  • Jetzt habe ich doch noch mal nachgeschaut. Ich war zwar der festen Überzeugung, dass es unstable-yavdr ist , aber du hattest Recht, tatsächlich wird unstable-vdr geladen.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • hepi:
    Der vdr-Upstart-Job ist von yavdr-base ins vdr-Paket gewandert. Es gibt nur ein Problem, wenn man testing/stable-yavdr mit unstable-vdr mischt, weil dann die beiden Pakete yavdr-base und vdr jeweils /etc/init/vdr.conf mitbringen.


    Lars.

  • hepi:
    Der vdr-Upstart-Job ist von yavdr-base ins vdr-Paket gewandert. Es gibt nur ein Problem, wenn man testing/stable-yavdr mit unstable-vdr mischt, weil dann die beiden Pakete yavdr-base und vdr jeweils /etc/init/vdr.conf mitbringen.


    Lars, ich meine es anders: Wenn er aus unstable-yavdr yavdr-base installiert haben sollte, kommt doch vdr.override zum Zuge und der normale Upstart-Job vdr.conf wird ignoriert.


    Gruß
    hepi

  • Lars, ich meine es anders: Wenn er aus unstable-yavdr yavdr-base installiert haben sollte, kommt doch vdr.override zum Zuge und der normale Upstart-Job vdr.conf wird ignoriert.


    Das würde mich aber wundern, denn dann dürften unsere unstable-vdrs alle nicht laufen... :)
    In der vdr.override steht nur "expext stop" drin, d.h. der vdr-Upstart-Job wird schon ausgeführt, aber zusätzlich noch "expect stop" dazugetan. Da wir ja dbus2vdr mit dem Parameter "--upstart" benutzen, sendet dbus2vdr das STOP-Signal, wenn der vdr vollständig initialisiert ist, damit Upstart dann abhängige Dienste starten kann.


    Deaktivieren kann man Upstart-Jobs nur, wenn man in die override-Datei "manual" hineinschreibt, weil dann die "start on"-Bedingung ausgehebelt wird.
    Die override-Dateien überschreiben nicht den ganzen Job, sondern nur die stanzas, die da drin angegeben sind.


    Danke aber, dass du mich daran erinnerst.
    Flachzange: hast du dbus2vdr aktiv? Wenn ja, mit welchen Parametern (/etc/vdr/plugins/plugin.dbus2vdr.conf)?


    Wenn dbus2vdr aktiv ist und mit "--upstart" gestartet wird, dann muss "expect stop" in den Job, wenn nicht aktiv oder ohne "--upstart", dann darf da kein "expect stop" drin stehen.


    Lars.

  • Danke aber, dass du mich daran erinnerst.
    Flachzange: hast du dbus2vdr aktiv? Wenn ja, mit welchen Parametern (/etc/vdr/plugins/plugin.dbus2vdr.conf)?


    Wenn dbus2vdr aktiv ist und mit "--upstart" gestartet wird, dann muss "expect stop" in den Job, wenn nicht aktiv oder ohne "--upstart", dann darf da kein "expect stop" drin stehen.


    Den Hinweis hatte ich in der conf Datei gelesen. dbus2vdr habe ich nicht. Aber wie gesagt. Das vdr script wird regulär ausgeführt, wenn ich am Anfang "start on started networking" setze. Das networking noch läuft ist wohl das eigentliche Problem.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • In unstable-vdr ist aber der vdr mit neuem upstart-Job enthalten. Die override macht nur expect stop - das würde sich aber anders auswirken. Anyway ...


    Flachzange: Wie sieht denn bei dir /etc/init/networking.conf aus ? Ich bin noch auf precise mit all meinen Systemen.
    Ein if-up -a sollte in endlicher Zeit fertig sein und ein task bleibt normalerweise nicht weiter laufen. Wenn wir jetzt mal nicht ubuntu debuggen wollen:
    ersetze "stopped networking" mit "static-network-up". Das initctl emit stoppt nicht networking. networking sagt mit diesem emit das es fertig ist.
    Also nur weil du das Signal gibst das er fertig ist, muss er dann nicht auf magische Weise fertig sein ;)


    Wenn dann das Problem immer noch existiert, sollte man dmesg/syslog anschauen ob Probleme gemeldet werden, oder if-up -a mal manuell auf der Kosole ausführen um zu sehen ob er fertig wird.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Die networking.conf sieht etwas anders aus als bei precise. Ich habe mich jetzt blöderweise durch eine Änderung selbst ausgesperrt und komme bis heute Abend erstmal nicht mehr ans System.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Das vdr script wird regulär ausgeführt, wenn ich am Anfang "start on started networking" setze. Das networking noch läuft ist wohl das eigentliche Problem.


    Ja, genau, dass ist das Problem. Warum kommt "networking" bei dir nicht zum Ende?
    "on started networking" startet den vdr, sobald die Netzwerkkonfiguration beginnt, d.h. aber, dass die beiden Jobs parallel gestartet werden. Das kann zu Problemen bei der Netzwerkfunktionalität des vdr oder seiner Plugins führen.
    Deshalb ist "on stopped networking" oder eben "on static-network-up" das richtigere.


    Ah, bei raring ist das wohl kein Task mehr, das erklärt einiges. Dann ist "on static-network-up" korrekt.


    Lars.

  • Ah, bei raring ist das wohl kein Task mehr, das erklärt einiges. Dann ist "on static-network-up" korrekt.


    Und wieder etwas gelernt gerlernt. Danke. Ich probiere es aus, sobald ich wieder Zugang habe. Heißt das im Umkehrschluss, dass networking unter raring durchläuft, also started bleibt?

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Ich hab noch kein Raring laufen, aber es sieht so danach aus.
    Beim Stopp von networking scheint er dann ja auch die Netzwerkgeräte wieder zu löschen und "deconfiguring-networking" zu senden. Das macht unter precise noch rc.conf.
    Da hat sich also definitiv was geändert.


    Danke für den Hinweis!
    Das einzige "Problem" ist dann nur, dass es "static-network-up" nicht unter Lucid und Natty gibt, sondern erst seit Oneiric.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!