Frage an die systemd-Experten hier

    Hallo,


    ich betreibe seit geraumer Zeit einen Server & Client. Der Server hat hier das Video-Verzeichnis. Und wird vom Client bei dessem Start geweckt. Das Video-Verzeichnis bindet der Client per systemd-Unit ein.

    Bisher hat das auch funktioniert, dass der Client mit dem VDR-Start gewartet hat bis des Video-Verzeichnis vom Server verfügbar war. Sonst würde der VDR ja nicht starten.

    Seit ein paar Tagen funktioniert das eben nicht mehr und vdr auf dem Client wartet nicht mehr.


    Gibt es hier noch irgendwo eine Stellschraube?

    In der vdr.service habe ich es auch schon mit After=srv.mountprobiert, was nicht half.

    Mit einem Requires=srv.mountgibt es eine Fehlermeldung mit fehlerhafter Abhängigkeiten.


    Hat da jemand eine Idee?


    Gruss.

    Markus

    Ich weiß nicht, was weckt den Server hier? Da müßte doch noch ein Dienst laufen, etwa einer, der wakeonlan an die MAC des Servers sendet?

    Ja klar. Der Server wird ja auch schön geweckt. Der Client ist nur schneller als der Server, womit das Videoverzeichnis noch nicht verfügbar ist.

    Aber das hat ja bisher mit der config funktioniert, hier hatte der VDR mit dem Start immer gewartet bis des Videoverzeichnis da war.


    Hier die Unit, die den Server weckt:

    Ich laß einen ähnlichen Service bei mir ein Shellscript aufrufen, worin i.w. steht:

    Code
    until ping -4 -c1 192.168.0.30 >/dev/null 2>&1
do
wol 00:23:24:aa:8d:d0
sleep 3
done

    D.h. erst wenn das aufgeweckte Gerät pingbar ist (Service-Timeout ist auf 2min gesetzt, sodaß das nicht in alle Ewigkeit läuft), geht es weiter.

    Wenn der Server schon online ist, auch verzögerungsfrei.

    Notfalls auch ein eigenes Target erstellen für "server-online" und das referenzieren im mount-Service.

    Dann machst du eine ähnliche Unit, die eben nur darauf testet, dass eine bestimmte (bekannte) Datei existiert und davon dann den vdr abhängig.

    Aber warum funktioniert es denn nicht, in der vdr.service ein After=srv.mounteinzufügen, das sollte doch reichen, dass hier auf die Unit gewartet wird, oder?

    After= heißt nur, daß die referenzierte Unit aufgerufen/abgearbeitet wurde - ob mit oder ohne Erfolg.

    Wie ich das verstehe, kann, wenn das srv.mount nach dem einmaligen wakeonlan gleich aufgerufen wird, durchaus das noch nicht erfolgreich (gewesen) sein.

    Gibts dafür nicht genau "wait-for"? Kenn mich da aber nicht wirklich aus.

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Da hab ich gestern ein Beispiel, wo der ddbridge mal wieder nicht wollte:

    und klar, die Jobs "wait-for ..." sind trotzdem finished.

    Ich lasse dann im do_startvdr.sh auch prüfen, ob alle /dev/dvb/xxx vorhanden sind bzw. wenn gar nicht erst das /dev/dvb da ist .... dann wird die Kiste mit acpi-wakeup 3 Min später komplett runtergefahren, neuer Versuch. Klappt dann.

    Also hilft auch wait-for ... nicht, wenn das Device nicht (rechtzeitig) hochkommt, zudem ist das wait-for... Unit auch nur eine Ansammlung von "After="-Statements :)

    Wieder was gelernt - danke!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Zitat von hopsi

    Versuch doch mal ein Requires=srv.mount zusätzlich zum After=


    Christian

    Das hatte ich auch schon, dann startet der vdr.service nicht und meckert irgendwelche fehlerhafte dependencys an.

    Eigenartigeweise hat das ja bis vor einer Weile alles problemlos funktioniert.

    War der Server nicht schon an, dann hat der Client mit dem VDR-Start brav gewartet bis der Mount verfügbar war. War der Server schon an, ging auch der Client-Start schneller.

    Scheinbar muss es irgendein Update gewesen sein, dass sich das Verhalten nun geändert hat.

    In letzter Zeit hatte ich eigentlich nur den Kernel auf 5.15.6 hochgezogen. Irgendwann merjte ich halt, dass der Client mit dem yavdr-Splash stehen bieb und es nicht mehr weiterging.

    Es könnte sein, dass du in den linear wachsenden Timeout läufst, der bei NFS vorgesehen ist - retry=10000 besagt ja, dass er es bis zu 10.000 Minuten versuchen soll, der Default-Wert für retrans ist 3 (das ist die Zahl der Wiederholungen eines NFS-Befehls, wenn der Server nicht antwortet) und der default-Wert für timeo ist 600 (also 60 Sekunden - vgl. man 5 nfs) - wenn er also einen Mount-Versuch macht, probiert er drei Kontaktaufnahmen im Abstand von einer Minute, dann wartet er bei jedem weiteren Mount-Versuch eine Minute länger zwischen den Versuchen - angenommen der 1. Mount-Versuch klappt nicht, dann wartet er 3x eine Minute, dann klappt der zweite Mount-Versuch nicht, er wartet 3x zwei Minuten bevor er einen weiteren Versuch startet und das geht so weiter, bis er Versuche im maximal vorgesehenen Abstand von 5 Minuten macht.


    Die Mount-Option bg wird gemäß der Manpage zu systemd.mount ebenfalls speziell behandelt:

    Zitat von man systemd.mount

    The NFS mount option bg for NFS background mounts as documented in nfs(5) is detected by systemd-fstab-generator and the options are transformed so that systemd fulfills the job-control implications of that option. Specifically systemd-fstab-generator acts as though "x-systemd.mount-timeout=infinity,retry=10000" was prepended to the option list, and "fg,nofail" was appended. Depending on specific requirements, it may be appropriate to provide some of these options explicitly, or to make use of the "x-systemd.automount" option described below instead of using "bg".


    Ich würde mal versuchen das stattdessen mit systemd.automount zu machen (dann läuft man nicht in das Problem, dass die Mount-Unit vom remote-fs.target aktiviert wird und zusätzlich - weil das vermeidet den nfs-mount Befehl unnötig früh auszuführen (ähnlich wie @wmauter das vorgeschlagen) - auf den Server zu warten:

    Code: /etc/systemd/systemd/vdr.service.d/nfs-mount.conf
    [Unit]
After=wake-server.service
Requires=wake-server.service

    Und in der fstab kann man das dann so eintragen (wenn man es mit Mount-Units machen wollte, bräuchte man neben der Mount-Unit zusätzlich noch eine automount-Unit):

    Code
    192.168.178.10:/srv /srv nfs retry=10000,timeo=10,soft,rw,nosuid,nodev,noatime,_netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=0,x-systemd.idle-timeout=0,noauto,wsize=8192,rsize=8192 0 0

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

    Ach ja: die avahi-linker.service sollte man dann natürlich deaktiveren, damit niemand zu früh versucht auf /srv zuzugreifen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Wenn du willst kannst du die Mount-Unit und die Automount-Unit natürlich auch selber anlegen, der Weg über den systemd-fstab-generator ist halt oft bequemer, weil man nur eine Datei dafür anfassen muss.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    alles klar. danke werde ich die tage mal mit deinem code versuchen.

    mich wundert halt nur, dass es bisher mit meinen settings so klappte.

    ich habe auch noch am server einen externe usb-platte die dort nach /srv/vdr/video/FILME eingehängt ist. deren mount-unit hängt inzwischen auch, obwohl dieselben einstellugen wie die srv.mount.

    Hallo Alexander,


    mit deinem Code hat es jetzt geklappt. Danke.

    Jetzt habe ich noch das Problem, dass der zweiter Mount in der fstab nicht immer funktioniert.

    Code
    192.168.178.10:/srv/vdr/video/FILME /srv/vdr/video/FILME nfs retry=10000,timeo=10,soft,rw,nosuid,nodev,noatime,_netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=0,x-systemd.idle-timeout=0,noauto,wsize=8192,rsize=8192 0 0

    Mal klappt es beim Start und mal nicht. Eine Ahnung woran das liegen könnte?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden