Der Linux-Befehl find verhält sich fehlerhaft

Bei der Suche nach systemaufgelösten Diensten nach der kürzlich bekannt gewordenen Sicherheitsanfälligkeit stellte ich ein sehr merkwürdiges Verhalten des Befehls find fest.

 root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz

Der Befehl gibt 0 oder zwei Zeilen als Ausgabe für den ersten Lauf zurück. Aber wenn ich den Befehl das zweite Mal ausführe, erhalte ich:

root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service

Dies bedeutet, dass "find" beim ersten Mal nicht wirklich alles findet. Auch das passiert nur einmal. Wenn Sie den Befehl das nächste Mal ausführen, wird die korrekte Ausgabe angezeigt. Ich habe dies auf einigen anderen Systemen mit Debian 8 (jessie) überprüft. Bei Kernel 4.9 und höher tritt dieses Problem immer auf, bei Kernel 3.16-Systemen jedoch nicht.
Nach dem Neustart des Systems geschieht dies alles erneut. Das Verhalten ist jedoch für jedes einzelne System gleich. Das bedeutet, dass, wenn das Testen auf einem bestimmten System (falsch) zwei Ausgabezeilen für den ersten Durchlauf und die korrekte Ausgabe für den zweiten Durchlauf zurückgibt, die erste Ausführung des Befehls nach dem Neustart des Systems erneut zwei Zeilen ausgibt. Daher zeigen die Systeme nach jedem Neustart das gleiche Verhalten (gemäß meinen Tests). Die Dateidetails lauten wie folgt:

-rw-r--r-- 1 root root  ./usr/share/man/man8/systemd-resolved.service.8.gz
lrwxrwxrwx 1 root root  ./usr/share/man/man8/systemd-resolved.8.gz -> systemd-resolved.service.8.gz
-rwxr-xr-x 1 root root  ./lib/systemd/systemd-resolved
drwxr-xr-x 2 root root  ./lib/systemd/system/systemd-resolved.service.d
-rw-r--r-- 1 root root  ./lib/systemd/system/systemd-resolved.service

BEARBEITEN: An alle, die das Problem vorschlagen, möglicherweise im Zusammenhang mit diesem speziellen Fall für diese speziellen Dateien: " System-gelöst " ist nur ein Beispiel. Dies passiert auch bei der Suche nach anderen Keywords. Dies ist ein weiteres Beispiel, das beim ersten Durchlauf falsche Ergebnisse liefert:

root@localhost:/# find . -name "*apache*"

Ist niemand hier in der Lage, dieses Problem auf einem Debian 8 mit dem neuesten Kernel aus dem Backport-Repository zu überprüfen?

linux find

— user2808671
quelle

Können Sie versuchen, die Spuren der beiden Anrufe zu vergleichen, indem Sie beispielsweise Folgendes verwenden strace? Auf welchem Betriebssystem haben Sie das fehlerhafte Verhalten beobachtet? Was meinst du mit "liefert 0 oder zwei Ergebnisse wie oben"? Null oder zwei Ausgabezeilen oder Beendigungscode 0 + zwei Zeilen? Kommt es erneut vor, nachdem eine neue Shell gestartet oder neu gestartet wurde? Es kann relevant sein, dass der erste Aufruf nur Dateien zurückgibt, während der zweite Dateien und Verzeichnisse zurückgibt.

— 30.

@ l0b0 Wie gesagt, es passiert unter Debian mit Kernel 4.9 auf mehreren Systemen. Andere Distributionen habe ich nicht überprüft. 0 oder 2 bedeutet null oder zwei Ausgabezeilen. Dies geschieht nach jedem Neustart. Ihre letzte Aussage trifft hier nicht zu. Es wird versucht, alles zurückzugeben. Sowohl Verzeichnisse als auch Dateien.

— user2808671

@ l0b0 Nun, ich bin mir nicht sicher, wonach du suchst, aber wie du sehen kannst, habe ich den Befehl erwähnt, damit man das Problem reproduzieren kann. Dieser Befehl muss alle Pfade zurückgeben, die "systemd-resolved" enthalten, wird dies aber nicht tun. Es gibt insgesamt fünf Pfade, die diese Bedingung erfüllen, aber das Programm "find" gibt nur zwei davon oder einen oder null zurück. Hier kommt es darauf an, dass das Tool eine falsche Ausgabe ausgibt und einige korrekte Pfade überspringt. Und wie ich bereits erwähnte, habe ich dies auf anderen Systemen mit Debian überprüft, bei denen mit Kernel 4.9 ist dieses Problem aufgetreten. Dies könnte etwas Ernstes sein, das über den Benutzerbereich hinausgeht.

— user2808671

@ MarkWagner Nein. Ich habe einen Fehlerbericht an die Gnu-Findutils und die Debian-Backports-Mailingliste gesendet. Dies scheint mir sehr ernst zu sein, da die Ursache dieses Problems viele andere Dinge betreffen kann, obwohl ich nicht weiß, ob ihr mir zustimmt. "Find" ist auf jeden Fall ein sehr beliebtes Tool und die Ausgabe muss zuverlässig sein.

— user2808671

Wie wird /lib/systemdmontiert? Um was für ein Dateisystem handelt es sich? Wenn es ein separaten ist Mount - Punkt, welche Zeit war es angebracht?

— Andrew Henle

Die Standardversion von findutils, die auf Debian 8 installiert ist, ist 4.4.2 und dies ist die neueste Version auf Jessie-Repositories. Ich lade die neueste Version (4.6.0) des Quellcodes von findutils herunter und baue die Binärdateien aus dem Quellcode. Dann habe ich die gleichen Tests durchgeführt und der Befehl "find" zeigte die korrekte Ausgabe für den ersten Lauf.

Dann habe ich den Quellcode von findutils, Version 4.4.2 , aus dem gnu-Archiv heruntergeladen und kompiliert. Dasselbe Problem trat beim kompilierten Befehl find auf. Daher tritt dieses Problem bei findutils 4.6.0 nicht auf.

Aber ich weiß immer noch nicht, warum einige Benutzer mit findutils 4.4.2 (der Standardversion des auf Debian installierten Dienstprogramms) nicht die gleichen Ergebnisse erzielen und warum Debian mit dieser alten Version von findutils immer noch veröffentlicht werden sollte und möglicherweise andere Linux-Dienstprogramme und verursachen diese problematische Situation. Und das Letzte ist, dass der genaue technische Grund für das, was seltsam passiert ist, noch unbekannt ist, was nicht wünschenswert ist. Weil ich nicht sicher bin, ob in meiner Betriebssystemumgebung etwas Besorgniserregendes ist.

— user2808671
quelle