autofs монтирует не разъединение после неактивный

Помимо переменной ТАЙМ-АУТА autofs имеет интервал проверки:

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

Это равно ТАЙМ-АУТУ/4. Каждые секунды ТАЙМ-АУТА/4 autofs спрашивают ядро, когда к каталогу получили доступ в прошлый раз. Таким образом в Вашей среде Вам размонтировали каталог после 375 секунд неактивности.

Для получения более подробного журнала, необходимо добавить LOGGING="debug" кому: /etc/sysconfig/autofs

У меня была похожая проблема. Я переустановил наш 10-летний сервер RHEL 4.7 ProLiant с CentOS 6 во время рождественских каникул. У меня было 2 более новых ProLiant, на которые я смог установить CentOS 7 совсем недавно (в апреле).

Я настроил автомонтирование домашних каталогов с сервера CentOS 6, используя строку в /etc/auto.master на серверах CentOS 7 следующим образом:

/home   /etc/auto.home

Затем я создал новый / etc/auto.home на серверах CentOS 7 изначально со строкой:

*      sam:/home/&

Однако домашние каталоги не размонтировались. Я также обнаружил, что некоторые из владельцев файлов в домашних каталогах время от времени оказывались против них огромными номерами UID и GID. Через несколько минут он изменится.

Я установил уровень ведения журнала «debug» в /etc/autofs.conf и начал просмотр с помощью journalctl -fu autofs.service. Я видел почти такие же сообщения, как показано выше, которые, казалось, не содержали подсказок.

Поскольку я еще не разбирался в NFS 4 и знал, что наш сервер CentOS 6 по умолчанию экспортирует свои общие ресурсы как NFS 4, я попытался добавить nfsvers=3 в /etc/auto.home примерно так:

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

Я также видел странное сообщение о попытке смонтировать каталоги типа /home/lib, поэтому добавил отдельные домашние каталоги в отдельные строки. (Возможно, в этот момент следовало попробовать прямое монтирование или системное автомонтирование.)

Теперь я начал видеть такие сообщения, как:

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

Домашние каталоги теперь начали размонтироваться через 10 минут, как и должны были — так что в моем случае это была проблема с неправильно настроенной NFS 4.

Важно: после перенастройки карт простое выполнение systemctl daemon-reload или systemctl reload autofs не дает никакого эффекта. Мне пришлось systemctl перезапустить autofs

Сегодня я провел несколько часов, пытаясь отладить аналогичную проблему. Вот что я нашел и как я с этим справился.]

setup :Я хотел автоматически смонтировать каталог, содержащий домашние каталоги пользователей, с сервера nfs "srv1 :/srv/homes" в /mnt/nfs/homes на клиентах. Серверы NFS экспортируют NFS4. версия autofs 5.1.3

Я так настраивал каждый клиент:

/etc/auto.mount :файл, содержащий следующее:

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

/etc/auto.home:

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

В конце концов это представляет собой непрямую карту. Автоматическое крепление работает как шарм. Я правильно смонтировал и заработал том NFS. Но... он никогда не размонтируется автоматически. Несмотря на то, что файл autofs.conf говорит:

и mountпоказывают время ожидания 600 секунд:

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

Точно то же самое я видел на (уровне журнала отладки, активирующем )журналы autofs из журналаctl как 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

В то время я отказался от autofs и решил воспроизвести конфигурацию автомонтирования с помощью systemd. На самом деле я запустил его, и в это время все отлично работало -автоматическое монтирование, автоматическое размонтирование после заданного периода простоя. Просто идеально. А вот systemd... немного корявый (не стреляйте в меня, он мне даже нравится ). Затем я посмотрел, как systemd обрабатывает автоматическое монтирование :

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

Разница между #1 #и #2 #заключается в том, что последний является прямым отображением, тогда как #1 #является косвенным. Поэтому я сразу решил перенастроить autofs на другом клиенте и создать такую ​​прямую карту:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

И это, в конце концов, решило проблему. И автоматическое монтирование, и автоматическое размонтирование работали нормально. umount был успешно запущен после предопределенного времени простоя в /etc/autofs.conf

Абсолютно никаких изменений на сервере NFS не потребовалось.

Для всех, у кого возникают подобные проблемы, есть процессы с графическим интерфейсом на современных настольных компьютерах, которые постоянно сканируют диски. В частности, Nautilus в Gnome и Dolphin в KDE, а также приложения для индексации файлов, такие как Baloo. Все они способны вызвать симптом.

Для меня (запускающего KDE )единственной подсказкой из журнала отладки автомонтирования было «1 оставшийся», например:

    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

Это на самом деле не идентифицировало источник. Также ни один из lsof, fuser и auditctl (auditd )не дал никакого понимания.

В конце концов методом исключения я определил, что было 2 приложения:

• KSysGuard (Системный монитор KDE)
• Дельфин (Диспетчер файлов)

В этом случае проблема с Dolphin может быть решена путем «скрытия» неисправного подключенного диска в его древовидном представлении.

KSysGuard не кажется настраиваемым, но, возможно, необычно, чтобы он работал долго, если только вы не занимаетесь отладкой чего-либо. Будем надеяться, что другие приложения могут быть более гибкими в разрешении исключений для предотвращения сканирования точки монтирования при автоматическом монтировании.