Linux: el montaje CIFS / Samba se cuelga durante varios minutos

Tengo una pequeña red local que tiene un cuadro de Gentoo y un cuadro de Windows. Monto un recurso compartido que se origina en el cuadro de Windows en el cuadro de Gentoo con un comando como:

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

La mayoría de las veces, todo funciona, y puedo leer y escribir sin problemas. Sin embargo, cada pocas semanas más o menos, la conexión o el punto de montaje parece bloquearse, de modo que cualquier proceso que intente acceder al punto de montaje se atasca en estado D (disco o espera de E / S). Estos procesos se vuelven impermeables a las señales TERM y KILL. Desconectar y volver a conectar el cuadro de Windows de la red no ayuda. El estado congelado dura más de 5 minutos. Es realmente frustrante y se interpone en el camino del trabajo normal, porque congela los diálogos, lscomandos, etc. de Guardar como umount. Eventualmente, el estado muerto se resuelve solo, y el punto de montaje se desmonta, o se hace posible umountsin demora.

Supongo que esto sucede cuando la conexión / montaje se ha quedado inactivo, o cuando la máquina Windows ha estado inactiva. No estoy muy seguro.

¿Por qué sucede esto y qué puedo hacer para evitarlo? ¿O cómo puedo matar con éxito estos procesos de estado D a voluntad?

Posiblemente relacionado: los montajes CIFS se cuelgan en la lectura

linux cifs

— Pistos
fuente

¿Hay algún tipo de firewall en uso entre las dos máquinas?

— Schrute

@Schrute: Supongo que los valores predeterminados están en Linux (¿iptables?) Y Windows se está ejecutando. ¿Crees que los firewalls están agotando las conexiones? Nunca había oído hablar de tal cosa.

— Pistos

Creo que esto podría ser un problema de la caja de Linux. Vi un problema similar, no con cifs y Windows, sino con un recurso compartido nfs montado. No fue posible guardar. Supongo que debido a algún proceso se bloqueó al acceder al servidor nfs no existente. Esto suele suceder cuando el servidor falla.

— cornelinux

Mi consejo es configurar una captura de red de buffer de anillo en la máquina Linux (es decir, tcpdump -i eth0 -C 5 -W 10 -s 0 -v -w /tmp/cifs.pcap host 192.168.0.103 - También ejecutaría debajo de la pantalla para evitar que el proceso finalice cuando se desconecta). Cuando se produce el problema, detenga el seguimiento después de unos segundos y al menos debería poder determinar qué lado está causando el problema al revisar el seguimiento del paquete (es decir, el servidor deja de responder, la sesión se desconecta, etc.).

— GeekyDeaks

@Pistos - ¡Wireshark es tu amigo! Las huellas pueden parecer confusas, pero wireshark decodificará los marcos para ayudar. Primero desea eliminar lo básico, como que el servidor o el cliente abandonen la sesión (paquetes FIN), luego avance a otros, como el servidor deja de responder, etc. Si tiene tiempo, hubo un video de tiburones en CIFS en 2013 ( youtube.com/watch ? v = XbvFXSPig-w ) pero es bastante largo :)

— GeekyDeaks

Respuestas:

No estoy seguro de por qué está ocurriendo el problema, pero como solución alternativa, ¿ha intentado poner algo como touch /mnt/windowsbox/keepalive.txto echo "I am still alive." >/mnt/windowsbox/keepalive.txtejecutarse a través de cron cada minuto? De esa manera, la conexión debe permanecer activa.

— Janne Pikkarainen
fuente

Buena idea. Puse esto en su lugar y veré qué sucede.

— Pistos

Esto parece haber resuelto el problema, debo mencionar.

— Pistos

¡Que bueno escuchar eso!

— Janne Pikkarainen

según la respuesta de @ Pat, uno podría recortar esto de un latido cada minuto a un latido cada 5 minutos (300 segundos), lo que estaría */5 * * * *en el horario de crontab

— woodvi

Estoy usando esto por ahora. En 3 días, tuve tres máquinas Ubuntu Server 16 LTS separadas (dos físicas, una VM) dejaron sus conexiones SMB después de unas horas de reiniciar. Al inicio, la conexión SMB se monta sin problemas, pero finalmente deja de responder.

— user38537

Yo también encuentro esto cada pocos meses. sudo umount -les mi solución /programming//a/96288/2097284

— Camille Goudeseune
fuente

Otra posible respuesta sugirió escribir en un archivo en la montura en un intervalo regular a través de cron. En su lugar, sugeriría usar el programa smbclient para conectarse al recurso compartido y desconectarse.

Escribí un script bash como este para lograr eso:

#!/bin/bash

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

Este comando establece una nueva conexión con el recurso compartido y luego ejecuta el comando de salida, apagando inmediatamente la conexión que acaba de establecer en la línea de comando. Debe haber 8 barras diagonales antes del nombre del servidor y 4 antes del nombre del recurso compartido, ya que las barras invertidas deben escaparse, y las escapes deben escaparse dentro de una cadena de comillas dobles. Quizás haya una forma más inteligente de hacer esto, pero parece funcionar.

Quizás haya una manera de hacer esto aún más confiable haciendo que mantenga la conexión abierta durante varios minutos a la vez, pero eso está un poco fuera de mi alcance.

— RedScourge
fuente

Interesante propuesta. Lo hubiera intentado si aún no hubiera tenido éxito con la otra solución.

— Pistos

No veo cómo esto sería útil. La solución de Janne sería mantener viva la conexión realizada por el cliente cifs, mientras que esto crearía una nueva conexión no relacionada con el cliente smb, entonces, ¿cómo ayudaría?

— flungo

Para su información, smbclient admite barras diagonales si desea usarlas en lugar de barras diagonales inversas, por lo que //servername/sharnamees mucho más fácil en lugares donde necesita escapar mucho.

— Steve Friedl