Linux: CIFS / Samba mount зависает на несколько минут

26

У меня есть небольшая локальная сеть, в которой есть окно Gentoo и окно Windows. Я подключаю общий ресурс, исходящий из коробки Windows, к коробке Gentoo с помощью команды вроде:

mount -t cifs -o username=WindowsUsername,password=thepassword,uid=pistos //192.168.0.103/Users /mnt/windowsbox

В большинстве случаев все просто работает, и я могу читать и писать без проблем. Однако каждые несколько недель соединение или точка монтирования, кажется, обесточивается или зависает, так что любой процесс, который пытается получить доступ к точке монтирования, застревает в состоянии D (диск или ожидание ввода-вывода). Эти процессы становятся невосприимчивыми к сигналам TERM и KILL. Отключение и повторное подключение окна Windows от сети не помогает. Замороженное состояние длится 5+ минут. Это действительно расстраивает и мешает нормальной работе, потому что он замораживает диалоги Сохранить как, lsкоманды и т. Д. Если я umountзапускаю точку монтирования, она либо зависает, либо сообщает, что точка монтирования используется. В конце концов, мертвое состояние разрешается само, и точка монтирования отключается, или это становится возможным umountбез задержки.

Я предполагаю, что это происходит, когда соединение / монтирование бездействует, или когда машина Windows бездействует. Я не совсем уверен.

Почему это происходит, и что я могу сделать, чтобы предотвратить это? Или как я могу успешно убить эти процессы D-состояния по желанию?

Возможно связано: монтирование CIFS зависает при чтении

Pistos
источник
1
Используются ли межсетевые экраны между двумя компьютерами?
Шруте
@Schrute: Я предполагаю, что по умолчанию в Linux (iptables?) И Windows работают. Вы думаете, что брандмауэры отключают соединения? Я никогда не слышал о такой вещи.
Пистос
Я думаю, что это может быть проблемой коробки Linux. Я видел похожую проблему - не с cifs и Windows - но с смонтированным общим ресурсом nfs. Сохранение было невозможно - я думаю, из-за зависания какого-либо процесса при доступе к несуществующему серверу NFS. Обычно это происходит при сбое сервера.
cornelinux
1
Мой совет - настроить захват сети с кольцевым буфером на машине linux (т. Е. Tcpdump -i eth0 -C 5 -W 10 -s 0 -v -w /tmp/cifs.pcap host 192.168.0.103 - я бы тоже запустил это под экраном, чтобы предотвратить завершение процесса при отключении). Когда возникнет проблема, остановите трассировку через несколько секунд, и вы, по крайней мере, сможете определить, какая сторона вызывает проблему при просмотре трассировки пакетов (т. Е. Сервер перестает отвечать на запросы, сеанс отключается и т. Д.).
GeekyDeaks
1
@Pistos - Wireshark твой друг! Следы могут выглядеть запутанными, но wireshark расшифрует кадры, чтобы помочь. Вы хотите сначала устранить основы, например, сервер или клиент, отбрасывающий сеанс (пакеты FIN), затем переходить к другим, например, сервер перестает отвечать и т. Д. Если у вас было время, в 2013 году на CIFS было видео о sharkfest ( youtube.com/watch). ? v = XbvFXSPig-w ) но это довольно долго :)
GeekyDeaks

Ответы:

11

Не уверен, почему проблема возникает, но в качестве обходного пути, вы пытались поставить что-то вроде touch /mnt/windowsbox/keepalive.txtили echo "I am still alive." >/mnt/windowsbox/keepalive.txtзапускаться через cron каждую минуту? Таким образом, соединение должно оставаться активным.

Янне Пиккарайнен
источник
Отличная идея. Я положил это на место, и посмотрим, что произойдет.
Pistos
2
Это, кажется, решило проблему, я должен упомянуть.
Pistos
Рад слышать!
Янне Пиккарайнен
1
согласно ответу @ Pat, можно было урезать это от сердцебиения каждую минуту до сердцебиения каждые 5 минут (300 секунд), что будет */5 * * * *в расписании crontab
woodvi
Я использую это сейчас. В течение 3 дней у меня было три отдельных компьютера Ubuntu Server 16 LTS (две физические, одна виртуальная машина), которые через несколько часов после перезагрузки теряли соединения SMB. При запуске SMB-соединение монтируется без проблем, но в конечном итоге оно перестает отвечать на запросы.
user38537
5

Я тоже сталкиваюсь с этим каждые несколько месяцев. sudo umount -lэто мой обходной путь. /programming//a/96288/2097284

Камиль Гудесюн
источник
0

Другой потенциальный ответ - запись в файл на монтировании через регулярные промежутки времени через cron. Я бы предложил вместо этого использовать программу smbclient для подключения к общему ресурсу и отключения.

Я написал скрипт bash, как это, чтобы выполнить это:

#!/bin/bash

su usernamehere -c "smbclient \\\\\\\\\\\\\\\\servernamehere\\\\\\\\sharenamehere passwordhere -c exit" >/dev/null 2>&1

Эта команда устанавливает новое подключение к общему ресурсу, а затем запускает команду выхода, немедленно закрывая только что установленное соединение в командной строке. Должно быть 8 косых черт перед именем сервера и 4 перед именем общего ресурса, поскольку обратные косые черты должны быть экранированы, и экранированные символы должны быть экранированы, если они находятся внутри строки в двойных кавычках. Возможно, есть более разумный способ сделать это, но, похоже, это работает.

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

RedScourge
источник
Интересное предложение. Я бы попробовал, если бы у меня не было успеха с другим решением.
Пистос
Я не понимаю, как это было бы полезно? Решением Janne было бы сохранение соединения, установленного клиентом cifs, тогда как это создавало бы новое, не связанное с smbclient соединение - так как бы это помогло?
flungo
1
К вашему сведению, smbclient поддерживает прямую косую черту, если вы хотите использовать их вместо обратной косой черты, так что //servername/sharnameэто гораздо проще в местах, где вам нужно много экранирования.
Стив Фридл