Posts by lopiuh

    Bist du sicher, dass sich da der X-Server verabschiedet und nicht nur alles durcheinander kommt, weil du ihn ohne "-noreset" statest und dann Probleme auftreten, wenn das lokale sxfe-Frontend als einziges Fenster mal crasht/geschlossen wird?

    Code
    1. #
    2. # Function that starts X.
    3. #
    4. start() {
    5. start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --exec /usr/bin/X -- $DISPLAY $TERMINAL -br -nolisten tcp
    6. if [ $? -gt 0 ]; then
    7. echo "Error starting X-Server."
    8. exit $?
    9. fi
    10. }


    Den Parameter "-br" habe ich in der Manpage von X nicht gefunden...

    oha, gut "-noreset" aufzunehmen dürfte vmtl. nicht schaden. [EDIT 1 START] Es ist allerdings so, dass der fehlende Parameter scheinbar nichts ausmacht. VDR beendet und X läuft weiter, VDR gestartet und sxfe und Bild wieder da. [EDIT 1 ENDE]


    Das "-br" gibt es zumindest auf http://www.x.org/archive/X11R7.5/doc/man/man1/Xserver.1.html als "sets the default root window to solid black instead of the standard root weave pattern."



    Auf systemd wechseln...


    Lars


    :] ja, hab ich schon in Auftrag gegeben, wird für jessie (debian) gemacht :D Ich tu mir das selber noch nicht an, da garantiert "Sometimes it is necessary to investigate why systemd hangs on startup or on reboot/shutdown." ("https://wiki.debian.org/systemd"). Aber mit jessie auf jeden Fall...

    Yep, sinnvoll, jeweils in beiden ganz oben eingebaut, so können wir wenigstens sehen, ob der init.d beim sporadischen "boot-Nichtstart" aufgerufen und vor dem ersten regulären log absäuft, oder der init-Aufruf gar nicht erfolgt.


    Ich berichte...


    Bericht:
    [EDIT 1]
    Er säuft in /etc/init.d/vdr ab. Ganz dreckig am Ende von /etc/init.d/vdr mal ein reboot aufgenommen und ihn so in einen bootloop geschickt. Siehe da 10 Minuten später: Zielzustand erreicht (ein Logeintrag "etc/init.d/vdr script gestartet" und dann nichts mehr). Was mir bei den erfolgreichen Starts aufgefallen ist, dass die Protokollierung aufgrund (daemon, parallelisierung?) nicht chronologisch erfolgt. Also im Log ist die Reihenfolge:
    - "etc/init.d/vdr script gestartet"
    - "shutdown[2940]:"
    - usr/sbin/runvdr gestartet
    - vdr: [2958] VDR version 2.0.3 started


    Gut nochmal in Erinnerung zu rufen, Vorsicht bei der Interpretation der vermeindlich protokollierten Reihenfolge. Dann wollen wir mal und eine Handvoll Logausgaben einbauen und hoffen, dass ich die Katze nicht bei der Messung töte.


    [EDIT 2]


    hmm ist ja schon klar, was es sein wird, eine racecondition, die halt auf manchen Systemen zum Tragen kommt und auf anderen nicht, da in Abhängigkeit der HW/SW ja immer unfreiwillig irgendwelche Startzeiten von einzelnen Komponenten anders sind. Natürlich werden die Logeinträge die Laufzeiten und somit das System verändern und den Test scheitern lassen :mua


    Was mir schon auffällt und oft ist es ja genau das, was am Ende auch rauskommt:

    Code
    1. Jul 17 21:39:34 mediapc acpid: client connected from 2851[0:0]
    2. Jul 17 21:39:34 mediapc acpid: 1 client rule loaded


    kommt in den Logs direkt nach Start der /init.d/vdr (aber nicht dadurch ausgelöst?!). Ob das den vdr-start tangiert, wenn das mal früher oder später durchgeführt wird?
    EDIT: die komen vom X Start (plain-x-server von e-tobi)


    [EDIT 3]


    So ich glaube ich habs. Ich (re)starte bislang den X-Server in der init.d/vdr (http://e-tobi.net/blog/files/plain-xserver) und mache ein exit, wenn das nicht klappt und das passiert dann halt ab und zu. Ist natürlich dämlich den vdr erst gar nicht zu starten, wenn X nicht gestartet werden konnte :wand Also bastel ich mir jetzt mal einen watchdog für X oder nehme wieder nodm (http://www.enricozini.org/sw/nodm/)

    Hi,


    bevor auch ich den Thread wieder ruhen lasse, sei hier festgehalten (Debian wheezy) Aufruf von /usr/bin/updatedb.mlocate (mit unangepasster config) provozierte den Fehler. Mit angepasster config bislang stabil. (EDIT: habe mhddfs allerdings nicht im Dauereinsatz, sondern nur für das Zusammenkleben von Backupsets)


    Ciao


    lopiuh

    Hi,


    ja Signatur ist aktuell.


    yep, es ist beim Nichtstart überhaupt kein VDR-Eintrag im Log. Alles andere ist in beiden Logs nahezu identisch. Nahezu, da jeder Start ja doch mal eine andere Reihenfolge in der Inititialisierung der ACPI Komponenten und so hat. In jedem Fall ist der DVB-Treiber geladen, KEINE Fehlermeldungen oder wesentlich geänderte / neue Einträge oder so. Ich hänge die Logs mall an, Vielleicht fällt Euch ja doch was auf ...


    Daaaaanke


    Gruß


    lopiuh

    Moin,


    mag mir jemand helfen?


    Wheezy, e-Tobi (2.0.3) xineliboutput, 2x ngene DVB-S, keine Graka (onboard, CPU encoding), acpi poweron (timergesteuert), keine eigenen Patches / kein CAM


    sporadisch (ca jeder 20. Boot) startet VDR nicht.Im syslog diff eines erfolgreichen und eines nicht erfolgreichen Starts gibt es keine Auffälligkeit. Es fehlen einfach die Einträge ab dem Moment, ab dem der VDR sonst startet und sich protokollieren würde. Es sind keine Fehlermeldung, die darauf hindeuten, dass irgendwas beim VDR-Start schiefgeht. Blöd, da die Kiste in diesem Zustand einfach nichts macht. Das weckt das Begehren nach einem weiteren Watchdog, da der VDR Watchdog natürlich auch nicht läuft :rolleyes: Erstmal will ich aber ergründen, warum er "so häufig" nicht hochkommt :wow


    Installation ist sauber (minimale, scriptgesteuerte Installation). Phänomen seit Boardmodellwechsel (ein schnelleres,INTEL C2D) vielleicht gibts doch irgendeine racecondition beim Start?


    Tips, wo es klemmen könnte?


    Gruß lopiuh



    EDIT: manueller /etc/init.d/vdr stop|start ist unauffällig, wobei da fällt mir ein, ich hab die initdatei angepasst, um X dort zu starten hmmm, müsste aber unkritisch sein, es ist ja auch 0 im syslog, was auf einen (sporadisch) überhaupt nicht stattfindenden Start der init.d Datei hindeutet. ;(

    Hi mini,


    oh ja, die Sorge hatte ich auch bei mir. Hab mir dann aber gesagt, wer macht denn sowas, sind ja nicht bei Win hier :mua

    Hi,


    yep, jetzt wo Du es sagst, fällt es mir wieder ein. Usermod achtet darauf, dass der user, dessen uid Du ändern willst, nicht eingeloggt ist. Ist ja nett, das man da vor dem Risiko von Inkonsistenzen geschützt wird. Andernfalls würde während / kurz nach dem Script der laufende user mit seiner alten uid wieder files erzeugen können. Ggf wie Du schreibst, die Dienste beenden oder im entsprechenden runlevel starten, wenn man kein root hat, wirds natürlich schwierig.


    Ciao und viel Erfolg


    Lopiuh

    Moin,


    storebackup hat mir jetzt auch bei meinem VDR zu bis zu 39 Tage Backup verholfen auf einem nur fürs Backup eingesetzten 6TB NAS :wow


    Einfach sehr genial das Teil. (http://storebackup.org/)


    Das gute daran: Überwachung von bit rot, da src und backup verify gegen md5-Datenbank (flat file), die beim Backup aufgebaut wird. Kann das Teil nicht hoch genug loben.


    Ciao



    Lopiuh

    Hi,


    passt vielleicht nicht ganz, aber hier mal meine aufbereitete (auf einer yavdr-Lösung basierenden) bash-Lösung.



    ###############################################
    # uid gid vom VDR anpassen (Korrektur der Basispaketinstallation)
    ###############################################
    #
    #
    old_uid=`cat /etc/passwd | awk -F":" '/VDR user/ {print $3}'`
    old_gid=`cat /etc/passwd | awk -F":" '/VDR user/ {print $4}'`
    new_uid=4242
    new_gid=4242
    find_opts='/ -xdev -ignore_readdir_race'
    if [ "$new_uid" != "$old_uid" -o "$new_gid" != "$old_gid" ] ; then
    if [ "$new_uid" != "$old_uid" ] ; then
    echo "uid VDR anpassen: $old_uid->$new_uid..."
    usermod -u $new_uid vdr
    find $find_opts -uid $old_uid -exec chown -h vdr {} \;
    fi
    if [ "$new_gid" != "$old_gid" ] ; then
    echo "gid VDR anpassen: $old_gid->$new_gid..."
    # Remember files that have set setuid bit
    suid_files=`find $find_opts -gid $old_gid -perm -4000`
    groupmod -g $new_gid vdr
    find $find_opts -gid $old_gid -exec chgrp -h vdr {} \;
    # Restoring setuid bits
    for f in $suid_files; do
    echo "Adjusting setuid bit of $f"
    chmod 6750 $f
    done


    fi
    fi



    Gruß lopiuh

    Hi,


    in der /var/lib/yavdrdb.hdf ist die uid gid vom vdr-user redundant abgelegt. Muss man die per Hand aktualisieren, wenn man seine uid/gid vdr im System geändert hat? Wofür wird die uid verwendet (warum nutzt ein etwaig verwendender Prozess nicht einfach den user vdr/groups / pqasswd?)


    Gruß Lopiuh


    Ändern der UID/GUD:
    (korrigiertes https://github.com/yavdr/yavdr…lob/master/change-vdr-uid)

    old_uid=`cat /etc/passwd | awk -F":" '/VDR user/ {print $3}'`
    old_gid=`cat /etc/passwd | awk -F":" '/VDR user/ {print $4}'`
    new_uid=4242
    new_gid=4242
    find_opts='/ -xdev -ignore_readdir_race'
    # Remember files that have set setuid bit
    suid_files=`find $find_opts -gid $old_gid -perm -4000`
    usermod -u $new_uid vdr
    groupmod -g $new_gid vdr
    find $find_opts -uid $old_uid -exec chown -h vdr {} \;
    find $find_opts -gid $old_gid -exec chgrp -h vdr {} \;
    # Restoring setuid bits
    for f in $suid_files; do
    echo "Adjusting setuid bit of $f"
    chmod 6750 $f
    done

    Hi,


    OberlererAN EDIT: leerer Oberlehrer, sechs setzen :wand


    die Hauptmotivation des Threads war zwei Systeme (OMV und yaVDR z. B.) zu vereinen (beide "iso orientiert") und nicht OMV auf einem Debian fork / derivat zu installieren.


    OberlererAUS :D



    Gruß


    Lopiuh

    Moin!


    Keine Ahnung, wer das war, aber die gleiche UserId auf allen vdrs im Haushalt vereinfacht so einiges... :)


    Lars.

    Ja, genau beim Angleichen der UID/GUIDs bin ich ja darauf gestoßen ;-) zum Angleichen der u/gid gibts ja auch einfache scripte und sogar was vorgefertigtes bei yavdr, wodurch ich darauf aufmerksam gemacht wurde ;-), auf die setuid-bit Geschichte zu achten.


    https://github.com/yavdr/yavdr…lob/master/change-vdr-uid
    https://bugs.yavdr.com/issues/873


    Gruß Lopiuh

    Hi,


    ich leg mir immer die Daten, die ich beim Rücksichern (imagebackup, fsarchiver) nicht verlieren will an meinen "Daten-Ort" und symlinke darauf. Unter debian / easyvdr klappt das auch. unter yaVDR 0.5a bekomme ich permission denied. Vom Symptom genau so wie hier beschrieben: https://linuxtv.org/patch/12335/


    Code
    1. 7534] ERROR (tools.c,1526): /mnt/data/gen/relcfg_yavdr/var/lib/vdr/channels.conf.$$$: Permission denied




    Die verzeichnisse haben alle "x" gesetzt, die Datei Channels.conf gehört vdr:vdr. Habe das schon x mal unter anderen Konstellationen (mit der channels.conf) gemacht und x mal gechecked. Ich verstehe es nicht. Hat jemand von Euch die channels.conf (aus /var/lib/vdr) erfolgreich woanders hin verlinkt (mit der VDR 1.7.27)?


    Ich vermute fast, dass es ein Feature der VDR version 1.7.27 ist?


    Gruß Lopiuh

    Zusatz 1:
    mit VDR 2.0.1 dasselbe Verhalten. by the way: eingelogt als vdr geht ein Bearbeiten und Speichern der Datei, auch wenn sie über den Symlink geöffnet wird.


    ls /var/lib/vdr/ch* -lsa
    0 lrwxrwxrwx 1 vdr vdr 33 May 17 19:33 /var/lib/vdr/channels.conf -> /relcfg/var/lib/vdr/channels.conf


    ls /re* -lsa
    0 lrwxrwxrwx 1 root root 26 May 17 17:39 /relcfg -> /mnt/data/gen/relcfg_yavdr

    ls /mnt/data/gen/relcfg_yavdr/var/lib/vdr/channels.conf -lsa
    132 -rw-r--r-- 1 vdr vdr 131476 May 17 22:21 /mnt/data/gen/relcfg_yavdr/var/lib/vdr/channels.conf



    Zusatz 2:
    Was hat es denn mit $$$-Dateien auf sich? Was bewirken hier die Dollarzeichen?


    nano /mnt/data/gen/relcfg_yavdr/var/lib/vdr/channels.conf
    nano /var/lib/vdr/channels.conf
    +Speichern
    funktioniert. aber die Variante mit $$$ angehängt funktioniert nur unter /var/lib/vdr/
    :wow

    LÖSUNG
    Natürlich mein Fehler. Beim Speichern wird eine neue Datei geschrieben und das geht nur, wenn das überliegende Verzeichnis (hier /mnt/data/gen/relcfg_yavdr/var/lib/vdr) auch vdr gehört. Ein chown -R vdr:vdr /mnt/data/gen/relcfg_yavdr/var/lib/vdr und es funzt.


    Ich lasse es mal stehen, falls noch jemand mal genau die $$$ Fehlermeldung im log erhält....



    Danke fürs zuhören :->

    @DaKilla,


    da hast Du recht, so pauschal kann man das nicht sagen. Es kommt aufs/die Detailpaket / -situation an. Aber das Pinning hat nur Auswirkung, wenn Pakete mit demselben Namen in mehreren Quellen vorhanden sind. Wenn also yavdr / Tobi / easyvdr pakete "überschreiben" (also selbst aufnehmen, obwohl die Distro auch so ein Paket hat), dann verlasse ich mich ungerne nur auf den Umstand, dass die Version in der Distro (hier Ubuntu) kleiner ist. Ist natürlich bei ubuntu unwahrscheinlich, dass da auf einmal ein VDR-Paket mit einer höheren Version, als in den yavdr Quellen enthalten, geliefert wird. Aber genau das ist hier passiert, eine größere Version ist aus Ubuntu gekommen und hat den Zuschlag bekommen. Das ist ja auch grundsätzlich ok, wenn aber Pakete gepatched wurden und ursprünglich nicht nur höhere Versionen "durchgereicht" wurde, dann ist pinning unverzichtbar, um nicht auf einmal einen inkompatiblen Paket-Mischmasch zu haben...


    Also in der Tat ist mein Hinweis auf yaVDR wahrscheinlich nicht so zutreffend... es ist aber die Antwort auf die Frage, "wie verhindere ich, dass ein Paket aus Yavdr durch ein Paket aus Ubuntu überschrieben wird" (kwbolte frug: "Wie konnte es dazu kommen und was kann ich dagegen tun")


    Gruß lopiuh