instalacje autofs nie odłączają się po nieaktywności

Mam autofs zainstalowany na kilku serwerach Linux, które łączą się z centralnym serwerem NFS dla użytkowników / katalogów domowych. Działa świetnie podczas montowania katalogów podczas logowania, ale montowania nigdy nie wydają się przekroczyć limitu czasu. Sprawdziłem / etc / sysconfig / autofs i domyślnie jest ustawiony na 300, więc powinny upłynąć limit czasu po 5 minutach.

Ponowne uruchomienie autofs powoduje odmontowanie wszystkich katalogów, więc wiem, że jest w stanie.

Próbowałem użyć lsof losowo w katalogach, ale żadne pliki nie wydają się otwarte w żadnym momencie.

Zamontowałem także losowy katalog, o którym wiem, że nie jest aktywny, ale nigdy się nie zamontują. Niektóre z tych skrzynek mają ponad 10 użytkowników, którzy zalogowali się raz, a wierzchowce nigdy nie spadają.

Próbuję się dowiedzieć, czy istnieje lepsza metoda, aby dowiedzieć się, dlaczego. Nie widzę nic konkretnego w żadnych logach.

Wszelkie sugestie są mile widziane. Dzięki!

AKTUALIZACJA

Włączyłem debugowanie dla autofs, ale wydaje się, że nie ujawnia niczego niezwykłego. Te dzienniki zostały wygenerowane 7 minut po pierwszym zamontowaniu / home / user1 i po 6 minutach braku aktywności. Zgodnie z 5-minutowym domyślnym ustawieniem powinno to zostać odmontowane. Nigdy nie widziałem przechodzącej kłody, która wskazywała, że ​​podjęto próbę umountowania.

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

Aktualizacja 2 Po rozmowie na ten temat ze wsparciem Red Hat, rozwiązaniem było po prostu skrócenie limitu czasu dla katalogów domowych. Zrobiłem to i wygląda dobrze. Najwyraźniej coś przemierza punkt montowania co 2 1/2 do 3 minut i powoduje, że utrzymuje się.

Rozwiązaniem było dodanie wartości limitu czasu do pliku /etc/auto.master dla tego mapowania:

 /home     /etc/auto_home --timeout=120

Poza tym zmienne autofs TIMEOUT mają interwał sprawdzania:

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

Jest równa TIMEOUT / 4. Co TIMEOUT / 4 sekundy autofs pyta jądro, kiedy ostatnio otwierano katalog. Tak więc w twoim środowisku masz katalog umnountowany po 375 sekundach bezczynności.

Aby uzyskać bardziej szczegółowy dziennik, należy dodać LOGGING="debug"do/etc/sysconfig/autofs

Miałem podobny problem. Podczas świątecznej przerwy ponownie zainstalowałem nasz 10-letni serwer RHEL 4.7 ProLiant z CentOS 6. Miałem 2 nowsze wersje ProLiantów, na których mogłem ostatnio zainstalować CentOS 7 (w kwietniu).

Skonfigurowałem automatyczne montowanie katalogów domowych z serwera CentOS 6 za pomocą wejścia liniowego /etc/auto.masterna serwerach CentOS 7 w następujący sposób:

/home   /etc/auto.home

Następnie stworzyłem nowy /etc/auto.homeplik na serwerach CentOS 7 początkowo z linią:

*      sam:/home/&

Jednak katalogi domowe nie zostały odmontowane. Odkryłem również, że niektóre własności plików w katalogach domowych od czasu do czasu kończą się ogromnym numerem UID i GID przeciwko nim. Zmieniłoby się to kilka minut później.

Ustawiam poziom logowania na „debugowanie” /etc/autofs.confi rozpoczęcie oglądania journalctl -fu autofs.service. Widziałem prawie identyczne wiadomości, jak pokazano powyżej, które nie zawierały żadnych wskazówek.

Ponieważ nie byłem jeszcze w stanie zrozumieć NFS 4 i wiedziałem, że nasz serwer CentOS 6 domyślnie eksportuje swoje udziały jako NFS 4, próbowałem dodać nfsvers=3do /etc/auto.homepliku w ten sposób:

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

Widziałem też dziwny komunikat o próbie zamontowania katalogów /home/lib, więc dodałem poszczególne katalogi domowe w osobnych wierszach. (Prawdopodobnie powinien był wypróbować bezpośrednie podłączenie w tym momencie lub wypróbować systemount).

Teraz zacząłem widzieć wiadomości takie jak:

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

Katalogi domowe zaczęły teraz odmontowywać po 10 minutach tak, jak powinny - więc w moim przypadku był to problem ze źle skonfigurowanym NFS 4.

Ważne: po rekonfiguracji map po prostu robi się systemctl daemon-reloadlub systemctl reload autofsnie ma żadnego efektu. musiałem zrobićsystemctl restart autofs

Dla każdego innego, kto ma podobne problemy, są procesy GUI na nowoczesnych komputerach, które stale skanują dyski. W szczególności Nautilus na Gnome i Dolphin na KDE wraz z aplikacjami do indeksowania plików, takimi jak Baloo. Wszystkie są w stanie wywołać objaw.

Dla mnie (działającego KDE) jedyną wskazówką z logowania debugowania automount było „pozostało 1” np .:

    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

To tak naprawdę nie zidentyfikowało źródła. Również żaden z lsof, fuser i auditctl (auditd) nie dał żadnego wglądu.

Ostatecznie w wyniku procesu eliminacji ustaliłem, że były 2 wnioski:

• KSysGuard (monitor systemu KDE)
• Dolphin (Menedżer plików)

W tym przypadku problem z Dolphin można rozwiązać, „ukrywając” obrażający zamontowany dysk w widoku drzewa.

KSysGuard nie wydaje się konfigurowalny, ale być może jest to niezwykłe, że działa długo, chyba że coś debugujesz. Mamy nadzieję, że inne aplikacje mogą być bardziej konfigurowalne zezwalając na wykluczenia, aby zapobiec skanowaniu punktu instalacji automount.

Spędziłem dziś godziny próbując debugować i podobny problem. Oto, co znalazłem i jak sobie z tym poradziłem.]

setup: Chciałem automatycznie zamontować katalog zawierający katalogi domowe użytkowników z serwera nfs „srv1: / srv / homes” w / mnt / nfs / homes na klientach. Serwery NFS eksportują NFS4. wersja autofs 5.1.3

Skonfigurowałem każdego klienta w ten sposób:

/etc/auto.mount: plik zawierający następujące elementy:

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

/etc/auto.home:

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

Ostatecznie stanowi to mapę pośrednią. Automatyczne mocowanie działa jak urok. Otrzymuję wolumin NFS poprawnie zamontowany i działający. Ale ... nigdy nie zostaje automatycznie odmontowane. Mimo że plik autofs.conf mówi:

i mountpokazuje limit czasu 600 sekund:

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

Widziałem dokładnie to samo w dziennikach autofs z dziennikactl (aktywacja poziomu dziennika debugowania) jak 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

W tym czasie zrezygnowałem z autofs i postanowiłem zreplikować konfigurację automount z systemd. Właściwie to go uruchomiłem i w tym czasie wszystko działało świetnie - automatyczne montowanie, automatyczne odmontowywanie po zdefiniowanym okresie bezczynności. Po prostu perfekcyjnie. Ale systemd ... trochę niezdarny (nie strzelaj do mnie, naprawdę to lubię). Potem spojrzałem na to, jak systemd radzi sobie z automatycznym montażem:

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

Różnica między # 1 # i # 2 # polega na tym, że ta ostatnia jest mapą bezpośrednią, podczas gdy # 1 # jest pośrednia. Dlatego od razu postanowiłem zmienić konfigurację autofs na innym kliencie i stworzyć bezpośrednią mapę w ten sposób:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

I to ostatecznie rozwiązało problem. Zarówno auto mount, jak i auto umount działały dobrze. Umount został pomyślnie uruchomiony po uprzednio zdefiniowanym czasie bezczynności w /etc/autofs.conf

Absolutnie nie było potrzeby modyfikacji na serwerze NFS.