Linux: le montage CIFS / Samba se bloque pendant plusieurs minutes

J'ai un petit réseau local qui a une boîte Gentoo et une boîte Windows. Je monte un partage provenant de la boîte Windows sur la boîte Gentoo avec une commande comme:

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

La plupart du temps, tout fonctionne, et je peux lire et écrire sans problème. Cependant, toutes les quelques semaines environ, la connexion ou le point de montage semble se bloquer ou se bloquer, de sorte que tout processus qui tente d'accéder au point de montage se bloque en état D (disque ou attente d'E / S). Ces processus deviennent imperméables aux signaux TERM et KILL. Déconnecter et reconnecter la boîte Windows du réseau n'aide pas. L'état gelé dure plus de 5 minutes. C'est vraiment frustrant et gêne le travail normal, car il fige les dialogues, les lscommandes, etc. Si j'émets un umountsur le point de montage, il se bloque également ou signale que le point de montage est en cours d'utilisation. Finalement, l'état mort se résout automatiquement et le point de montage est démonté, ou il devient possible de le faire umountsans délai.

Je suppose que cela se produit lorsque la connexion / le montage est devenu inactif ou lorsque la machine Windows est inactive. Je ne suis pas vraiment sûr.

Pourquoi cela se produit-il et que puis-je faire pour l'empêcher? Ou comment puis-je réussir à tuer ces processus d'état D à volonté?

Peut-être lié: les supports CIFS restent en lecture

linux cifs

— Pistos
source

Existe-t-il un type de pare-feu entre les deux machines?

— Schrute

@Schrute: Je suppose que toutes les valeurs par défaut sont sous Linux (iptables?), Et Windows fonctionne. Vous pensez que les pare-feu interrompent les connexions? Je n'avais jamais entendu parler d'une telle chose.

— Pistos

Je pense que cela pourrait être un problème de la boîte Linux. J'ai vu un problème similaire - pas avec cifs et Windows - mais avec un partage nfs monté. L'enregistrement n'a pas été possible - je suppose en raison d'un processus suspendu lors de l'accès au serveur nfs non existant. Cela se produit généralement lorsque le serveur tombe en panne.

— cornelinux

Mon conseil est de configurer une capture réseau en tampon en anneau sur la machine Linux (c.-à-d. Tcpdump -i eth0 -C 5 -W 10 -s 0 -v -w /tmp/cifs.pcap host 192.168.0.103 - je lancerais également sous l'écran pour empêcher le processus de se terminer lorsque vous vous déconnectez). Lorsque le problème se produit, arrêtez la trace après quelques secondes et vous devriez au moins être en mesure de déterminer de quel côté est à l'origine le problème lors de l'examen de la trace de paquet (par exemple, le serveur cesse de répondre, la session est déconnectée, etc.).

— GeekyDeaks

@Pistos - Wireshark est votre ami! Les traces peuvent sembler déroutantes, mais wirehark décode les images pour vous aider. Vous voulez d'abord éliminer les bases, comme le serveur ou le client supprimant la session (paquets FIN), puis passer à d'autres comme le serveur cesse de répondre, etc. Si vous avez le temps, il y a eu une vidéo sharkfest sur CIFS en 2013 ( youtube.com/watch ? v = XbvFXSPig-w ) mais c'est plutôt long :)

— GeekyDeaks

Réponses:

Vous ne savez pas pourquoi le problème se produit, mais comme solution de contournement, avez-vous essayé de mettre quelque chose comme touch /mnt/windowsbox/keepalive.txtou echo "I am still alive." >/mnt/windowsbox/keepalive.txtd'être exécuté via cron toutes les minutes? De cette façon, la connexion doit rester active.

— Janne Pikkarainen
source

Bonne idée. J'ai mis cela en place et je verrai ce qui se passera.

— Pistos

Cela semble avoir résolu le problème, je dois le mentionner.

— Pistos

Bien d'entendre ça!

— Janne Pikkarainen

selon la réponse de @ Pat, on pourrait couper cela d'un rythme cardiaque chaque minute à un rythme cardiaque toutes les 5 minutes (300 secondes), ce qui serait */5 * * * *dans le programme crontab

— woodvi

J'utilise ceci pour l'instant. En 3 jours, j'ai eu trois machines Ubuntu Server 16 LTS distinctes (deux physiques, une VM) qui ont abandonné leurs connexions SMB après quelques heures de redémarrage. Au démarrage, la connexion SMB est montée sans problème, mais elle ne répond finalement pas.

— user38537

Je rencontre aussi cela tous les quelques mois. sudo umount -lest ma solution. /programming//a/96288/2097284

— Camille Goudeseune
source

Une autre réponse potentielle a suggéré d'écrire dans un fichier sur le support à intervalles réguliers via cron. Je suggérerais plutôt d'utiliser le programme smbclient pour vous connecter au partage et vous déconnecter.

J'ai écrit un script bash comme celui-ci pour accomplir cela:

#!/bin/bash

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

Cette commande établit une nouvelle connexion au partage, puis exécute la commande exit, arrêtant immédiatement la connexion qu'elle vient d'établir sur la ligne de commande. Il doit y avoir 8 barres obliques avant le nom du serveur et 4 avant le nom de partage, car les barres obliques inverses doivent être échappées et les échappements doivent être échappés lorsqu'ils sont à l'intérieur d'une chaîne entre guillemets doubles. Peut-être existe-t-il une façon plus intelligente de procéder, mais cela semble fonctionner.

Il y a peut-être un moyen de rendre cela encore plus fiable en lui faisant maintenir la connexion ouverte pendant plusieurs minutes à la fois, mais c'est un peu hors de ma ligue.

— RedScourge
source

Proposition intéressante. J'aurais essayé si je n'avais pas déjà réussi avec l'autre solution.

— Pistos

Je ne vois pas en quoi cela serait utile? La solution de Janne serait de maintenir la connexion établie par le client cifs alors que cela créerait une nouvelle connexion sans rapport avec le client smbcl - alors comment cela pourrait-il aider?

— flungo

Pour info, smbclient prend en charge les barres obliques si vous souhaitez les utiliser à la place des barres obliques inverses, il //servername/sharnameest donc beaucoup plus facile dans les endroits où vous avez besoin de beaucoup de s'échapper.

— Steve Friedl