i supporti autofs non si disconnettono dopo essere inattivi

Ho autofs installato su diversi server Linux che si collegano al server NFS centrale per le directory utenti / home. Funziona benissimo quando si montano le directory all'accesso, ma i montaggi non sembrano mai andare in timeout. Ho controllato / etc / sysconfig / autofs e il valore predefinito è effettivamente impostato su 300, quindi questi dovrebbero scadere dopo 5 minuti.

Il riavvio di autofs smonta tutte le directory, quindi so che è capace.

Ho tentato di usare casualmente lsof nelle directory ma nessun file appare aperto in qualsiasi momento.

Ho anche montato una directory casuale che so non è attiva, ma questi non si smontano mai da soli. Alcune di queste caselle hanno più di 10 utenti che hanno effettuato l'accesso una sola volta e i supporti non cadono mai.

Sto solo cercando di scoprire che esiste un metodo migliore per scoprire perché. Non vedo nulla di specifico in alcun registro.

Eventuali suggerimenti sono apprezzati. Grazie!

AGGIORNARE

Ho attivato il debug per autofs ma non sembra rivelare nulla di straordinario. Questi log sono stati generati 7 minuti dopo il montaggio iniziale di / home / user1 e dopo 6 minuti di inattività. In base all'impostazione predefinita di 5 minuti, questo avrebbe dovuto essere smontato. Non ho mai visto un registro che indicava che era stato fatto un tentativo di smontare.

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

Aggiornamento 2 Dopo aver parlato con il supporto di Red Hat a riguardo, la soluzione è stata quella di abbreviare il valore di timeout per le home directory. L'ho fatto e sembra buono. Qualcosa a quanto pare sta attraversando il punto di montaggio ogni 2 1/2 a 3 minuti e facendo sì che questo rimanga in piedi.

La soluzione era aggiungere il valore di timeout al file /etc/auto.master per quel mapping:

 /home     /etc/auto_home --timeout=120

Oltre a TIMEOUT, l'autofs variabile ha un intervallo di controllo:

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

È uguale a TIMEOUT / 4. Ogni TIMEOUT / 4 secondi autofs chiede al kernel quando la directory è stata letta l'ultima volta. Quindi nel tuo ambiente hai smontato la directory dopo 375 secondi di inattività.

Per ottenere registro più dettagliato si dovrebbe aggiungere LOGGING="debug"a/etc/sysconfig/autofs

Ho avuto un problema simile. Ho reinstallato il nostro server RHEL 4.7 ProLiant di 10 anni con CentOS 6 durante le vacanze di Natale. Avevo 2 ProLiants più recenti su cui sono stato in grado di installare CentOS 7 più di recente (ad aprile).

Ho configurato il montaggio automatico delle home directory dal server CentOS 6 usando una linea /etc/auto.mastersui server CentOS 7 in questo modo:

/home   /etc/auto.home

Quindi ho creato un nuovo /etc/auto.homefile sui server CentOS 7 inizialmente con una riga:

*      sam:/home/&

Le home directory non smonterebbero comunque. Ho anche scoperto che alcune delle proprietà dei file nelle directory home di volta in volta finivano con un enorme UID e numero GID contro di loro. Cambierebbe qualche minuto dopo.

Ho impostato il livello di registrazione su "debug" /etc/autofs.confe ho iniziato a guardarlo journalctl -fu autofs.service. Ho visto messaggi quasi identici come mostrato sopra, che sembrava non contenere indizi.

Poiché non ero ancora stato in grado di capire NFS 4 e sapevo che il nostro server CentOS 6 stava esportando le sue condivisioni come NFS 4 per impostazione predefinita, ho provato ad aggiungere nfsvers=3al /etc/auto.homefile in questo modo:

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

Stavo anche vedendo lo strano messaggio sul tentativo di montare directory come /home/lib, quindi ho aggiunto le singole home directory su linee separate. (Probabilmente avrebbe dovuto provare i montaggi diretti a questo punto o provare gli automount di systemd.)

Ora ho iniziato a vedere messaggi come:

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

Le home directory ora hanno iniziato a smontare dopo 10 minuti come avrebbero dovuto - quindi nel mio caso si è trattato di un problema con NFS 4 non configurato correttamente.

Importante: dopo aver riconfigurato le mappe, fare semplicemente systemctl daemon-reloado systemctl reload autofsnon ha alcun effetto. Ho dovuto faresystemctl restart autofs

Per chiunque abbia problemi simili, ci sono processi GUI su desktop moderni che scansionano continuamente le unità. In particolare Nautilus su Gnome e Dolphin su KDE insieme ad applicazioni di indicizzazione di file come Baloo. Questi sono tutti in grado di causare il sintomo.

Per me (con KDE) l'unico indizio della registrazione di debug con automount era "1 rimanente", ad esempio:

    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

Questo non identificava davvero la fonte. Inoltre, nessuno di lsof, fuser e auditctl (auditd) ha fornito informazioni dettagliate.

Alla fine, per processo di eliminazione, ho determinato che c'erano 2 domande:

• KSysGuard (monitor del sistema KDE)
• Dolphin (File Manager)

Il problema con Dolphin potrebbe essere risolto in questo caso "nascondendo" il disco montato offensivo nella sua vista ad albero.

KSysGuard non sembra configurabile, ma forse è insolito averlo in esecuzione a lungo termine a meno che non si stia eseguendo il debug di qualcosa. Si spera che altre applicazioni possano essere più configurabili nel consentire le esclusioni per impedire la scansione del punto di montaggio automatico.

Oggi ho passato ore a cercare di eseguire il debug e problemi simili. Ecco cosa ho trovato e come ho lavorato.]

installazione: volevo montare automaticamente la directory contenente le directory home degli utenti dal server nfs "srv1: / srv / homes" su / mnt / nfs / homes sui client. I server NFS esportano NFS4. versione autofs 5.1.3

Avevo configurato tutti i client in questo modo:

/etc/auto.mount: file contenente quanto segue:

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

/etc/auto.home:

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

Alla fine questo rappresenta una mappa indiretta. Il montaggio automatico funziona come un incantesimo. Ottengo il volume NFS correttamente montato e funzionante. Ma ... non viene mai smontato automaticamente. Anche se il file autofs.conf dice:

e mountmostra un timeout di 600 secondi:

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

Stavo vedendo esattamente lo stesso nei registri autofs (debug log level) di journalctl come 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 quel tempo ho rinunciato alle autofs e ho deciso di replicare la configurazione di automount con systemd. In realtà l'ho eseguito e in questo momento tutto ha funzionato alla grande - montaggio automatico, smontaggio automatico dopo un periodo di inattività predefinito. Semplicemente perfetto. Ma systemd ... un po 'goffo (non spararmi, in realtà mi piace). Poi ho visto come systemd gestisce il montaggio automatico:

#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 differenza tra # 1 # e # 2 # è che quest'ultima è la mappa diretta mentre # 1 # è indiretta. Quindi ho immediatamente deciso di riconfigurare autofs su un altro client e creare una mappa diretta come quella:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

E questo alla fine ha risolto il problema. Sia auto mount che auto umount hanno funzionato bene. umount è stato eseguito correttamente dopo il tempo di inattività predefinito in /etc/autofs.conf

Non è stata assolutamente necessaria alcuna modifica sul server NFS.