montagens autofs não desconectam após inativo


10

Tenho autofs instalados em vários servidores Linux que estão se conectando ao servidor NFS central para os diretórios usuários / home. Funciona muito bem ao montar os diretórios no login, mas as montagens nunca parecem esgotar o tempo limite. Eu verifiquei o arquivo / etc / sysconfig / autofs e o padrão é realmente definido como 300, portanto, o tempo limite deve exceder após 5 minutos.

Reiniciar autofs desmonta todos os diretórios, então eu sei que é capaz.

Eu tentei usar lsof aleatoriamente nos diretórios, mas nenhum arquivo aparece aberto a qualquer momento.

Eu também montei um diretório aleatório que sei que não está ativo, mas eles nunca se somam. Algumas dessas caixas têm mais de 10 usuários que efetuaram login uma vez e as montagens nunca caem.

Só estou tentando descobrir a partir de que existe um método melhor para descobrir o porquê. Não vejo nada específico em nenhum registro.

Todas as sugestões são apreciadas. Obrigado!

ATUALIZAR

Ativei a depuração para autofs, mas parece não revelar nada fora do comum. Esses logs foram gerados 7 minutos após a montagem inicial do / home / user1 e após 6 minutos de inatividade. De acordo com o padrão de 5 minutos, isso deveria ter sido desmontado. Eu nunca vi um registro que indicava uma tentativa de quantia.

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

Atualização 2 Depois de conversar com o suporte da Red Hat sobre isso, a solução acabou diminuindo o valor do tempo limite dos diretórios pessoais. Eu fiz isso e parece bem. Aparentemente, algo está atravessando o ponto de montagem a cada 2 1/2 a 3 minutos e fazendo com que ele permaneça ativo.

A solução foi adicionar o valor do tempo limite ao arquivo /etc/auto.master para esse mapeamento:

 /home     /etc/auto_home --timeout=120

quais comandos você está usando para determinar se essas montagens estão presentes? Presumo df, mas só quero esclarecer.
Banjer

Sim, estou usando o df para verificar o espaço montado. Eu apenas cd para os diretórios como root para que eles montem.
SteveHNH

Respostas:


4

Além da variável TIMEOUT, autofs possui um intervalo de verificação:

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

É igual a TIMEOUT / 4. A cada TIMEOUT / 4 segundos, o autofs pergunta ao kernel quando o diretório foi acessado pela última vez. Portanto, em seu ambiente, você tem um diretório desmontado após 375 segundos de inatividade.

Para obter um registro mais detalhado, você deve adicionar LOGGING="debug"ao/etc/sysconfig/autofs


Eu vejo. Obrigado pelo esclarecimento. Os logs acima continuaram bem após os 6 minutos de inatividade e excederam 375 segundos. Eu continuo pensando que algo tem que estar acessando esses diretórios, ou a quantidade seria tentada. Eu acho que meu objetivo real é descobrir o que está acessando este diretório, se houver. Essa pode ser a única razão pela qual consigo pensar que isso não importaria.
SteveHNH

1

Eu tive um problema parecido. Reinstalei nosso servidor RHEL 4.7 ProLiant de 10 anos com o CentOS 6 durante as férias de Natal. Eu tinha dois ProLiants mais recentes nos quais pude instalar o CentOS 7 mais recentemente (em abril).

Configurei a montagem automática dos diretórios pessoais do servidor CentOS 6 usando uma linha nos /etc/auto.masterservidores CentOS 7 da seguinte maneira:

/home   /etc/auto.home

Então, criei um novo /etc/auto.homearquivo nos servidores CentOS 7 inicialmente com uma linha:

*      sam:/home/&

Os diretórios pessoais não desmontariam, no entanto. Também descobri que algumas das propriedades dos arquivos nos diretórios pessoais acabavam, de tempos em tempos, com um grande número de UID e GID. Isso mudaria alguns minutos depois.

Defino o nível de log como 'debug' /etc/autofs.confe comece a assistir journalctl -fu autofs.service. Vi mensagens quase idênticas, como mostrado acima, que pareciam não conter pistas.

Como ainda não conseguia entender o NFS 4 e sabia que nosso servidor CentOS 6 estava exportando seus compartilhamentos como NFS 4 por padrão, tentei adicionar nfsvers=3ao /etc/auto.homearquivo da seguinte maneira:

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

Eu também estava vendo a mensagem estranha sobre tentar montar diretórios como /home/lib, então adicionei os diretórios pessoais individuais em linhas separadas. (Provavelmente deveria ter tentado montagens diretas neste momento ou tentado montagens automáticas do systemd.)

Agora comecei a ver mensagens como:

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

Os diretórios pessoais agora começaram a desmontar após 10 minutos, como deveriam - então, no meu caso, havia um problema com o NFS 4 mal configurado.

Importante: depois de reconfigurar os mapas, simplesmente fazer systemctl daemon-reloadou systemctl reload autofsnão tem efeito. eu tive que fazersystemctl restart autofs


1

Para qualquer outra pessoa que tenha problemas semelhantes, existem processos de GUI em desktops modernos que examinam as unidades continuamente. Em particular o Nautilus no Gnome e o Dolphin no KDE, juntamente com aplicativos de indexação de arquivos como o Baloo. Todos são capazes de causar o sintoma.

Para mim (executando o KDE), a única pista do registro de depuração automount era "1 restante", por exemplo:

    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

Isso realmente não identificou a fonte. Também nenhum dos lsof, fuser e auditctl (auditd) forneceram qualquer insight.

Eventualmente, por processo de eliminação, determinei que havia duas aplicações:

  • KSysGuard (monitor do sistema KDE)
  • Dolphin (Gerenciador de Arquivos)

O problema com o Dolphin pode ser corrigido nesse caso "ocultando" o disco montado incorreto na visualização em árvore.

O KSysGuard não parece configurável, mas talvez seja incomum tê-lo em execução a longo prazo, a menos que você esteja depurando alguma coisa. Esperamos que outros aplicativos possam ser mais configuráveis ​​ao permitir exclusões para impedir que o ponto de montagem da montagem automática seja varrido.


Para sua informação, se você fizer login antes de editar sua postagem, não precisará aprová-la mais tarde (ou aguardar horas para que outras pessoas a aprovem).
G-Man diz 'Reinstate Monica'

0

Passei horas hoje tentando depurar e problema semelhante. Aqui está o que eu encontrei e como trabalhei.]

instalação: eu queria montar automaticamente o diretório contendo os diretórios pessoais dos usuários do servidor nfs "srv1: / srv / homes" em / mnt / nfs / homes nos clientes. Os servidores NFS exportam o NFS4. autofs versão 5.1.3

Eu havia configurado todos os clientes assim:

/etc/auto.mount: arquivo contendo o seguinte:

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

/etc/auto.home:

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

Eventualmente, isso representa um mapa indireto. A montagem automática funciona como um encanto. Recebo o volume NFS adequadamente montado e funcionando. Mas ... nunca é desmontado automaticamente. Mesmo que o arquivo autofs.conf diga:

e mountmostra 600 segundos de tempo limite:

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

Eu estava vendo exatamente o mesmo nos logs de autofs (depuração do nível de log ativado) do journalctl como 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

Naquele momento, desisti do autofs e decidi replicar a configuração do automount com o systemd. Na verdade, eu o executei e, neste momento, tudo funcionou muito bem - montagem automática, desmontagem automática após um período inativo predefinido. Simplesmente perfeito. Mas systemd ... um pouco desajeitado (não atire em mim, eu realmente gosto). Depois, observei como o systemd lida com a montagem automática:

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

A diferença entre # 1 # e # 2 # é que este último é o mapa direto, enquanto o # 1 # é indireto. Por isso, decidi imediatamente reconfigurar autofs em outro cliente e criar um mapa direto assim:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

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

E isso acabou resolvendo o problema. A montagem automática e a montagem automática funcionaram bem. umount foi executado com êxito após o tempo ocioso predefinido no /etc/autofs.conf

Absolutamente nenhuma modificação no servidor NFS foi necessária.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.