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 gèle les boîtes de dialogue Enregistrer sous, les commandes ls, etc. Si j'émets un umount sur 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 et le point de montage est démonté, ou il devient possible de umount sans 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 montures CIFS sont suspendues en lecture
Je ne sais pas pourquoi le problème se produit, mais comme solution de contournement, avez-vous essayé de mettre quelque chose comme touch /mnt/windowsbox/keepalive.txt ou echo "I am still alive." >/mnt/windowsbox/keepalive.txt à exécuter via cron toutes les minutes? De cette façon, la connexion doit rester active.
Je rencontre aussi cela tous les quelques mois. Sudo umount -l est ma solution. https://stackoverflow.com/a/96288/2097284
Si vous rencontrez des problèmes de réseau et que la boîte Windows fonctionne 7+, veuillez lire
Minuterie de récupération ouverte résiliente [MS-SMB2] (300 secondes par défaut)
plus d'informations sur les délais d'attente cifs
http://blogs.msdn.com/b/openspecification/archive/2013/03/19/cifs-and-smb-timeouts-in-windows.aspx
Si votre problème a un comportement de récupération automatique, recherchez les délais d'expiration ...
Une autre réponse potentielle a suggéré d'écrire dans un fichier sur le support à intervalles réguliers via cron. Je suggère plutôt d'utiliser le programme smbclient pour se connecter au partage et se 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.