LINUX.ORG.RU

sshfs - Кащей бессмертный


0

1

Часто пользуюсь sshfs и постоянно сталкиваюсь с проблемой: при обрыве связи с удалённым хостом или просто рандомно после некоторого времени, почему-то, точка монтирования становится недоступна. Любой процесс, обратившийся к ней, зависает и убивается только SIGKILL'ом.
ls -l ~/sshfs показывает:

??????????  ? ?        ?                ?            ? sshfs
При попытке отмонтировать ФС, выдаёт, что она занята, хотя все процессы, использовавшие её, я убил. В итоге, освободить точку монтирования мне пока удавалось только перезагрузкой.
Кто-нибудь в курсе, как этого можно избежать, или, хотя бы, как размонтировать уже подвисшую sshfs без перезагрузки?

★★★★★

Последнее исправление: Axon (всего исправлений: 1)

Ответ на: комментарий от sin_a

Спасибо!!! Пять раз читал man umount, но, почему-то, не подумал, что это может помочь...

Axon ★★★★★
() автор топика
Ответ на: комментарий от ckotinko

у sshfs есть опция reconnect

Связь, как правило, теряется, когда удалённый хост ребутают в винду, следовательно, реконнект невозможен. В остальных случаях абсолютно неясна причина дисконнекта.

Axon ★★★★★
() автор топика
Ответ на: комментарий от sin_a

Монтирует при обращении и отмонтирует без обращения после таймаута.

Это не поможет. Не замечал, чтобы оно переставало работать во время обращения, но без него может отвалиться очень быстро - иногда хватает нескольких минут.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

Ты не понял. После того как ты перестаёшь обращаться к каталогу - он сам отмонтируется после таймаута (обычно несколько секунд, настраивается в конфигурационном файле).

То есть, после того как ты перестал что то делать - через три секунды он уже отмонтирован и после этого со связью может происходить уже что угодно.

sin_a ★★★★★
()
Ответ на: комментарий от pekmop1024

1. убить процесс sshfs 2. размонтировать точку

Читаем:

хотя все процессы, использовавшие её, я убил.


Помогает lazy unmount, предложенный sin_a.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

> использовавшие её

я тебе не предлагаю убить «все процессы, использовавшие её». Я тебе предлагаю убить конкретно sshfs.

pekmop1024 ★★★★★
()
Ответ на: комментарий от sin_a

То есть, после того как ты перестал что то делать - через три секунды он уже отмонтирован и после этого со связью может происходить уже что угодно.

Ну, как вариант, конечно, но костыль и он мне не нравится. К тому же, это возможно только при авторизации по ключу, а я пользуюсь sshfs на разных машинах и для каждой запихивать ключ на хост геморно.

Axon ★★★★★
() автор топика
Ответ на: комментарий от pekmop1024

я тебе не предлагаю убить «все процессы, использовавшие её». Я тебе предлагаю убить конкретно sshfs.

Короче, это первое, что я попробовал убить. Не помогает.

Axon ★★★★★
() автор топика
Ответ на: комментарий от unanimous

Ты врешь.

Офигенно. Нет, в данном случае killall ssh я не делал, так как сам сидел на этом хосте через ssh, но процесс sshfs я убил и это ничего не дало.

Axon ★★★★★
() автор топика
Ответ на: комментарий от pekmop1024

Только с -9 убивается, btw.

Я заметил. :-)

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

процесс sshfs поднимает процесс ssh + fuse. Ты даже не удосужился набрать ps axfu | less чтобы посмотреть, какие процессы оно вызывает, а уже прискакал на ЛОР постить вызывающе неверные сообщения, порожденные твоей тупостью.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

процесс sshfs поднимает процесс ssh + fuse. Ты даже не удосужился набрать ps axfu | less чтобы посмотреть, какие процессы оно вызывает

Я могу ошибаться, но мне кажется, что я лучше знаю, что я сделал, и чего не сделал.

постить вызывающе неверные сообщения, порожденные твоей тупостью.

А с такими закидонами могу вам предложить лишь проследовать в известном направлении. Толку от вас в этом треде всё равно ноль.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

ОК, если тебе не нужно решение, а показать всем, какой ты умный и самостоятельный — дело твое. Больше тебе ничего объяснять я не буду.

unanimous ★★★★★
()
Ответ на: комментарий от Axon

Я сказал достаточно: убивать нужно не sshfs, а ssh, которую запускает sshfs в бэкграунде. Но тебе влом даже смонтировать sshfs и посмотреть в ps что и как, из чего я деляю вывод, что решение тебе не интересно, а интересно посраться.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Но тебе влом даже смонтировать sshfs и посмотреть в ps что и как

Дело в том, что я это делал и об этом говорил. Я не идиот и проблему мою мне уже решить помогли те, кто мог и хотел. А вот от вас пока исходит только хамство и, видимо, некомпетентность.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

Ты будешь мне говорить, о том, как пользоваться sshfs, когда я ее использую уже годы под разными системами? Нет, может в твоем арче ее как-то несовестимо поменяли, но в моих федоре, centos и бубунте она работает одинаково. Если соединение зависло — убить ssh сначала, потом отмонтировать fusermount -u. Любые другие способы, в том числе попытка добить точку монтирования Tab'ом приводят к блокированию шелла на вводе/выводе.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Нет, может в твоем арче ее как-то несовестимо поменяли, но в моих федоре, centos и бубунте она работает одинаково.

Arch, Ubuntu, Gentoo. Везде поведение одинаково. И помогло убить sshfs, а затем umount -l. Предложенный вами вариант напрашивается первым, я пробовал его 100500 раз и всегда с одинаковым нулевым результатом.

Ты будешь мне говорить, о том, как пользоваться sshfs, когда я ее использую уже годы под разными системами?

В отличие от некоторых, я никому тыкать или рассказывать, как ведёт себя его система привычки не имею.

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

> И помогло убить sshfs, а затем umount -l

umount -l не освобождает ресурсы, просто делает вид, что все ок. Это костыль, чтобы можно было хромать дальше. Кроме того, umount -l требует рутовых прав, а у тебя их может не быть, как у меня на рабочей машинею Правильный вариант — убить все процессы с открытыми файлами на удаленной fs, убить запущенный процесс ssh с под системой sftp, затем все должно отвалиться само. Если нет — fusermount -u. На твоем месте я бы хотя бы попробовал понять, что тебе говорят, а не заводить шарманку «я, может и ламер, но...»

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

>umount -l не освобождает ресурсы, просто делает вид, что все ок.
Я знаю.

umount -l требует рутовых прав, а у тебя их может не быть

Я об этом думал. Слава богу, они есть.

Правильный вариант — убить все процессы с открытыми файлами на удаленной fs, убить запущенный процесс ssh с под системой sftp

Сделано

затем все должно отвалиться само

Не отваливается.

Если нет — fusermount -u

Точка монтирования занята.
Сколько ещё раз мне повторить, что я ПРОБОВАЛ делать так, как вы сказали, ДО того, как просить помощи здесь, чтобы до вас дошло?

Axon ★★★★★
() автор топика
Ответ на: комментарий от Axon

> Сколько ещё раз мне повторить, что я ПРОБОВАЛ делать так, как вы сказали, ДО того, как просить помощи здесь, чтобы до вас дошло?

ОК, я проделываю по шагам.

1. Монтирую sshfs

2. Выдергиваю сетевой кабель. Проверяю: mc действительно заблокировался на попытке прочесть удаленную FS

3. ps axfu | grep ssh

Вот нужная строка:

ssh -x -a ssh -x -a -oClearAllForwardings=yes -oCompression=yes -2-oClearAllForwardings=yes -oCompression=yes -2 <поскипано>

4. kill -9 28848

5. mc все еще блокирован

6. Убиваю непосредственно sshfs

7. kill -9 28854

8. mc отпустило, но точка монтирования еще не удалена

9. fusermount -u отработал без ошибок.

Итог: последовательно нужно: убить ssh, убить sshfs, отмонтировать fusermount -u

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Да, прошу прощения, что ругался, убить sshfs тоже нужно. Но ты мог бы это и сам выяснить.

Удачи!

unanimous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.