find: Dateisystemschleife erkannt

9

Wenn ich versuche, eine Datei mit zu finden find -name "filename", wird folgende Fehlermeldung angezeigt:

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

Ich habe den ls -ldi /var/named/chroot/var/named/ /var/namedBefehl ausgeführt und die Inode-Nummern sind gleich. Nachforschungen haben ergeben, dass der Fix darin besteht, den Hardlink /var/named/chroot/var/named/mithilfe rm -feines Verzeichnisses zu löschen und neu zu erstellen. Wenn ich dies tue, wird mir jedoch empfohlen, dass er nicht gelöscht werden kann, da es sich bereits um ein Verzeichnis handelt. Wie behebe ich das? Ich verwende Centos 6 mit Plesk 11.

Der Befehl mount gibt Folgendes an:

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

linux centos

— user1780242
quelle

9

named, das ist der DNS-Server, läuft in einer Chroot. Um auf die Konfigurationsdatei zuzugreifen, verwendet das Startskript mount --bind, um das Konfigurationsverzeichnis in der Chroot sichtbar zu machen. Dies bedeutet , dass /var/named/das gleiche wie /var/named/chroot/var/namedund /var/named/chroot/var/named/chroot/var/namedund so weiter. Dies ist eine rekursive Verzeichnisstruktur. Wenn Sie also findversuchen, alles zu durchqueren, kann sie die Ausführung niemals beenden. Sie erkennt also, dass die beiden Verzeichnisse tatsächlich identisch sind, und druckt diese Nachricht aus, um Sie zu warnen.

Die Nachricht bedeutet, dass findnicht nach innen gesucht wird, /var/named/chroot/var/namedda festgestellt wurde, dass es sich um dasselbe Verzeichnis handelt, das bereits zuvor angezeigt wurde. Es ist eine völlig harmlose Nachricht, die Sie ignorieren können: Nach dem Überspringen wird /var/named/chroot/var/namedder findVorgang normal fortgesetzt.

— pqnet
quelle

Wenn nach dieser Anweisung nichts mehr steht, bedeutet dies einfach, dass die Datei nicht gefunden wurde?

— user1780242

Ja, denke schon. Versuchen Sie dasselbe mit einer Datei, von der Sie wissen, dass sie existiert. Sie können auch Fehlermeldungen unterdrücken, indem Sie der Befehlszeile "2> / dev / null" hinzufügen.

— pqnet

1

Die Nachricht löst einen Rückkehrcode 1 aus und kann nicht ignoriert werden. Die Umleitung funktioniert auch nicht.

Verwenden von findutils findutils-4.4.2-6.el6.x86_64

Es scheint, dass dies der entsprechende Fehlerbericht ist:

Auf Systemen, auf denen der Linux-Kernel ausgeführt wird, erzeugt "find -printf% F" nicht mehr die falsche Antwort für Dateien auf Dateisystemen, die mit "mount --bind" an anderer Stelle erneut bereitgestellt wurden. (Savannah Bug # 14921).

Eine (sicherheitsrelevante) Lösung, wenn Sie das betroffene Skript nicht reparieren können (dh weil es von einem Drittanbieter geschrieben wurde), besteht darin, das Bind-Chroot-Paket zumindest vorübergehend zu entfernen.

— Florian Heigl
quelle

0

Ich denke nicht, dass es eine harte Verbindung ist. Normalerweise sind Verzeichnis-Hardlinks verboten. Ich könnte ein Softlink sein, aber es sieht so aus, als wäre es eine Mount-Schleife: Es scheint, dass /var/namedoder vielleicht /varwieder montiert wird /var/named/chroot. Vielleicht ist es ein Bind-Mount ( mount -o bind) oder nur ein normaler Mount.

Können Sie die Ausgabe Ihres mountBefehls veröffentlichen? Vielleicht ist dies auch ein Reittier, das für das Chroot-Gefängnis benötigt wird, und Sie sollten es besser verlassen.

— Migtor
quelle

Es ist wahrscheinlich ein, mount --bindweil es das einzige ist, was in einer Chroot funktioniert.

— pqnet

0

Das Problem wird durch das Init-Skript verursacht, über nameddas das /var/namedVerzeichnis bereitgestellt wird /var/named/chroot. Die Lösung für dieses Problem ist auch im Init-Skript enthalten.

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

Wie oben erwähnt, mountfunktioniert die Funktion nur, wenn das Verzeichnis leer ist. Verwenden Sie also die folgende Lösung:

Halt named
Erstellen Sie das Verzeichnis /var/named/chroot/var/named
Erstellen Sie eine leere Datei in diesem Verzeichnis
Start named

— user202132
quelle