les montages autofs ne se déconnectent pas après inactivité

J'ai installé des autofs sur plusieurs serveurs linux qui se connectent au serveur NFS central pour les répertoires utilisateurs / home. Cela fonctionne très bien lors du montage des répertoires lors de la connexion, mais les montages ne semblent jamais expirer. J'ai vérifié / etc / sysconfig / autofs et la valeur par défaut est en effet définie sur 300, donc ceux-ci devraient expirer après 5 minutes.

Le redémarrage d'autofs démonte tous les répertoires, donc je sais qu'il est capable.

J'ai essayé d'utiliser lsof au hasard dans les répertoires mais aucun fichier ne semble ouvert à aucun moment.

J'ai également monté un répertoire aléatoire dont je sais qu'il n'est pas actif, mais ceux-ci ne se démontent jamais eux-mêmes. Certaines de ces boîtes ont plus de 10 utilisateurs qui se sont connectés une fois, et les montures ne tombent jamais.

J'essaie juste de découvrir qu'il existe une meilleure méthode pour savoir pourquoi. Je ne vois rien de spécifique dans les journaux.

Toutes les suggestions sont appréciées. Merci!

METTRE À JOUR

J'ai activé le débogage pour les autofs, mais cela ne semble rien révéler d'extraordinaire. Ces journaux ont été générés 7 minutes après le montage initial de / home / user1 et après 6 minutes d'inactivité. Selon la valeur par défaut de 5 minutes, cela aurait dû être démonté. Je n'ai jamais vu un journal passer qui indiquait qu'une tentative avait même été faite pour démonter.

Jan 11 12:52:00 linux automount[26505]: st_expire: state 1 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc: exp_proc = 3055176592 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user1
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user2
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user3
Jan 11 12:52:00 linux automount[26505]: 3 remaining in /home
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: got thid 3055176592 path /home stat 7
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: sigchld: exp 3055176592 finished, switching from 2 to 1
Jan 11 12:52:00 linux automount[26505]: st_ready: st_ready(): state = 2 path /home

Mise à jour 2 Après en avoir discuté avec le support de Red Hat, la solution a finalement consisté à raccourcir la valeur du délai d'expiration des répertoires personnels. J'ai fait ça et ça a l'air bien. Apparemment, quelque chose traverse le point de montage toutes les 2 1/2 à 3 minutes et fait que cela reste en place.

La solution consistait à ajouter la valeur du délai d'attente au fichier /etc/auto.master pour ce mappage:

 /home     /etc/auto_home --timeout=120

Outre la variable TIMEOUT, autofs a un intervalle de vérification:

# cat /var/log/messages
Jan 11 21:45:35 client automount[24804]: mounted offset on /net/server/share with timeout 300, freq 75 seconds

Il est égal à TIMEOUT / 4. Chaque TIMEOUT / 4 secondes autofs demande au noyau quand le répertoire a été accédé la dernière fois. Ainsi, dans votre environnement, vous avez annulé le répertoire après 375 secondes d'inactivité.

Pour obtenir un journal plus détaillé, vous devez ajouter LOGGING="debug"à/etc/sysconfig/autofs

J'avais un problème similaire. J'ai réinstallé notre serveur RHEL 4.7 ProLiant de 10 ans avec CentOS 6 pendant les vacances de Noël. J'ai eu 2 nouveaux ProLiants sur lesquels j'ai pu installer CentOS 7 plus récemment (en avril).

J'ai configuré le montage automatique des répertoires personnels à partir du serveur CentOS 6 en utilisant une ligne /etc/auto.mastersur les serveurs CentOS 7 comme suit:

/home   /etc/auto.home

Ensuite, j'ai créé un nouveau /etc/auto.homefichier sur les serveurs CentOS 7 initialement avec une ligne:

*      sam:/home/&

Les répertoires personnels ne seraient cependant pas démontés. J'ai également constaté que certains des propriétaires de fichiers dans les répertoires personnels se retrouvaient de temps en temps avec un énorme numéro UID et GID contre eux. Cela changerait quelques minutes plus tard.

J'ai défini le niveau de journalisation sur «déboguer» /etc/autofs.confet commencer à regarder avec journalctl -fu autofs.service. J'ai vu des messages presque identiques comme indiqué ci-dessus, qui ne semblaient contenir aucun indice.

Comme je n'avais pas encore pu comprendre NFS 4, et je savais que notre serveur CentOS 6 exportait ses partages en tant que NFS 4 par défaut, j'ai essayé d'ajouter nfsvers=3au /etc/auto.homefichier comme ceci:

training      -nfsvers=3,noac,soft,intr  sam:/home/training

Je voyais également le message étrange d'essayer de monter des répertoires comme /home/lib, alors j'ai ajouté les répertoires personnels sur des lignes distinctes. (Il aurait probablement dû essayer des montages directs à ce stade, ou des montages automatiques systemd.)

Maintenant, j'ai commencé à voir des messages comme:

Apr 27 09:32:28 betty automount[13501]: expire_proc_indirect: expire /home/fred
Apr 27 09:32:28 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:28 betty automount[13501]: handle_packet_expire_indirect: token 21, name fred
Apr 27 09:32:28 betty automount[13501]: expiring path /home/fred
Apr 27 09:32:28 betty automount[13501]: umount_multi: path /home/fred incl 1
Apr 27 09:32:28 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/fred
Apr 27 09:32:28 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/fred
Apr 27 09:32:29 betty automount[13501]: expired /home/fred
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 21
Apr 27 09:32:29 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:29 betty automount[13501]: handle_packet_expire_indirect: token 22, name barney
Apr 27 09:32:29 betty automount[13501]: expiring path /home/barney
Apr 27 09:32:29 betty automount[13501]: umount_multi: path /home/barney incl 1
Apr 27 09:32:29 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/barney
Apr 27 09:32:29 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/barney
Apr 27 09:32:29 betty automount[13501]: expired /home/barney
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 22
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/barney
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/wilma
Apr 27 09:32:29 betty automount[13501]: 1 remaining in /home

Les répertoires personnels ont maintenant commencé à se démonter après 10 minutes comme ils le devraient - c'était donc un problème avec NFS 4 mal configuré dans mon cas.

Important: après avoir reconfiguré les cartes, faire simplement systemctl daemon-reloadou systemctl reload autofsn'a aucun effet. je devais fairesystemctl restart autofs

Pour toute autre personne rencontrant des problèmes similaires, il existe des processus GUI sur les ordinateurs de bureau modernes qui analysent continuellement les disques. En particulier Nautilus sur Gnome et Dolphin sur KDE ainsi que des applications d'indexation de fichiers comme Baloo. Ce sont tous capables de provoquer le symptôme.

Pour moi (exécutant KDE), le seul indice de la journalisation du débogage de montage automatique était "1 restant", par exemple:

    Feb 13 00:00:44 fig automount[19026]: expire_proc: exp_proc = 139620739028736 path /mnt/vchanger
    Feb 13 00:00:44 fig automount[19026]: expire_proc_indirect: expire /mnt/vchanger/fb207cd6-6931-4af4-8293-c82ee0d2394c
    Feb 13 00:00:44 fig automount[19026]: 1 remaining in /mnt/vchanger

Cela n'a pas vraiment identifié la source. De plus, aucun de lsof, fuser et auditctl (auditd) n'a donné un aperçu.

Finalement, par processus d'élimination, j'ai déterminé qu'il y avait 2 demandes:

• KSysGuard (moniteur système KDE)
• Dolphin (gestionnaire de fichiers)

Le problème avec Dolphin pourrait être résolu dans ce cas en «masquant» le disque monté incriminé dans son arborescence.

KSysGuard ne semble pas configurable, mais il est peut-être inhabituel de le faire fonctionner à long terme, sauf si vous déboguez quelque chose. Espérons que d'autres applications pourraient être plus configurables en permettant des exclusions pour empêcher le point de montage de montage automatique d'être analysé.

J'ai passé des heures aujourd'hui à essayer de déboguer et de résoudre un problème similaire. Voici ce que j'ai trouvé et comment je l'ai travaillé.]

configuration: je voulais monter automatiquement le répertoire contenant les répertoires personnels des utilisateurs à partir du serveur nfs "srv1: / srv / homes" dans / mnt / nfs / homes sur les clients. Les serveurs NFS exportent NFS4. autofs version 5.1.3

J'avais configuré chaque client comme ça:

/etc/auto.mount: fichier contenant les éléments suivants:

... 
/mnt/nfs /etc/auto.home
...

/etc/auto.home:

homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

Finalement, cela représente une carte indirecte. Le montage automatique fonctionne comme un charme. J'obtiens le volume NFS correctement monté et fonctionne. Mais ... il n'est jamais démonté automatiquement. Même si le fichier autofs.conf indique:

et mountaffiche un délai d'expiration de 600 secondes:

#1# /etc/auto.home on /mnt/nfs type autofs (rw,relatime,fd=18,pgrp=5054,timeout=300,minproto=5,maxproto=5,indirect) 
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

Je voyais exactement la même chose dans (les journaux de débogage activent) les journaux autofs de journalctl en tant que wanpelaman

automount[53593]: st_expire: state 1 path /mnt/nfs
automount[53593]: expire_proc: exp_proc = 139645987374848 path /mnt/nfs
automount[53593]: expire_proc_indirect: expire /mnt/nfs/homes
automount[53593]: 1 remaining in /mnt/nfs
automount[53593]: expire_cleanup: got thid 139645987374848 path /mnt/nfs stat 3
automount[53593]: expire_cleanup: sigchld: exp 139645987374848 finished, switching from 2 to 1
automount[53593]: st_ready: st_ready(): state = 2 path /mnt/nfs

A cette époque, j'ai abandonné les autofs et j'ai décidé de répliquer la configuration automount avec systemd. En fait, je l'ai exécuté et à ce moment tout fonctionnait très bien - montage automatique, démontage automatique après une période d'inactivité prédéfinie. Juste parfait. Mais systemd ... un peu maladroit (ne me tirez pas dessus, j'aime vraiment ça). Ensuite, j'ai regardé comment systemd gère le montage automatique:

#2# systemd-1 on /mnt/nfs/homes type autofs (rw,relatime,fd=35,pgrp=1,timeout=20,minproto=5,maxproto=5,direct)
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

La différence entre # 1 # et # 2 # est que cette dernière est une carte directe tandis que # 1 # est indirecte. J'ai donc immédiatement décidé de reconfigurer les autofs sur un autre client et de créer une carte directe comme celle-ci:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

/mnt/nfs/homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

Et cela a finalement résolu le problème. Le montage automatique et le démontage automatique ont bien fonctionné. umount a été exécuté avec succès après la période d'inactivité prédéfinie dans /etc/autofs.conf

Aucune modification sur le serveur NFS n'était absolument nécessaire.