Question

Existe-t-il un moyen de forcer un processus Samba à fermer un fichier sans le tuer?

Samba ouvre un processus pour chaque connexion client et je constate parfois qu'il contient des fichiers ouverts bien plus longtemps que nécessaire. Habituellement, je tue simplement le processus et le client (Windows) le rouvrira lors de son prochain accès au partage. mais parfois, il lit activement un autre fichier pendant une longue période et je voudrais simplement "tuer" un fichier, et non la connexion entière.

edit: j'ai essayé le 'fichier net rpc à proximité', mais cela ne semble pas fonctionner. Quelqu'un sait pourquoi?

modifier: c'est la meilleure mention qui soit 'ont trouvé quelque chose de similaire. Cela semble être un problème sur le client win32, une solution pour laquelle les serveurs Microsoft ont une solution de contournement; mais Samba non. Je souhaite que la commande net rpc file close <fileid> fonctionne, je vais continuer à essayer de savoir pourquoi. J'accepte la réponse de LuckyLindy, même si cela n'a pas résolu le problème, car c'est la seule procédure utile dans ce cas.

Était-ce utile?

La solution

Cela se produit tout le temps sur nos systèmes, en particulier lors de la connexion à Samba depuis un ordinateur Win98. Nous suivons ces étapes pour le résoudre (qui sont probablement similaires aux vôtres):

  • Voir quel ordinateur utilise le fichier (c'est-à-dire lsof|grep -i <file_name>)
  • Essayez d'ouvrir ce fichier à partir de l'ordinateur incriminé ou de voir si un processus se cache dans le gestionnaire de tâches que nous pouvons fermer
  • Si cela ne vous tente pas, demandez à l'utilisateur de quitter tout programme réseau important
  • Tuez le processus Samba de l'utilisateur sous Linux (c'est-à-dire kill -9 <pid>)

Je souhaite qu'il y ait un meilleur moyen!

Autres conseils

Je crée une nouvelle réponse, car ma première réponse contenait en réalité davantage de questions et ne m'aidait pas beaucoup.

Après quelques recherches, je n'ai pas trouvé de bogues ouverts pour la dernière version de Samba. Veuillez vérifier le site Web Samba Bug Report et créez un nouveau bogue. C'est le moyen le plus simple de demander à quelqu'un de suggérer des idées sur la façon de résoudre ce problème, et de demander aux développeurs d'examiner le problème. Dans ma réponse précédente, LuckyLindy avait laissé un commentaire qui disait que c'était la même chose depuis 5 ans. Le projet est bien Open Source le meilleur moyen de réparer quelque chose qui ne va pas en le rapportant et en fournissant des correctifs.

J'ai également trouvé une entrée dans la liste de diffusion: Samba Ouvrir les fichiers , ils suggèrent d’ajouter posix locking=no au fichier de configuration, à condition que les fichiers distribués via NFS ne soient pas verrouillés, mais que le verrouillage du fichier soit correct, c’est-à-dire si le fichier en attente est verrouillé.

Si vous le souhaitez également, vous pouvez écrire un programme qui utilise ptrace et s’attache au programme. Il exécute, déverrouille et ferme tous les fichiers. Cependant, sachez que cela pourrait éventuellement laisser Samba dans un état inconnu, ce qui peut être plus dangereux.

Le travail que j'ai déjà mentionné consiste à redémarrer régulièrement samba en tant que solution de contournement. Je sais que ce n'est pas une solution, mais cela pourrait fonctionner temporairement.

Ceci est probablement résolu ici: Comment fermer un descripteur de fichier à partir d'un autre processus sous les systèmes Unix

À première vue, la "fermeture du fichier net rpc" ne fonctionne probablement pas car la communication interprocessus demandant à Samba de fermer le fichier ne sera pas examinée tant que le fichier que vous souhaitez fermer n'est pas lu.

S'il n'y a pas d'option explicite dans samba, il serait impossible de fermer en externe un descripteur de fichier ouvert avec des interfaces Unix standard.

En règle générale, vous ne pouvez pas vous mêler des descripteurs de fichier de processus de l'extérieur. Cependant, en tant que root, vous pouvez bien sûr faire ce que vous avez vu dans cet article de 1997: http://www.phrack.org/issues.html?issue=51 & amp; id = 5 # article - Je ne recommanderais pas cela sur un système de production bien que ...

La meilleure question dans ce cas serait pourquoi? Pourquoi voulez-vous fermer un fichier plus tôt? Quel est le but ultime de la fermeture du fichier? Qu'est-ce que vous essayez d'accomplir?

Samba fournit des commandes permettant d’afficher et de fermer les fichiers ouverts.

Pour répertorier tous les fichiers ouverts:

fichier net rpc -U ADadmin % mot de passe

Remplacez ADadmin et le mot de passe par les informations d'identification d'un administrateur de domaine Windows AD. Cela vous donne un identifiant de fichier, le nom de l'utilisateur qui l'a ouvert, le statut de verrouillage et le nom du fichier. Vous voudrez souvent filtrer les résultats en les passant par grep.

Une fois que vous avez trouvé un fichier que vous souhaitez fermer, copiez-en le numéro d'identification et utilisez cette commande:

net rpc file close id_fichier -U ADadmin % mot de passe

J'avais besoin d'accomplir quelque chose comme ceci pour pouvoir démonter facilement les périphériques que je partageais. J'ai écrit ce script bash rapide:

#!/bin/bash
PIDS_TO_CLOSE=$(smbstatus -L | tail -n-3 | grep "$1" | cut -d' ' -f1 - | sort -u | sed '/^$/$
for PID in $PIDS_TO_CLOSE; do
    kill $PID
done

Il faut un seul argument, les chemins à fermer:

smbclose /media/drive

Tout chemin correspondant à cet argument (par grep) est fermé. Vous devriez donc être assez précis avec ce dernier. (Seuls les fichiers ouverts via samba sont concernés.) Il est évident que vous avez besoin de root pour fermer les fichiers ouverts par d'autres utilisateurs, mais cela fonctionne bien pour les fichiers que vous avez ouverts. Notez que, comme pour toute fermeture forcée d’un fichier, les données peuvent être corrompues. Tant que les fichiers sont inactifs, ça devrait aller.

C'est assez moche, mais pour mon cas d'utilisation (fermeture de points de montage entiers), cela fonctionne assez bien.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top