[Testing 0.5] Wenn Aufnahmen vom Server nicht mehr erreichbar stürzt Client ab

ich hatte sowas ähnliches als ich auf eine über avahi gemounteten vdr zugegriffen hab der aber zwischenzeitlich heruntergefahren war - konnte den vdr nur neu starten...

Christian

Quote from dippes

Genau das selbe....liegt das am vdr oder am frondent? Ist doch ein Bug oder?

Was steht denn im Syslog des herunterfahrenden VDR und wie sah die /etc/vdr/lifeguard.conf dabei aus?

also bei meinem Thema mit avahi seh ich das noch einen Hauch anders: mir stellt sich daher die Frage warum der vdr als der andere vdr runtergefahren ist die Aufnahmenliste nicht refreshed und den temporären Server aus selbiger entfernt hat?

lifeguard war selbstredend komplett deaktiviert, es war ja kein Server sondern nur ein anderer vdr über avahi...

Christian

Quote from CKone

mir stellt sich daher die Frage warum der vdr als der andere vdr runterfehfahren ist die Aufnahmenliste nicht refreshed und den temporären Server aus selbiger entfernt hat?

Es könnte ein Timing-Problem mit dem Stoppen des avahi-daemon und der Verfügbarkeit des Netzwerks geben. Wenn am Gegenüber die Netzwerk-Verbindung weg ist, bevor dem Avahi-Daemon gestoppt wird erkennt der lokale avahi-daemon nicht direkt durch einen Broadcast, dass das Gegenüber sich abmeldet, sondern es greift ein Timeout, wenn er eine Zeit lang nichts mehr von dem anderen hört und erst dann weiß auch der avahi-mounter, dass er den NFS-Mount aushängen und den VDR die Aufnahmeliste aktualisieren lassen soll. Wenn man in dem Zeitraum einen Zugriffsversuch über NFS macht, wird das Programm bis zum für den NFS-Mount definierten Timeout (Mount-Option timeo=n) hängen bleiben.

Du könntest mal versuchen mit einem custom Template für https://github.com/yavdr/yavdr…ooks/S99.shutdown/10_main das SHUTDOWNCMD um einen Stop des avahi-daemon zu erweitern, z.B.:

<?cs if:(!?system.shutdown || system.shutdown == "s3") ?> 
if grep -q "mem" /sys/power/state ; then
        echo "SHUTDOWNCMD=\"stop vdr ; stop avahi-daemon; /sbin/initctl --quiet emit --no-wait init-s3\""
fi
<?cs elif:(system.shutdown == "s4") ?>
if grep -q "disk" /sys/power/state ; then
    echo "SHUTDOWNCMD=\"stop vdr ; stop avahi-daemon; /sbin/initctl --quiet emit --no-wait init-s4\""
fi
<?cs elif:(system.shutdown == "s5") ?>
echo "SHUTDOWNCMD=\"stop vdr ; stop avahi-daemon; /sbin/halt -p\""
<?cs elif:(system.shutdown == "reboot") ?>
echo "SHUTDOWNCMD=\"stop vdr ; stop avahi-daemon; /usr/sbin/grub-reboot PowerOff ; /sbin/reboot\""
<?cs /if ?>

Edit: vermutlich ist es besser den VDR vor dem avahi-daemon zu stoppen

Quote from seahawk1986

Wenn man in dem Zeitraum einen Zugriffsversuch über NFS macht, wird das Programm bis zum für den NFS-Mount definierten Timeout (Mount-Option timeo=n) hängen bleiben.

aber wenn wir das auf 10s stellen dann sind doch alle froh, Alex

Quote from seahawk1986

Edit: vermutlich ist es besser den VDR vor dem avahi-daemon zu stoppen

weiß nicht ob der das einfach so mit sich machen lässt: die Platte unmounten die der vdr unter seinen Fitticchen hat...

Christian

Quote from CKone

aber wenn wir das auf 10s stellen dann sind doch alle froh, Alex

Das ist aber nicht so schön, wenn ich mir die Manpage so ansehe:

Quote from man 5 nfs

timeo=n
The time in deciseconds (tenths of a second) the NFS client waits for a response before it retries an NFS request.

For NFS over TCP the default timeo value is 600 (60 seconds). The NFS client performs linear backoff: After each retransmission the timeout is increased by timeo up to the maximum of 600 seconds.

However, for NFS over UDP, the client uses an adaptive algorithm to estimate an appropriate timeout value for frequently used request types (such as READ and WRITE requests), but uses the timeo setting for infrequently used request types (such as FSINFO requests). If the timeo option is not specified, infrequently used request types are retried after 1.1 seconds. After each retransmission, the NFS client doubles the timeout for that request, up to a maximum timeout length of 60 seconds.

retrans=n
The number of times the NFS client retries a request before it attempts further recovery action. If the retrans option is not specified, the NFS client tries each request three times.

The NFS client generates a "server not responding" message after retrans retries, then attempts further recovery (depending on whether the hard mount option is in effect).

Display More

Du kannst das ja mal versuchen: https://github.com/yavdr/vdr-a…master/avahi-mounter#L199

try:
            mountshell = subprocess.Popen(['/bin/mount',
                     '-t', 'nfs',
                     '-o', 'soft,intr,timeo=16,retrans=2',
                     self.remote,
                     self.local])
            mountshell.wait()
        except OSError as (errno, strerror):
                syslog("unable to mount: %s" % strerror)
                return

Für mich ist das ein total unerwünschtes Verhalten, wenn ich eine Aufnahme von einem anderen Rechner ansehe und der dann trotzdem plötzlich herunterfahren darf. Mein Ansatzt ist seit ein paar Monaten der avahi-linker, der autofs5 nutzt: https://github.com/seahawk1986/arch-avahi-linker
Da autofs selbstständig eine nicht genutzte NFS-Freigabe nach einem frei wählbaren Timeout wieder aushängt kann man auch das Lifeguard-Addon für bestehende NFS-Mounts auf allen Rechnern nutzen ohne dass sich die Rechner gegenseitig blockieren. Wenn Interesse besteht suche ich mal raus, wie ich das auf meinem yaVDR eingerichtet habe (ein schönes Paket zu schnüren hat leider nicht so ganz wie gehofft geklappt, daher habe ich das erst mal zu Fuß erledigt).

gib mir mal n Tag um das zu verinnerlichen