los montajes de autofs no se desconectan después de inactivo

Tengo autofs instalados en varios servidores de Linux que se conectan al servidor NFS central para los usuarios / directorios de inicio. Funciona muy bien al montar los directorios al iniciar sesión, pero los montajes nunca parecen agotar el tiempo de espera. He comprobado / etc / sysconfig / autofs y el valor predeterminado de hecho está configurado en 300, por lo que estos deberían estar en espera después de 5 minutos.

Reiniciar autofs desmonta todos los directorios, así que sé que es capaz.

Intenté usar lsof aleatoriamente en los directorios, pero no aparece ningún archivo abierto en ningún momento.

También he montado un directorio aleatorio que sé que no está activo, pero estos nunca se montan solos. Algunos de estos cuadros tienen más de 10 usuarios que han iniciado sesión una vez, y las monturas nunca caen.

Solo estoy tratando de descubrir que hay un mejor método para descubrir por qué. No veo nada específico en ningún registro.

Cualquier sugerencia es apreciada. ¡Gracias!

ACTUALIZAR

Encendí la depuración de autofs, pero no parece revelar nada fuera de lo común. Estos registros se generaron 7 minutos después de que / home / user1 se montó inicialmente y después de 6 minutos de inactividad. De acuerdo con el valor predeterminado de 5 minutos, esto debería haberse desmontado. Nunca vi entrar un registro que indicara que incluso se intentó desmontar.

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

Actualización 2 Después de hablar con el soporte de Red Hat sobre esto, la solución terminó siendo solo acortar el valor de tiempo de espera para los directorios principales. Lo hice y se ve bien. Aparentemente, algo atraviesa el punto de montaje cada 2 1/2 a 3 minutos y hace que esto permanezca arriba.

La solución fue agregar el valor de tiempo de espera al archivo /etc/auto.master para esa asignación:

 /home     /etc/auto_home --timeout=120

Además TIMEOUT variable autofs tiene un intervalo de comprobación:

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

Es igual a TIMEOUT / 4. Cada TIMEOUT / 4 segundos autofs pregunta al núcleo cuándo se accedió al directorio la última vez. Entonces, en su entorno, tiene un directorio anunciado después de 375 segundos de inactividad.

Para obtener un registro más detallado, debe agregar LOGGING="debug"a/etc/sysconfig/autofs

Tuve un problema similar. Reinstalé nuestro servidor ProLiant RHEL 4.7 de 10 años con CentOS 6 durante las vacaciones de Navidad. Tenía 2 ProLiants más nuevos en los que pude instalar CentOS 7 más recientemente (en abril).

Configuré el montaje automático de los directorios de inicio del servidor CentOS 6 usando una línea en /etc/auto.masterlos servidores CentOS 7 de esta manera:

/home   /etc/auto.home

Luego creé un nuevo /etc/auto.homearchivo en los servidores CentOS 7 inicialmente con una línea:

*      sam:/home/&

Sin embargo, los directorios principales no se desmontarían. También descubrí que algunas de las propiedades de los archivos en los directorios principales terminarían de vez en cuando con un gran número de UID y GID en su contra. Cambiaría unos minutos más tarde.

Configuré el nivel de registro para 'depurar' /etc/autofs.confy comencé a mirar con journalctl -fu autofs.service. Vi mensajes casi idénticos como se muestra arriba, que parecían no tener pistas.

Como todavía no había podido entender NFS 4, y sabía que nuestro servidor CentOS 6 estaba exportando sus recursos compartidos como NFS 4 de forma predeterminada, intenté agregar nfsvers=3al /etc/auto.homearchivo de esta manera:

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

También estaba viendo un mensaje extraño sobre cómo tratar de montar directorios /home/lib, así que agregué los directorios de inicio individuales en líneas separadas. (Probablemente debería haber intentado montajes directos en este punto, o probado montajes automáticos systemd).

Ahora comencé a ver mensajes como:

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

Los directorios principales ahora comenzaron a desmontarse después de 10 minutos como deberían, por lo que fue un problema con NFS 4 mal configurado en mi caso.

Importante: después de reconfigurar los mapas, simplemente hacer systemctl daemon-reloado systemctl reload autofsno tiene ningún efecto. Tenía que hacersystemctl restart autofs

Para cualquier otra persona que experimente problemas similares, existen procesos de GUI en escritorios modernos que escanean las unidades continuamente. En particular, Nautilus en Gnome y Dolphin en KDE junto con aplicaciones de indexación de archivos como Baloo. Todos estos son capaces de causar el síntoma.

Para mí (ejecutando KDE), la única pista del registro de depuración de montaje automático fue "1 restante", por ejemplo:

    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

Esto realmente no identificó la fuente. Tampoco ninguno de lsof, fuser y auditctl (auditd) dieron ninguna idea.

Finalmente, por proceso de eliminación, determiné que había 2 aplicaciones:

• KSysGuard (monitor del sistema KDE)
• Dolphin (Administrador de archivos)

El problema con Dolphin podría solucionarse en este caso "ocultando" el disco montado ofensivo en su vista de árbol.

KSysGuard no parece configurable, pero quizás sea inusual tenerlo funcionando a largo plazo a menos que esté depurando algo. Esperemos que otras aplicaciones sean más configurables para permitir exclusiones para evitar que se escanee el punto de montaje del montaje automático.

Hoy pasé horas tratando de depurar y un problema similar. Esto es lo que encontré y cómo lo resolví.]

configuración: quería montar automáticamente el directorio que contiene los directorios principales de los usuarios desde el servidor nfs "srv1: / srv / homes" en / mnt / nfs / homes en los clientes. Los servidores NFS exportan NFS4. autofs versión 5.1.3

Había configurado a cada cliente así:

/etc/auto.mount: archivo que contiene lo siguiente:

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

/etc/auto.home:

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

Finalmente, esto representa un mapa indirecto. El montaje automático funciona de maravilla. Obtengo el volumen NFS correctamente montado y funcionando. Pero ... nunca se desmonta automáticamente. Aunque el archivo autofs.conf dice:

y mountmuestra 600 segundos de tiempo de espera:

#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)

Estaba viendo exactamente lo mismo en los registros de autofs (activación del nivel de registro de depuración) de journalctl como 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

En ese momento dejé de usar autofs y decidí replicar la configuración de montaje automático con systemd. En realidad lo ejecuté y en este momento todo funcionó muy bien: montaje automático, desmontaje automático después del período inactivo predefinido. Simplemente perfecto. Pero systemd ... un poco torpe (no me dispares, en realidad me gusta). Luego miré cómo systemd maneja el montaje automático:

#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 diferencia entre # 1 # y # 2 # es que este último es un mapa directo mientras que # 1 # es indirecto. Por lo tanto, inmediatamente decidí reconfigurar autofs en otro cliente y crear un mapa directo como ese:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

Y esto finalmente ha resuelto el problema. Tanto el montaje automático como el desmontaje automático funcionaron bien. umount se ejecutó con éxito después del tiempo inactivo predefinido en /etc/autofs.conf

Absolutamente ninguna modificación en el servidor NFS era necesaria.