yaVDR 0.6.1: Verhalten, wenn das root filesystem im ro Modus gestartet wurde

    Das wird z.B. benötigt, wenn man ein Festplatten-Image bei laufendem VDR-System ziehen will. Dazu muss ein "remount,ro" in die /etc/fstab rein und neugestartet werden und nach der Arbeit muss das "remount,ro" wieder raus aus der /etc/fstab" (dazu muss der ro-Modus temporär aufgehoben werden) und wieder neugestartet werden.


    Nun zum Problem:
    Nach dem ersten Reboot (im ro-Modus also) war es bisher so, dass der VDR Upstart-Job sich in einen Wartezustand begeben hat, bis das Filesystem wieder schreibbar wurde, und dann hat er ganz normal weiter gemacht.
    Neuerdings wartet der Upstart-Job aber bis in alle Ewigkeit. Und wenn man dann rebootet, stirbt dadurch zwar der "post-start" Prozess, aber das löst dann (während des Herunterfahrens!) den Start des VDR aus. Resultat: Der Rechner bleibt stehen und nur noch die Reset-Taste hilft.


    Mit etwas Geduld fand ich heraus, dass man nach dem Re-Aktivieren des rw-Modus den "post-start" Prozess des VDR von Hand killen muss, danach noch ein "stop vdr" hinterher, und dann funktioniert der Reboot.
    Damit aber noch nicht genug: Eine der Aktionen bewirkt offenbar, dass beim Reboot ein falscher ALSA-State auf die Platte geschrieben wird. Abhilfe schafft hier ein "alsactl restore" direkt vor dem Reboot.


    Warum ich das alles erzähle, obwohl ich ja offenbar eine Lösung für alles gefunden habe?


    Nun ja, das alles ist bei mir Teil eines Backup-Scriptes, und das will ich eigentlich so allgemein wie möglich halten. Ich würde mir wünschen, dass ich dort keine (exotischen) Eigenheiten des Zielrechners rein programmieren muss.


    Gibt es eine solche Lösung? Zufrieden wäre ich aber z.B. auch schon, wenn ich den VDR-"post-start"-Prozess noch im ro-Modus killen könnte. Das liesse sich auch relativ einfach allgemeingültig programmieren. Aber leider startet (zumindest) der VDR-"post-start"-Prozess immer sofort wieder neu, vermutlich durch irgendeinen Watchdog :wand .

    Warum installierst du nicht ein zweites System, dass dann für das Backup gebootet wird, das Image zieht, und dann wieder das normale System startet?


    Oder du nutzt ein Dateisystem mit Snapshot-Funktionalität.


    Und warum muss das Filesystem ro sein? Von yaVDR aus unterstützen wir da nichts direkt. Dann musst du vor dem ro-mounten eben den vdr stoppen. Das hilft nicht?


    Lars.

    Also, nach dem Booten in ro ist der VDR ja erst einmal nicht gestartet. Er ist dann irgendwie am "warten". "status vdr" sagt: "vdr stop/post-start, process xxxx".


    Gerne würde ich genau diesen Prozess dauerhaft stoppen, so dass er später beim Reboot nicht dazwischenfunken kann, aber wie gesagt, wird der immer wieder automatisch neu gestartet.


    Warum ich das unbedingt auf dem "heissen" System haben will, ist ganz einfach: Es ist schön einfach zu steuern von dem (genialen) Progrämmle, das bei mir auf der NAS als cron-job läuft und automatisch und regelmässig (jeden Monat eines Nachts) Images von allen (!) meinen Rechnern zieht. Was Du vorschlägst, ist natürlich DIE Lösung, benötigt aber dauernd manuelle Eingriffe.


    Ausserdem ist das Problem eines, das nicht unbedingt nur mein (seltenes) Anliegen betreffen muss. Schliesslich ist es doch die Aufgabe des Upstart-Systems, Dinge genau dann zu starten, wenn sich das gehört. Und genau das ist ja in meinem Fall nicht so. Da wird der VDR vom sterbenden "post-start"-Prozess gestartet, und das kann nicht gut sein. Nie. Ihr habt vermutlich den (seltenen) Fall nur noch nicht wahrgenommen, wo das System auch ohne ro-Mounting beim Runterfahren einfriert. Jetzt, wo ich weiss wie, bekomme ich den VDR in 50% der Fälle auch ohne mein ro-Gebastel zum Aufhängen, und zwar indem ich einfach Strg+Alt+Del zur Unzeit drücke...

    Zitat von ako673de

    Ausserdem ist das Problem eines, das nicht unbedingt nur mein (seltenes) Anliegen betreffen muss.


    Das sind mir immer die liebsten Beschreibungen, a la "das brauchen bestimmt auch andere". Wenn es andere brauchen würden, dann hätten die sich schon gemeldet. Du bist also der erste. :)


    Wenn ich ein Backup meines vdr machen würde, wären es nur die paar Templates und die channels.conf und timers.conf. Mehr nicht. Wenn die Platte abrauchen würde, installiere ich es einfach neu, spiele die config-Dateien zurück und das war's.


    Zitat von ako673de

    Also, nach dem Booten in ro ist der VDR ja erst einmal nicht gestartet.


    Wenn dein Script schon irgendwas im System verändert, damit du das root-fs readonly mountest, warum erstellst du dann nicht eine /etc/init.d/vdr.conf.override mit dem Eintrag "manual", damit der Job gar nicht erst startet? Und damit es dein allgemeines Backupscript nicht machen soll, damit es allgemein bleibt, dann erstelle eine Möglichkeit, ein lokales Snippet einzubinden, welches rechnerspezifische Vorgänge für ein erfolgreiches Backup vornimmt.


    Und von welchem post-start-Script sprichst du? Ich sehe da keinen Abschnitt.
    Du musst schon mit ein paar mehr Details kommen, so allgemein ohne Code kann ich leider nicht viel sagen.


    Welcher Zeitpunkt ist denn die Unzeit für Strg+Alt+Entf?


    Lars.

    Zitat von mini73

    Und von welchem post-start-Script sprichst du? Ich sehe da keinen Abschnitt.


    Es gibt da https://github.com/yavdr/yavdr…init/vdr.override/10_main - das ist eine Krücke für Upstart, damit man Jobs mit "start on started vdr" wie unter yaVDR 0.5 starten lassen kann, nachdem der VDR komplett gestartet wurde (weil wir das expect stop rausgenommen haben) - wenn man das nicht benötigt (die relevanten Skripte in yaVDR nutzen stattdessen das Skript on_vdr) kann man den post-start auch entfernen.


    Eventuell bleibt da der logger-Aufruf hängen, wenn das Logverzeichnis read-only gemountet ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ok. Trotzdem würde ich nicht erwarten, dass bei einem ro-rootfs alles so funktioniert, wie ich es gerne hätte.
    Das ist definitiv ein Szenario, das wir bei yavdr nie wirklich getestet haben bzw. unterstützen können.


    Warum muss das rootfs denn eigentlich readonly sein?


    Lars

    Bitte nicht böse sein! Natürlich ist dieses Thema lowest Prio. Dass Ihr Euch überhaupt damit abgebt, dafür Euch beiden erst mal ein grosses Danke.


    Also, es ist genau so, dass "on_vdr" hängen bleibt, wenn das Logverzeichnis ro ist. Das ist aber nicht ganz das Thema. Das Thema ist, wie "on_vdr" sich verhält, wenn...
    1) das Log-Verzeichnis wieder schreibbar wird.
    2) es gekillt wird, bevor es den VDR (zu Ende) gestartet hat.


    Zu 1) Früher hat es dann ganz entspannt (weiter) den VDR gestartet. Jetzt hängt es dann fest =>
    @seahawk: Damit ist - glaube ich - Dein Gedanke gestorben. Da "on_vdr" nicht wieder zurück in einen stabilen Betrieb findet, kann ich nämlich auch nicht auf "VDR gestartet" warten, weil dieses Ereignis ja nicht eintritt.


    Zu 2) Der Tod von "on_vdr" löst den Start des VDR aus =>
    mini: Die "Unzeit" für Strg+Alt+Entf ist also genau dann, wenn "on_vdr" schon läuft, aber den VDR noch nicht gestartet hat. Der Reboot hat dann nämlich einige Prozesse schon gekillt und vermutlich den Runlevel schon auf 0 gesetzt, bevor "on_vdr" dran ist. Wenn dadurch dann VDR startet, der ja einige der bereits gekillten Prozesse benötigt, dann ist es vorbei und alles was man noch von dem Tod sehen kann, ist im ersten Terminal etwas in der Art "killing remaining processes ... fail", und dass sich das syslog immer weiter (im 3s-Takt) bis in alle Ewigkeit mit gescheiterten dbus-Kommandos füllt. Alle Terminals sind dann übrigens auch tot, vermutlich wegen runlevel 0.

    Vielleicht konzentrieren wir uns doch einfach mal darauf: Wieso kann noch etwas starten, nachdem der Reboot schon die ersten Prozesse gekillt hat und damit das Runlevel doch sicherlich auch kaum mehr eines sein dürfte, das noch den Start eines VDR erlauben würde :wow? Das ist m.E. in jedem Fall ein Fehler. Da weiss man doch nie, wann und wo dadurch noch etwas Unerwünschtes passiert, oder?



    mini: Du hast schon mal die epgsearch-Dateien vergessen. Auf Anhieb fällt mir dann noch die /etc/openbox/rc.xml ein, die ja kaum im Originalzustand bleiben kann (siehe ein anderer Thread von mir), und nicht (mehr) getemplatet ist. Und so ging es mir andauernd, bis ich mich zu dem Programmier-Projekt durchgerungen habe. Immer hab ich genau die Dateien zu sichern vergessen, die ich später gebraucht habe.


    mini: vdr.conf.override ist natürlich auch eine Lösung, aber viel besser als meine (kill on_vdr, stop vdr, restore alsa) ist die auch nicht wirklich, oder?

    Zu 1): Letztendlich sind das ja zwei Bedingungen, die da erfüllt sein müssen, damit es sich beim Aufruf mit den in dem Fall übergebenen Argumenten beendet:

    • Der VDR muss über dbus2vdr beim Start von on_vdr bereits sein Interface auf dem SystemBus anbieten oder das Programm läuft, bis es das DBus-Signal "Ready" von dbus2vdr bekommt
    • Der übergebene Befehl muss sich beenden

    Das ist ohne Logfiles schlecht nachzuvollziehen - wenn es dich interessiert, kannst du da ja mal gezielt Debuggen, indem du z.B. ins Netzwerk loggen lässt oder dich mit einem Debugger an on_vdr hängst, um zu sehen, was er gerade macht.
    Zu 2): Sobald du einen Automatien manipulierst, musst du damit rechnen, dass irgendetwas nicht mehr funktioniert - da gibt es noch mehr Punkte an denen es potentiell hakeln kann (z.B. wenn man KODI über irexec starten lässt, bevor der vdr-frontend Upstart-Job läuft) - die bisherige Struktur ist sicher nicht perfekt, aber mit Upstart sehe ich da wenig Potential das zu verbessern.
    Upstart selbst hat auch einige Unschönheiten, inklusive hängender Jobs in bestimmten Situationen und wurde bei neueren Ubuntu-Versionenschon durch Systemd ersetzt- meine Motivation mich groß mit Upstart-Skripten aufzuhalten ist daher relativ gering, da man sich die meisten Würgarounds mit Systemd schenken kann - aber sinnvolle Vorschläge nehme ich gerne an.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    Zu 2): Sobald du einen Automatien manipulierst, musst du damit rechnen, dass irgendetwas nicht mehr funktioniert


    Das ist klar, aber darum habe ich ja ein Szenario vorgestellt, wo auch ohne Manipulation ein Unglück passiert. Auf dieses Szenario bin ich zwar durch meine Manipulation gekommen, aber das Szenario an sich hat damit nichts zu tun.



    Wie auch immer: Ich habe das jetzt so verstanden, dass Du das Starten von Prozessen in den "reboot"-Vorgang hinein für einen "minor" Bug von Upstart hältst, den Du eher nicht weiter verfolgen willst, weil es ja ab Ubuntu 16 sowieso was Neues gibt, das vermutlich deutlich besser sein wird. Ja?


    War mir fast klar. Trotzdem danke.


    Darf ich trotzdem noch was fragen? Mein zentrales Problem ist ja, dass sich "on_vdr" immer wieder von selbst startet, wenn ich es (noch im ro-Modus befindlich, also ohne Gelegenheit mir ins Handwerk zu pfuschen) kille. Ich kenne mich zu wenig aus mit den Interna. Kannst Du mir sagen was dafür zuständig ist, d.h. was ich zusätzlich killen muss, damit on_vdr sich nicht mehr "berappelt". initctl? init? ...?

    So, hier nun (nach längerem Studium) meine Lösung - falls es irgend jemanden interessiert:


    Für das "Berappeln" ist die Anweisung "respawn" in den Upstart-Skripten (/etc/init/vdr*) verantwortlich. Ich verstehe zwar weiterhin nicht, warum vdr.override (dort wird on_vdr gestartet) ständig "respawned" (die Anweisung steht gerade dort nicht, sondern z.B. in vdr-frontend.conf), aber am Ende war es mir egal.


    Benenne ich nämlich einfach alle VDR-Upstart-Skripte (.conf und .override!) um, dann wird weder VDR noch on_vdr automatisch gestartet und ich kann entspannt zwischen ro und rw Modus wechseln, ohne beim Reboot Probleme zu bekommen.


    Lästig ist daran eigentlich nur, dass die umbenannten Dateien genau in dieser Form in das Image geschrieben werden. Aber da gibt es sowieso schon mind. eine andere Datei, die das gleiche Problem hat, nämlich /etc/fstab. Ist also auch nicht so schlimm (mein Image-Backup-Script generiert dazu ein "Post-restore"-Script, das man ausführen muss, nachdem man von einem Image zurück gesichert hat).

    Hallo ako673de,


    das Problem, das root-fs "ro" mounten zu müssen für ein einfaches&schnelles komplett Backup der Vdr installation per "dd" habe ich auch. (Schließlich sollen sich ja nicht grade irgendwelche Sektoren in der Systempartition ändern während dd die Parition grade sichert).
    Hatte es vorher auch immer so gemacht erst von ner live-cd bzw. usb stick zu booten, oder noch ne weitere parallele Linux Installation auf der Platte zu haben die man dann im Grub anwählt, aber hat sich alles als zu unpraktisch und unnötig kompliziert bzw. langsam erwiesen.
    Einfach nur per ssh ins "echte "System einloggen zu können und nur ein Script auszuführen zu müssen ist einfach unschlagbar was die usability angeht. ;)
    Ich gehe die Sache aber quasi vom anderen Ende an.


    Ich stelle erst fest welche Prozesse den offene write handles aufs root-fs haben, die beende ich dann bzw. schieße sie ab und dann lässt sich auch das rootfilesystem "ro" re-mounten.
    Hat denn Vorteil das man keinerlei Skripte/Configfiles/fstab vorher editieren muss und das gesicherte Image out-of-the box zurückgeschrieben werden kann ohne danach noch Modifikation vornehmen zu müssen.


    Mit dem Kommando kann man sich anzeigen lassen wer write handles offen hat auf "/":

    Code
    sudo lsof / | awk 'NR==1 || $4~/[0-9][uw]/'


    Unter yavdr 0.6 ergibt sich bei meiner Installation dann daraus letztendlich diese Stop/Kill Sequenz (muss mit root rechten ausgeführt werden):


    Wenn man jetzt das erste Kommando nochmal ausführt:

    Code
    sudo lsof / | awk 'NR==1 || $4~/[0-9][uw]/'


    Sollte die liste leer sein, wenn nicht, muss man halt schauen was man noch stoppen/beenden muss.


    Auf jedenfall kann man danach mittels dem Kommando hier das root-fs read-only mounten:

    Code
    sudo mount -o remount,ro /


    und danach lustig mit dem Backup Tool seiner Wahl loslegen.

    Ging ja bei mir nicht, weil es bei meinem Reboot-Ansatz kein "vor" gibt. Aber das Umbenennen der Upstart-Files stoppt den VDR ja auch irgendwie, oder?


    lsof ist mir durchaus bekannt, hat aber einige Haken:
    - ist defaultmässig nicht installiert in Ubuntu, und z.B. auf meiner NAS müsste ich es erst von Hand kompilieren
    - die Liste, die lsof ausgibt, kann nicht direkt zum "stop"-pen von Jobs benutzt werden.
    - Anstatt dessen einfach brutal "killall -9" auf alle Prozesse in der Liste anwenden scheitert daran, dass einige davon mit "respawn" dagegen geschützt sind.


    Das Problem an einer Liste, wie sie Antiriad z.B. für sein System (manuell) ermittelt hat, ist auf jeden Fall die "Flüchtigkeit". Installiere ich neue Software kann es sein, dass das nächste mal das Backup-Tool versagt, weil es plötzlich nicht mehr ro-remounten kann. Davon würde ich nie was mitbekommen, weil das Backup-Tool wie gesagt auf einem anderen Rechner als cron-Job läuft.


    Ich brauche also eine Möglichkeit, wie ich das lsof-Ergebnis programmgesteuert in Upstart-Jobs, SysV-Jobs, (zukünftig) systemd-Jobs und unabhängige Prozesse aufspalten lassen kann.
    Kurz: Wie findet man die zu Prozessen gehörenden Upstart, SysV, oder systemd-Jobs heraus? Jemand eine Idee hierzu?

    Zitat von ako673de

    Davon würde ich nie was mitbekommen, weil das Backup-Tool wie gesagt auf einem anderen Rechner als cron-Job läuft.


    Ein Backup kann aus verschiedenen Gründen fehlschlagen, z.B. wenn kein Platz mehr da ist usw. Benachrichtigt dich dein Script nicht, wenn etwas nicht geklappt hat?
    Ich würde mir sogar eine Erfolgsmeldung schicken lassen, damit ich sehe, dass es überhaupt gelaufen ist. Kann ja auch mal sein, dass bei cron etwas hakt.


    Lars.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden