find: Loop do sistema de arquivos detectado

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 ls -ldi /var/named/chroot/var/named/ /var/namedcomando 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-o rm -fe recriá-lo como um diretório, mas quando faço isso, sou avisado de que ele não pode ser excluído porque já é um diretório. Como faço para corrigir isso? Estou executando o Centos 6 com o Plesk 11.

O comando mount fornece isso:

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

named, que é o servidor DNS, é executado em um chroot. Para acessar o arquivo de configuração, o script de inicialização usa mount --bindpara tornar o diretório de configuração visível dentro do chroot. Isto significa que /var/named/é o mesmo que /var/named/chroot/var/named, e /var/named/chroot/var/named/chroot/var/namede assim por diante. Essa é uma estrutura de diretório recursiva; portanto, se você findtentar fazer uma inversão de tudo, nunca conseguirá terminar sua execução; portanto, percebe que os dois diretórios são realmente os mesmos e imprime a mensagem para avisá-lo.

A mensagem significa que findnão será pesquisado /var/named/chroot/var/namedpor dentro, porque percebeu que é o mesmo que em outro diretório já visto anteriormente. É uma mensagem totalmente inofensiva, você pode ignorá-la com segurança: depois de pular /var/named/chroot/var/nameda findoperação continua normalmente.

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

Usando findutils findutils-4.4.2-6.el6.x86_64

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

Em sistemas executando o kernel Linux, "find -printf% F" não produz mais a resposta errada para arquivos em sistemas de arquivos que foram remontados em outro lugar usando "mount --bind". (Bug da savana # 14921).

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

Não acho que seja um elo rígido. Geralmente, os links físicos do diretório são proibidos. Eu poderia ser um link flexível, mas parece que é um loop de montagem: parece que /var/namedou talvez ele /varesteja montado novamente /var/named/chroot. Talvez seja uma montagem mount ( mount -o bind) ou apenas uma montagem normal.

Você pode postar a saída do seu mountcomando? Além disso, talvez essa seja uma montagem necessária para a cadeia chroot e é melhor você deixá-la.

O problema é causado pelo script init, namedque monta o /var/nameddiretório /var/named/chroot. A solução para esse problema também está presente no script init.

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

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

1. Pare named
2. Crie o diretório /var/named/chroot/var/named
3. Crie um arquivo vazio dentro deste diretório
4. Começar named