Autofs монтирует не отключаться после неактивности


10

У меня установлены autofs на нескольких Linux-серверах, которые подключаются к центральному NFS-серверу для каталогов users / home. Он прекрасно работает при монтировании каталогов при входе в систему, но монтирование никогда не прекращается. Я проверил / etc / sysconfig / autofs, и по умолчанию он действительно равен 300, поэтому они должны быть отключены через 5 минут.

Перезапуск autofs отключает все каталоги, поэтому я знаю, что это возможно.

Я попытался использовать lsof случайным образом в каталогах, но файлы не открываются в любое время.

Я также смонтировал случайный каталог, который, как я знаю, не активен, но он никогда не размонтируется. Некоторые из этих ящиков имеют более 10 пользователей, которые вошли в систему один раз, и крепления никогда не падают.

Я просто пытаюсь выяснить, есть ли лучший способ выяснить, почему. Я не вижу ничего конкретного в журналах.

Любые предложения приветствуются. Спасибо!

ОБНОВИТЬ

Я включил отладку для autofs, но она, кажется, не показывает ничего необычного. Эти журналы были созданы через 7 минут после первоначального подключения / home / user1 и после 6 минут бездействия. Согласно 5-минутному дефолту, это должно было быть отключено. Я никогда не видел, чтобы в журнале было что-то, что указывало на попытку даже размонтировать.

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

Обновление 2 После того, как вы поговорили об этом со службой поддержки Red Hat, мы решили просто сократить время ожидания для домашних каталогов. Я сделал это и выглядит хорошо. Очевидно, что что-то пересекает точку монтирования каждые 2 с половиной до 3 минут и заставляет это оставаться на месте.

Решением было добавить значение таймаута в файл /etc/auto.master для этого отображения:

 /home     /etc/auto_home --timeout=120

какие команды вы используете для определения наличия этих монтировок? Я предполагаю df, но просто хочу уточнить.
Banjer

Да, я использую df для проверки смонтированного пространства. Я просто перейду в каталоги от имени пользователя root, чтобы их смонтировать.
SteveHNH

Ответы:


4

Кроме того, переменная TIMEOUT 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

Это равно TIMEOUT / 4. Каждые TIMEOUT / 4 секунды autofs спрашивает ядро, когда к каталогу обращались в последний раз. Таким образом, в вашей среде каталог отключен после 375 секунд бездействия.

Чтобы получить более подробный журнал вы должны добавить LOGGING="debug"в/etc/sysconfig/autofs


Понимаю. Спасибо за разъяснения. Журналы выше продолжались хорошо после 6 минут бездействия и превысили 375 секунд. Я продолжаю думать, что что-то должно получить доступ к этим каталогам, иначе будет предпринята попытка размонтирования. Я предполагаю, что моя настоящая цель - выяснить, что обращается к этому каталогу, если что-нибудь. Это может быть единственной причиной, по которой я могу думать, что это не прекратится.
SteveHNH

1

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

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

/home   /etc/auto.home

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

*      sam:/home/&

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

Я установил уровень ведения журнала на «отладку» /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, поэтому добавил отдельные домашние каталоги в отдельных строках. (Вероятно, в этот момент следовало попробовать прямое монтирование или автоматическое монтирование systemd.)

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

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 restart autofs


1

Для тех, кто сталкивается с подобными проблемами, на современных рабочих столах существуют процессы с графическим интерфейсом, которые непрерывно сканируют диски. В частности, 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 не выглядит настраиваемым, но, возможно, это необычно, если он работает долго, если вы что-то не отлаживаете. Надеемся, что другие приложения могут быть более конфигурируемыми в разрешении исключений, чтобы предотвратить сканирование точки монтирования.


К вашему сведению, если вы войдете в систему до редактирования своего поста, вам не нужно будет утверждать его позже (или часами ждать, пока другие люди одобрят его).
G-Man говорит «Восстановить Монику»

0

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

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 из journalctl как 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 не потребовалось.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.