Autofs-Halterungen werden nach Inaktivität nicht getrennt

Ich habe Autofs auf mehreren Linux-Servern installiert, die eine Verbindung zum zentralen NFS-Server für die Benutzer- / Home-Verzeichnisse herstellen. Es funktioniert hervorragend, wenn die Verzeichnisse beim Anmelden gemountet werden, aber die Mounts scheinen nie eine Zeitüberschreitung zu haben. Ich habe / etc / sysconfig / autofs überprüft und die Standardeinstellung ist in der Tat 300, daher sollte diese nach 5 Minuten abgelaufen sein.

Beim Neustart von autofs werden alle Verzeichnisse umountet , daher weiß ich, dass dies möglich ist.

Ich habe versucht, lsof zufällig in den Verzeichnissen zu verwenden, aber es werden zu keinem Zeitpunkt Dateien geöffnet.

Ich habe auch ein zufälliges Verzeichnis gemountet, von dem ich weiß, dass es nicht aktiv ist, aber diese stellen sich nie selbst bereit. Einige dieser Boxen haben mehr als 10 Benutzer, die sich einmal angemeldet haben, und die Reittiere fallen nie ab.

Ich versuche nur herauszufinden, warum es eine bessere Methode gibt, um herauszufinden, warum. Ich sehe in keinem Protokoll etwas Bestimmtes.

Anregungen sind willkommen. Vielen Dank!

AKTUALISIEREN

Ich habe das Debuggen für Autofs aktiviert, aber es scheint nichts Außergewöhnliches zu enthüllen. Diese Protokolle wurden 7 Minuten nach dem ersten Mounten von / home / user1 und nach 6 Minuten Inaktivität erstellt. Gemäß der 5-Minuten-Standardeinstellung sollte dies nicht bereitgestellt worden sein. Ich habe nie ein Protokoll gesehen, das darauf hinwies, dass sogar versucht wurde, es zu umounten.

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

Update 2 Nachdem Sie mit dem Red Hat-Support darüber gesprochen hatten, bestand die Lösung darin, den Timeout-Wert für Home-Verzeichnisse zu verkürzen. Ich habe das gemacht und sieht gut aus. Anscheinend überquert etwas den Montagepunkt alle 2 1/2 bis 3 Minuten und bewirkt, dass dieser oben bleibt.

Die Lösung bestand darin, den Timeout-Wert zur Datei /etc/auto.master für diese Zuordnung hinzuzufügen:

 /home     /etc/auto_home --timeout=120

Neben TIMEOUT hat die Variable autofs ein Prüfintervall:

# 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 ist gleich TIMEOUT / 4. Alle TIMEOUT / 4 Sekunden fragt autofs den Kernel, wann das letzte Mal auf das Verzeichnis zugegriffen wurde. In Ihrer Umgebung ist das Verzeichnis nach 375 Sekunden Inaktivität umnounted.

Um detailliertere Protokoll Sie hinzufügen sollten LOGGING="debug"zu/etc/sysconfig/autofs

Ich hatte ein ähnliches Problem. In der Weihnachtspause habe ich unseren 10 Jahre alten RHEL 4.7 ProLiant Server mit CentOS 6 neu installiert. Ich hatte 2 neuere ProLiants, auf denen ich kürzlich (im April) CentOS 7 installieren konnte.

Ich habe das automatische Bereitstellen der Home-Verzeichnisse vom CentOS 6-Server mithilfe einer Zeile /etc/auto.masterauf den CentOS 7-Servern wie folgt konfiguriert :

/home   /etc/auto.home

Dann habe ich zunächst eine neue /etc/auto.homeDatei auf den CentOS 7-Servern mit einer Zeile erstellt:

*      sam:/home/&

Die Home-Verzeichnisse würden jedoch nicht ausgehängt. Ich fand auch heraus, dass einige der Dateibesitzer in den Home-Verzeichnissen von Zeit zu Zeit eine riesige UID- und GID-Nummer gegen sie hatten. Es würde sich einige Minuten später ändern.

Ich habe die Protokollierungsstufe auf "Debuggen" eingestellt /etc/autofs.confund beginne mit dem Anschauen journalctl -fu autofs.service. Ich sah fast identische Nachrichten wie oben gezeigt, die keine Hinweise zu enthalten schienen.

Da ich NFS 4 noch nicht verstehen konnte und wusste, dass unser CentOS 6-Server seine Freigaben standardmäßig als NFS 4 exportiert, habe ich versucht nfsvers=3, der /etc/auto.homeDatei Folgendes hinzuzufügen :

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

Ich sah auch die seltsame Meldung über den Versuch, Verzeichnisse wie zu mounten /home/lib, also fügte ich die einzelnen Home-Verzeichnisse in separaten Zeilen hinzu. (Wahrscheinlich hätte ich zu diesem Zeitpunkt direkte Mounts oder systemd Automounts ausprobieren sollen.)

Jetzt sah ich Nachrichten wie:

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

Die Bereitstellung der Home-Verzeichnisse begann nun nach 10 Minuten, wie sie sollten - daher war es in meinem Fall ein Problem mit falsch konfiguriertem NFS 4.

Wichtig: Nach dem Neukonfigurieren der Karten kann dies einfach ausgeführt werden systemctl daemon-reloadoder systemctl reload autofshat keine Auswirkung. ich musste es tunsystemctl restart autofs

Für alle anderen, bei denen ähnliche Probleme auftreten, gibt es GUI-Prozesse auf modernen Desktops, die die Laufwerke kontinuierlich scannen. Insbesondere Nautilus auf Gnome und Dolphin auf KDE sowie Dateiindizierungsanwendungen wie Baloo. Diese können alle das Symptom verursachen.

Für mich (mit KDE) war der einzige Hinweis aus der automatischen Debug-Protokollierung "1 verbleibend", z.

    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

Dies identifizierte die Quelle nicht wirklich. Auch keiner von lsof, fuser und auditctl (auditd) gab einen Einblick.

Schließlich stellte ich durch den Eliminierungsprozess fest, dass es 2 Anträge gab:

• KSysGuard (KDE-Systemmonitor)
• Dolphin (Dateimanager)

Das Problem mit Dolphin könnte in diesem Fall behoben werden, indem die fehlerhafte gemountete Festplatte in ihrer Baumansicht "ausgeblendet" wird.

KSysGuard scheint nicht konfigurierbar zu sein, aber es ist möglicherweise ungewöhnlich, dass es langfristig ausgeführt wird, es sei denn, Sie debuggen etwas. Hoffentlich können andere Anwendungen besser konfiguriert werden, wenn Ausschlüsse zugelassen werden, um zu verhindern, dass der Automount-Mount-Punkt gescannt wird.

Ich habe heute stundenlang versucht, ein ähnliches Problem zu beheben. Hier ist, was ich gefunden habe und wie ich es umgangen habe.]

setup: Ich wollte ein Verzeichnis mit den Home-Verzeichnissen der Benutzer vom NFS-Server "srv1: / srv / Homes" unter / mnt / nfs / Homes auf Clients automatisch mounten. NFS-Server exportieren NFS4. autofs version 5.1.3

Ich hatte jeden Client so konfiguriert:

/etc/auto.mount: Datei mit folgenden Inhalten:

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

/etc/auto.home:

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

Letztendlich stellt dies eine indirekte Karte dar. Auto Mount funktioniert wie ein Zauber. Ich bekomme das NFS-Volume richtig gemountet und funktioniert. Aber ... es wird nie automatisch abmontiert. Obwohl die Datei autofs.conf sagt:

und mountzeigt 600 Sekunden Timeout:

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

Ich sah genau das gleiche in den Autofs-Protokollen (Debug-Protokollstufe aktivieren) von journalctl als 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

Zu dieser Zeit gab ich autofs auf und beschloss, die automount-Konfiguration mit systemd zu replizieren. Eigentlich habe ich es ausgeführt und zu diesem Zeitpunkt hat alles super funktioniert - Auto Mount, Auto Unmount nach vordefinierter Leerlaufzeit. Einfach perfekt. Aber systemd ... ein bisschen ungeschickt (schieß nicht auf mich, ich mag es wirklich). Dann habe ich mir angesehen, wie systemd mit der automatischen Montage umgeht:

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

Der Unterschied zwischen # 1 # und # 2 # besteht darin, dass letztere eine direkte Karte ist, während # 1 # indirekt ist. Daher habe ich mich sofort entschlossen, autofs auf einem anderen Client neu zu konfigurieren und eine direkte Karte wie diese zu erstellen:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

Und das hat schließlich das Problem gelöst. Sowohl Auto Mount als auch Auto Umount funktionierten einwandfrei. umount wurde erfolgreich nach der vordefinierten Leerlaufzeit in /etc/autofs.conf ausgeführt

Es war absolut keine Änderung am NFS-Server erforderlich.