autofs кріплення не відключаються після неактивного


10

У мене встановлені автофайли на декількох серверах Linux, які підключаються до центрального сервера NFS для користувачів / домашніх каталогів. Він чудово працює при монтажі каталогів на вході в систему, але монтажі ніколи не затримуються. Я перевірив / etc / sysconfig / autofs, і за замовчуванням дійсно встановлено 300, тому їх слід вичерпати через 5 хвилин.

Перезапуск автофайлів змінює всі каталоги, тому я знаю, що він здатний.

Я намагався використовувати довільно lsof у каталогах, але жоден файл не з’являється відкритим у будь-який час.

Я також встановив випадковий каталог, який, як я знаю, не активний, але вони ніколи не змінюються. У деяких із цих вікон є 10+ користувачів, які ввійшли в систему один раз, і кріплення ніколи не випадають.

Я просто намагаюся з'ясувати, чи є кращий метод з'ясувати, чому. Я не бачу нічого конкретного в жодному журналі.

Будь-які пропозиції вдячні. Дякую!

ОНОВЛЕННЯ

Я ввімкнув налагодження для автофільмів, але це, здається, не виявило нічого незвичайного. Ці журнали були створені через 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 1/2 до 3 хвилин і змушує це залишатися вгору.

Рішення полягало в тому, щоб додати значення timeout у файл /etc/auto.master для цього відображення:

 /home     /etc/auto_home --timeout=120

яку команду (и) ви використовуєте, щоб визначити, що ці кріплення є? Я припускаю df, але просто хочу уточнити.
Банджер

Так, я використовую 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 секунди автофайли запитують ядро, коли в останній раз звертався до каталогу. Тож у вашому оточенні ваш каталог було внесено після 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 automounts.)

Тепер я почав бачити повідомлення типу:

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

Для тих, хто має подібні проблеми, на сучасних настільних комп’ютерах є процеси GUI, які постійно сканують накопичувачі. Зокрема 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 не налаштовується, але тоді, можливо, незвично, щоб він працював довгостроково, якщо ви щось не налагоджуєте. Сподіваємось, інші програми можуть бути налаштовані на дозвіл виключень, щоб запобігти скануванню точки автоматичного монтажу.


FYI, якщо ви ввійдете в систему, перш ніж редагувати свою публікацію, вам не потрібно буде її затверджувати пізніше (або чекати годин, коли інші її затвердять).
G-Man каже "Відновити Моніку"

0

Я сьогодні провів години, намагаючись налагодити та подібну проблему. Ось що я знайшов і як я працював над цим.]

Налаштування: Я хотів автоматично встановити dir, що містить домашні dir-адреси користувачів із сервера nfs "srv1: / srv / homes" на / mnt / nfs / будинки для клієнтів. Сервери 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 і вирішив скопіювати config automount з 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.