find: loop do sistema de arquivos detectado

Question

Quando tento encontrar um arquivo usando find -name "filename" , recebo um erro que diz:

./var/named/chroot/var/named' is part of the same file system loop as './var/named'

Eu executei o comando ls -ldi /var/named/chroot/var/named/ /var/named e os números de inode são os mesmos. A pesquisa indica que a correção é excluir o link físico /var/named/chroot/var/named/ usando rm -f e recriá-lo como um diretório, mas quando faço isso, é aconselhável que ele não possa ser excluído porque já é um diretório. Como faço para corrigir isso? Estou rodando o Centos 6 com o Plesk 11.

O comando mount dá isto:

/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/etc/named on /var/named/chroot/etc/named type none (rw,bind)
/var/named on /var/named/chroot/var/named type none (rw,bind)
/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)
/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)
/usr/lib64/bind on /var/named/chroot/usr/lib64/bind type none (rw,bind)
/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)
/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

    

Answer 1

named , que é o servidor DNS, é executado em um chroot. Para acessar o arquivo de configuração, o script de inicialização usa mount --bind para tornar o diretório de configuração visível dentro do chroot. Isso significa que /var/named/ é igual a /var/named/chroot/var/named e /var/named/chroot/var/named/chroot/var/named e assim por diante. Esta é uma estrutura de diretórios recursiva, portanto, se find tentasse atravessá-la, nunca seria capaz de terminar sua execução, então ela percebe que os dois diretórios são realmente os mesmos e imprime essa mensagem para avisá-lo.

A mensagem significa que find não pesquisará dentro de /var/named/chroot/var/named porque percebeu que é igual a outro diretório já visto anteriormente. É uma mensagem totalmente inofensiva, você pode ignorá-la com segurança: após ignorar /var/named/chroot/var/named , a operação find continua normalmente.

    

Answer 2

A mensagem dispara um código de retorno 1 e não pode ser ignorada, nem o trabalho de redirecionamento.

Usando findutils findutils-4.4.2-6.el6.x86_64

Parece que este é o relatório de erros correspondente:

On systems running the Linux kernel, "find -printf %F" no longer produces the wrong answer for files on filesystems that have been remounted elsewhere using "mount --bind". (Savannah bug #14921).

Uma solução (desafiada por segurança) se você não puder corrigir o script afetado (por exemplo, porque foi escrito por terceiros) é remover o pacote bind-chroot, pelo menos temporariamente.

    

Answer 3

Eu não acho que seja um link difícil. Normalmente, os links rígidos do diretório são proibidos. Eu poderia ser um link flexível, mas parece que é um loop de montagem: parece que /var/named ou talvez /var está montado novamente em /var/named/chroot . Talvez seja uma montagem de ligação ( mount -o bind ) ou apenas uma montagem normal.

Você pode postar a saída do seu comando mount ? Além disso, talvez este seja um monte necessário para a cadeia de chroot e é melhor deixá-lo.

    

Answer 4

O problema é causado pelo script de inicialização de named , que monta o diretório /var/named sobre /var/named/chroot . A solução para este problema também está presente no script de inicialização.

mount_chroot_conf()
{
   # Mount source is a directory. Mount it only if directory in chroot is
   # empty.

Como mencionado acima, a função mount funcionará somente se o diretório estiver vazio. Então use a solução abaixo:

1. Parar named
2. Crie o diretório /var/named/chroot/var/named
3. Crie um arquivo vazio dentro deste diretório
4. Iniciar named