Nach Systemupdate kein /var/run/runvdr.pid mehr

  • Hi,


    nach dem ich seit längerem mal wieder ein Systemupdate gemacht habe (Debian Jessie) und dabei diverse Debian-Pakete und aber auch vdr auf die neueste Version gehoben wurde, legt das init-Script anscheinend kein runvdr.pid in /var/run ab und damit funktioniert mein Suspend-to-RAM-Skript nicht mehr, d.h. der vdr wird beendet, aber nicht runtergefahren und damit funktioniert auch das wieder Hochfahren und Starten nicht mehr :(. Da ich sonst an keiner Stelle etwas verändert habe: Gab es eine Systemänderung, von der ich nichts mitbekommen habe?! Und was kann ich dagegen tun?!


    Gruß,
    HeinB


    PS: Ich habe von vdr:amd64 (2.2.0-1~etobi4, 2.2.0-2~etobi3) aktualisiert. Da scheint sich irgendwas verändert zu haben ...

    Gruß,
    HeinB

    The post was edited 1 time, last by HeinB ().

  • Gute Frage: Ich sag mal Standard-Jessie, sollte also systemd sein. Aber das sollte sich ja nicht automatisch ändern, oder? Bisher lief es ja ohne Probleme.


    Update: Ein Downgrade hat wieder alles ins Lot gebracht - also entweder ich hab da irgendwas verpasst anzupassen, oder es ist etwas anderes, oder es ist ein Bug...
    Möglicherweise hat das was mit dem neuen Verzeichnis /etc/vdr/conf.d zu tun?!

    Gruß,
    HeinB

    The post was edited 1 time, last by HeinB ().

  • Mit dem Update wird der VDR über ein Systemd-Unit-File gestartet, nicht mehr via /etc/init.d/vdr und start-stop-daemon.
    Du müsstest entweder dein Skript an Systemd anpassen oder ein eigenes service-File anlegen, welches den VDR mit "-d" (=fork) startet und ein Pid-File anlegt.


    Wie schaut denn dein Suspend-To-RAM-Skript aus?


    Tobias

  • Hallo Tobias,


    Mit dem Update wird der VDR über ein Systemd-Unit-File gestartet, nicht mehr via /etc/init.d/vdr und start-stop-daemon.
    Du müsstest entweder dein Skript an Systemd anpassen oder ein eigenes service-File anlegen, welches den VDR mit "-d" (=fork) startet und ein Pid-File anlegt.


    Ich denke, dass ich ein zweigeteiltes Problem habe:

    • Scheint die /etc/default/vdr nicht seit der 2.2.0-2 abgearbeitet worden zu sein, welche ja das SHUTDOWNCMD beinhaltet (s.u.). Deswegen wurde das auch nicht ausgeführt.
    • Habe ich zusätzlich noch ein acpi-button-Skript, was beim Drücken des Power-Buttons am Rechner ausgeführt wird. Hier wird in der Tat auf die PID getriggert. Der relevante Teil des Skriptes sieht so aus:
      Code
      1. # If VDR is running
      2. if test -f /var/run/runvdr.pid
      3. then
      4. logger "ACPI power button pressed while vdr was running - powering off vdr"
      5. /usr/bin/svdrpsend HITK POWER
      6. else
      7. logger "ACPI power button pressed when vdr was not running - shutting down"
      8. /sbin/shutdown -h now "Power button pressed"
      9. fi


      Hier wäre es schon sinnvoll das anzupassen, auch wenn mir momentan der Ansatz dafür fehlt. Wie kann ich denn in einem Skript prüfen, ob ein systemd-gesteuerter Dienst gerade läuft oder nicht?


    Wie schaut denn dein Suspend-To-RAM-Skript aus?


    Naja, was heisst hier Skript :)?! Ich kann Dir nicht genau die Quelle sagen (es ist nicht auf meinem Mist gewachsen - Update: Das ist ja von Dir :)), aber hier ist "meine" Lösung:


    In /etc/default/vdr steht

    Code
    1. ENABLE_SHUTDOWN=1
    2. SHUTDOWNCMD="sudo /usr/sbin/pm-suspend"


    In /etc/pm/sleep.d/10_vdr steht


    Interessant ist, dass ja eigentlich laut /etc/systemd/system/multi-user.target.wants/vdr.service die Datei /usr/lib/vdr/merge-commands.sh aufgerufen wird, welche wiederrum die Datei /usr/lib/vdr/config-loader.sh aufruft, welche eigentlich die Variable SHUTDOWNCMD aus /etc/default/vdr auslesen und berücksichtigen sollte. Aber, das ist jetzt erstmal meine These, dem ist nicht so. Denn wie kann ich mir sonst erklären, dass bei einem Standby der VDR beendet, aber nicht wieder gestartet wird beim Resume?


    Update[erneut]: Wer hier über die Suche gelandet ist, der sollte sich zu dem Thema e-tobi.net anschauen - es wurde einiges umgestrickt.

    Gruß,
    HeinB

    The post was edited 2 times, last by HeinB ().

  • Hallo,
    das Shutdown-Skript kannst du in der /etc/vdr/conf.d/00-vdr.conf setzen (Argument -s cmd), vgl. Manpage des VDR:

    http://www.vdr-wiki.de/wiki/index.php/Vdr(1)#OPTIONS[/url]]

    Code
    1. -s cmd, --shutdown=cmd
    2. Call cmd to shutdown the computer. See the file INSTALL for more information.


    Und statt nach der .pid-Datei zu sehen, könnte man z.B. auch auswerten, ob der SVDRP-Befehl erfolgreich abgesetzt werden kann oder fehlschlägt:

    Code
    1. /usr/bin/svdrpsend HITK POWER && \
    2. logger "ACPI power button pressed while vdr was running - powering off vdr" || \
    3. (logger "ACPI power button pressed when vdr was not running - shutting down" && \
    4. /sbin/shutdown -h now "Power button pressed")

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo seahawk1986,


    das Shutdown-Skript kannst du in der /etc/vdr/conf.d/00-vdr.conf setzen (Argument -s cmd), vgl. Manpage des VDR:

    Leider klappt das so nicht - liegt vermutlich daran, dass ich ja "sudo /usr/sbin/pm-suspend" ausführen möchte (also keinen einfachen Befehl, sondern Befehl mit Parameter). Zumindest erhalte ich die Fehlermeldung


    Code
    1. executing '"sudo /usr/sbin/pm-suspend" ANDERERQUATSCH'
    2. Sep 16 09:45:22 vdr-server vdr[9395]: sh: 1: sudo /usr/sbin/pm-suspend: not found

    Parameter "-s" ist also kein adäquater Ersatz für die /etc/default/vdr-Variable SHUTDOWNCMD - so scheint es zumindest.


    Selbst wenn ich das sudo-Kommando in ein Skript wiederrum reinschreibe und dieses mit dem Parameter "-s" triggere, wird zwar vdr beendet, aber der Rechner geht nicht in Standby - was er aber tut, wenn ich das Paket downgrade - hier kann also nicht das pm-utils kaputt sein, sondern irgendwas ist mit dem vdr los.


    Und statt nach der .pid-Datei zu sehen, könnte man z.B. auch auswerten, ob der SVDRP-Befehl erfolgreich abgesetzt werden kann oder fehlschlägt:

    Code
    1. /usr/bin/svdrpsend HITK POWER && \
    2. logger "ACPI power button pressed while vdr was running - powering off vdr" || \
    3. (logger "ACPI power button pressed when vdr was not running - shutting down" && \
    4. /sbin/shutdown -h now "Power button pressed")


    Schöner Ansatz - das wird auf jeden Fall getestet. Danke!

    Gruß,
    HeinB

    The post was edited 1 time, last by HeinB ().

  • Hallo,


    Worum geht es dir bei deiner Prüfung, ob der VDR läuft? Sollte ja nicht der Regelfall sein, dass der VDR nicht läuft. Wenn es um einen Option zum "Notausstieg" im Falle des Falles geht, dann könntest du dir auch das hier mal anschauen:


    http://projects.vdr-developer.org/projects/vdrpbd


    Ach - das ist eigentlich ganz einfach: Wenn der VDR läuft und der Powerknopf am Rechner gedrückt wird, dann soll der VDR auch korrekt heruntergefahren werden (siehe ACPI-Wakeup) und die Shutdown-Regeln des VDRs sollen greifen (in meinem Fall: Suspend-to-RAM). Ist der VDR aber nicht an, dann kann der Rechner auch richtig heruntergefahren werden.


    Dein Tool schau ich mir auf jeden Fall mal an - aber ich denke das bestehende Konstrukt ist recht einfach anzupassen. Danke aber trotzdem.

    Gruß,
    HeinB

    The post was edited 1 time, last by HeinB ().

  • Parameter "-s" ist also kein adäquater Ersatz für die /etc/default/vdr-Variable SHUTDOWNCMD - so scheint es zumindest.


    Benutze mal den Pfad zu sudo, liegt das in /sbin oder irgendwo?


    Lars.

  • Hallo Lars,



    Benutze mal den Pfad zu sudo, liegt das in /sbin oder irgendwo?


    Ich komm jetzt gerade an das System nicht ran, aber ich denke, das das auch nur eine Korrektur ist, die nicht zum letztendlichen Ziel führen wird, denn: Ich habe bereits die Zeile "sudo /usr/sbin/pm-suspend" in ein "Skript" eingefügt und dann das Skript via "-s" in den VDR eingebunden. Dann klappt zwar der Aufruf von pm-suspend, aber es wird nicht richtig heruntergefahren, d.h. es wird zwar der Dienst vdr beendet, aber dann wird das System nicht in Suspend-to-RAM geschickt sondern bleibt an. Somit kann ACPI-Wakeup auch nicht den VDR wieder starten und eine geplante Aufnahme ausführen. Aber, wie bereits schon gesagt, mache ich ein Paket-Downgrade von vdr, dann funktioniert es. Irgendwo muss also beim umgestellten vdr-Paket der Wurm drin sein, oder?

    Gruß,
    HeinB

  • Parameter "-s" ist also kein adäquater Ersatz für die /etc/default/vdr-Variable SHUTDOWNCMD - so scheint es zumindest.

    Ja, der Unterschied ist, dass dann der vdr-shutdown.wrapper und die Shutdown-Hooks nicht genutzt werden und der Befehl dadurch nicht automatisch als root ausgeführt wird.


    Leider klappt das so nicht - liegt vermutlich daran, dass ich ja "sudo /usr/sbin/pm-suspend" ausführen möchte (also keinen einfachen Befehl, sondern Befehl mit Parameter). Zumindest erhalte ich die Fehlermeldung

    Code
    1. executing '"sudo /usr/sbin/pm-suspend" ANDERERQUATSCH'
    2. Sep 16 09:45:22 vdr-server vdr[9395]: sh: 1: sudo /usr/sbin/pm-suspend: not found


    Wie sieht es mit "/usr/bin/sudo /usr/sbin/pm-suspend" aus?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, der Unterschied ist, dass dann der vdr-shutdown.wrapper und die Shutdown-Hooks nicht genutzt werden und der Befehl dadurch nicht automatisch als root ausgeführt wird.


    Ja, aber das war vorher auch nicht der Fall, weswegen ich, wie Tobias das auch in seinem Blogpost geschrieben hat, dem vdr via visudo volle Rechte auf /usr/sbin/pm-suspend gegegeben habe.



    Wie sieht es mit "/usr/bin/sudo /usr/sbin/pm-suspend" aus?


    Der Vollständigkeit habe ich das auch nochmal ausprobiert, aber die Fehlermeldung bleibt die gleiche - einen Workaround habe ich ja weiter oben schon beschrieben (Befehl kommt in eigenes Skript), aber es beseitigt ja nicht das eigentliche Problem: Es wird nicht korrekt heruntergefahren. Aber ich habe ein paar mehr Tests gemacht. Ich habe mal den vdr-shutdown.wrapper mit der Option "-s" eingebunden und auch hier wird pm-suspend (wie in SHUTDOWNCMD definiert) ausgeführt. Aber irgendetwas führt nach dem Ausführen von pm-suspend dazu, dass sich zwar der vdr beendet, aber nicht pm-suspend das System herunterfährt. Ich würde ja selber glauben wollen, dass es an pm-utils liegt, aber dagegen spricht, dass es mit einem Downgrade von vdr wieder funktioniert. Ich werde jetzt systematisch probieren, aber es ist wahrscheinlich die Nadel im Heuhaufen, die ich suche, weil ich nicht genau weiß, wo ich suchen muss.

    Gruß,
    HeinB

  • Hallo an alle, die immernoch durchhalten :),


    ich habe jetzt nochmal Folgendes probiert:


    • $SHUTDOWNCMD /usr/sbin/pm-suspend eingebunden und Ausschaltbefehl via /usr/bin/svdrpsend HITK POWER gesendet - vdr2.2.0-2_etobi3 startet pm-suspend und beendet sich selbst - der Rechner bleibt aber an. Dabei konnte ich sehen, dass bei pm-suspend zwar der Hook für den vdr angetriggert wird, danach pm-suspend aber gleich stoppt.
    • vdr ist gestartet und Ausschaltbefehl als root auf der CLI via /usr/sbin/pm-suspend gegegen. vdr2.2.0-2_etobi3 beendet sich (ohne pm-suspend auszuführen) und der Rechner wird korrekt heruntergefahren.


    Eine Idee: Kann es vielleicht sein, dass pm-suspend mit der neuen Art des Startens über systemd sich selbst beim Beenden von vdr abschiesst, weil der Triggerprozess vom vdr selber kommt, den es ja gerade beendet?!

    Gruß,
    HeinB

  • Wenn der Shutdown 00-vdr.conf via "vdr-shutdown.wrapper" ausgeführt wird, dürfte da eigentlich kein Unterschied zur alten Version bestehen.
    $SHUTDOWNCMD wird wia "eval $SHUTDOWCMD &" gestartet.

    Versuch es mal mit:


    Code
    1. SHUTDOWNCMD="sudo /usr/sbin/pm-suspend >/tmp/pm-suspend.log 2>&1"


    ...und schau dann mal, ob du irgendwelche Fehlermeldungen im Log siehst.



    Tobias

  • Eine Idee: Kann es vielleicht sein, dass pm-suspend mit der neuen Art des Startens über systemd sich selbst beim Beenden von vdr abschiesst, weil der Triggerprozess vom vdr selber kommt, den es ja gerade beendet?!


    Das klingt zielführend. Wenn der Hauptprozess einer systemd-unit sich beendet, dann werden auch alle Kindprozesse abgeschossen.
    Das Suspend müsste in eine eigene Unit, die dann vom vdr gestartet wird, so dass der vdr sich dann beenden kann.


    Lars.

  • Hallo Tobias,


    Wenn der Shutdown 00-vdr.conf via "vdr-shutdown.wrapper" ausgeführt wird, dürfte da eigentlich kein Unterschied zur alten Version bestehen.
    $SHUTDOWNCMD wird wia "eval $SHUTDOWCMD &" gestartet.

    Versuch es mal mit:


    Code
    1. SHUTDOWNCMD="sudo /usr/sbin/pm-suspend >/tmp/pm-suspend.log 2>&1"


    ...und schau dann mal, ob du irgendwelche Fehlermeldungen im Log siehst.


    Nun, ich hab in pm-suspend eh ein Debug eingeschalten und kann deshalb sagen, dass ja laut des Skriptes von Dir zuerst der Dienst beendet und dann die Module entladen werden sollen. Im Falle eines Aufrufs von pm-suspend durch vdr sehe ich aber im Logfile nur das Beenden des Dienstes. Wenn ich pm-suspend aber direkt aufrufe, dann werden auch die Module entladen. Ich kann die Logfiles gerne nachreichen, wenn gewünscht. Vielleicht stimmt ja meine Annahme, die zumindest Lars nicht ganz verworfen hat?! :]

    Gruß,
    HeinB

  • Hallo Lars,


    Das klingt zielführend. Wenn der Hauptprozess einer systemd-unit sich beendet, dann werden auch alle Kindprozesse abgeschossen.
    Das Suspend müsste in eine eigene Unit, die dann vom vdr gestartet wird, so dass der vdr sich dann beenden kann.


    Ok, das freut mich - aber leider muss ich hier aussteigen. Ich habe keine Ahnung wie man sowas gestalten könnte. Hast Du eine Idee?

    Gruß,
    HeinB

  • Hab leider noch nicht so richtig ein System mit systemd am laufen, aber wenn seahawk1986 hier noch mal reinschaut, der kennt sich da aus.
    Kann auch sein, dass Suspend mit systemd im Allgemeinen anders behandelt werden kann, so dass man so ein Script nicht mehr braucht, sondern an einer Stelle bestimmt, was allgemein bei einem Suspend passieren soll.


    Müsste ich aber auch erst nachlesen, wenn ich Zeit habe.


    Lars.

  • Ich nutze den Standby-Modus auf meinem VDR mit Systemd zwar schon länger nicht mehr (mit SSD bootet der schnell genug) - aber prinzipiell kann man den Suspend auch über "systemctl suspend" auslösen. Damit dann auch die Skripte von pm-utils ausgeführt werden (da gibt es wohl noch keinen eingebauten Trigger im Paket: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745848 ), könnte man sich gemäß http://www.freedesktop.org/sof…temd-suspend.service.html z.B. so ein Skript im Ordner /usr/lib/systemd/system-sleep/ anlegen, das das nachholt:

    Shell-Script
    1. #!/bin/sh
    2. case $1 in
    3. pre)
    4. for file in /etc/pm/sleep.d/*; do /bin/sh "$file" suspend; done
    5. ;;
    6. post)
    7. for file in /etc/pm/sleep.d/*; do /bin/sh "$file" resume; done
    8. ;;
    9. esac

    Oder man erstellt sich eigene Services, die vor und nach dem sleep.target ausgeführt werden sollen: https://wiki.archlinux.org/ind…er_management#Sleep_hooks

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)