Łagodna degradacja SSHFS zamiast zamrażania w przypadku utraty połączenia. Czy to możliwe?

Program innej firmy zapisze pliki w katalogu zamontowanym przez SSHFS. W przypadku utraty połączenia z Internetem program innej firmy prawdopodobnie ulegnie awarii (źle), ponieważ wszystkie programy próbujące uzyskać dostęp do takiego katalogu zamontowanego w SSHFS w takim stanie (gdy nie ma połączenia z Internetem) są umieszczane w czymś, co niektórzy określają jako „nieprzerwany” sen". SSHFS ma opcję automatycznego ponownego połączenia, ale to nie pomaga, ponieważ program innej firmy nadal zawiesi się (i zawiesi), jeśli połączenie zostanie utracone (nawet jeśli po przywróceniu połączenia, SSHFS ponownie zainstaluje katalog). Autofs nie pomoże, w zasadzie chodzi o zachowanie SSHFS w przypadku utraty połączenia. Dlaczego nie może zachowywać się jak udostępniony katalog sieciowy (Samba lub w inny sposób) i po prostu zwrócić błąd wcześniej niż ... nigdy?

Czy istnieją alternatywy dla SSHFS, jeśli SSHFS nie może działać zgodnie z opisem?

Inne informacje:

System operacyjny: używam Ubuntu Linux (12.04 LTS)

— Andrei
źródło

Wyjaśnij, co dokładnie robisz. Wyobrażam sobie, że montujesz zdalny system plików za pomocą sshfs na lokalnej maszynie z Linuksem, prawda? Może podaj swój /etc/fstab? Czy próbowałeś autofs z softopcją?

— terdon

@terdon Program innej firmy zapisze pliki w katalogu zamontowanym przez SSHFS. W przypadku utraty połączenia z Internetem program innej firmy najprawdopodobniej ulegnie awarii (źle). SSHFS ma opcję automatycznego ponownego połączenia, ale to nie pomaga, ponieważ program innej firmy nadal zawiesi się (i zawiesi), jeśli połączenie zostanie utracone (nawet jeśli po przywróceniu połączenia, SSHFS ponownie zainstaluje katalog). Autofs nie pomoże, w zasadzie chodzi o zachowanie SSHFS w przypadku utraty połączenia. Dlaczego nie może zachowywać się jak udostępniony katalog sieciowy (Samba lub w inny sposób) i po prostu zwrócić błąd wcześniej niż ... nigdy?

— Andrei

Dziękujemy za aktualizację, ale prosimy o uwzględnienie jej w swoim pytaniu, ponieważ nie wszyscy czytają komentarze. Dołącz także używane pliki konfiguracyjne. Jaka jest wartość limitu czasu ssh itp.? Nie twierdzę, że znam odpowiedź. Po prostu im więcej informacji masz w swoim pytaniu, tym bardziej prawdopodobne jest, że dostaniesz dobrą odpowiedź. W tej chwili trudno jest zrozumieć, jaka jest dokładnie twoja konfiguracja.

— terdon

@terdon Dzięki, właściwie właściwie prawie całkowicie zastąpiłem moje pytanie.

— Andrei

Dużo lepiej :). Dodaj również używany system operacyjny. Czy to Linux, OSX, inny Unix?

— terdon

Odpowiedzi:

W skrócie: Nie - ponieważ zawieszenie jest spowodowane przez aplikację, awaria sshfs jest wdzięczna - każe aplikacji czekać. - fakt, że aplikacja tego nie szanuje, nie jest winą SSHFS.

Aplikacja zrobiłaby dokładnie to samo, gdyby uzyskiwała dostęp do pliku na nośniku wymiennym, takim jak dysk USB, a ty go usunąłeś. Aplikacja musi przechwytywać i obsługiwać zdarzenia przekroczenia limitu czasu we / wy, zamiast po prostu utknąć w oczekiwaniu na odpowiedź.

— djsmiley2kStaysInside
źródło

Smutny problem. Próbowałem sshfs kilka razy w przeszłości.

Gdy połączenie zostanie utracone, aplikacje uzyskujące dostęp do plików w zamontowanym folderze zawieszają się i zawieszają. Nawet terminale. ALE aplikacje nawet nie wiedzą, że czekają. Jest to coś na poziomie jądra, które nie jest w stanie obsłużyć sshfs, który każe im czekać wiecznie ... nawet odmontowanie nie działa, a czasem nawet zawiesza się, ponieważ zamontowany folder jest jakoś zablokowany na poziomie systemu plików.

Dlaczego tak się nie dzieje po odłączeniu napędu USB?

Ten problem istnieje od lat ...

Automatyczne ponowne połączenie nie pomaga, jeśli po prostu nie możesz ponownie nawiązać połączenia w dowolnym momencie. (W moim przypadku zabrakło kerberos Tickes).

Przepraszam, ale muszę stwierdzić: sshfs jest bezużyteczny!
(z wyjątkiem przypadków, w których połączenie nigdy nie jest tracone)

Zawsze zamiast tego używam scp. Smutny problem

— bugpulver
źródło