La commande Linux find se comporte mal

À la recherche d'un service résolu par le système à la suite de la récente divulgation de vulnérabilité, j'ai constaté un comportement très étrange de la part de la commande find.

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

La commande renvoie 0 ou deux lignes en sortie pour la première exécution. Mais si j'exécute la commande la deuxième fois, j'obtiens:

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

Cela signifie que la première fois, "trouver" ne trouve pas vraiment tout. De plus, cela ne se produit qu'une seule fois. L'exécution suivante de la commande affiche une sortie correcte. J'ai vérifié cela sur d'autres systèmes avec Debian 8 (jessie) installé. Sur ceux avec le noyau 4.9+, ce problème exact se produit toujours mais sur les systèmes avec le noyau 3.16, il ne se produit pas.
Après le redémarrage du système, tout cela se reproduit. Mais le comportement est le même pour chaque système individuel. Cela signifie que si le test sur un système spécifique renvoie (à tort) deux lignes de sortie pour la première exécution et une sortie correcte pour la deuxième exécution, la première exécution de la commande après le redémarrage du système imprime à nouveau 2 lignes. Les systèmes affichent donc le même comportement après chaque redémarrage (selon mes tests). Les détails des fichiers sont les suivants:

-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

EDIT: À tous ceux qui suggèrent que le problème peut être lié à ce cas spécifique pour ces fichiers spécifiques: " système-résolu " est juste comme exemple. Cela se produit également lors de la recherche d'autres mots clés. Voici un autre exemple qui donne des résultats erronés pour la première exécution:

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

Personne ici n'est en mesure de vérifier ce problème sur un Debian 8 avec le dernier noyau du référentiel backport?

linux find

— user2808671
source

Pouvez-vous essayer de comparer les traces des deux appels, par exemple en utilisant strace? Sur quel OS avez-vous observé le comportement défectueux? Qu'entendez-vous par «renvoie 0 ou deux résultats comme ci-dessus»? Zéro ou deux lignes de sortie, ou code de sortie 0 + deux lignes? Cela se reproduit-il après le démarrage d'un nouveau shell ou le redémarrage? Il peut être pertinent que le premier appel ne renvoie que des fichiers, tandis que le second renvoie des fichiers et des répertoires.

— l0b0

@ l0b0 Comme je l'ai dit, cela se produit sur Debian avec le noyau 4.9 dans plusieurs systèmes. Je n'ai pas vérifié les autres distributions. 0 ou 2 signifie zéro ou deux lignes de sortie. Cela se produit après chaque redémarrage. Votre dernière déclaration ne s'applique pas ici. Il essaie de tout retourner. Les répertoires et les fichiers.

— user2808671

@ l0b0 Eh bien, je ne suis pas sûr de ce que vous cherchez, mais comme vous pouvez le voir, j'ai mentionné la commande afin que l'on puisse reproduire le problème. Cette commande doit renvoyer tous les chemins d'accès contenant "systemd -olved", mais ce ne sera pas le cas. Il existe au total cinq chemins remplissant cette condition, mais le programme "find" n'en renvoie que deux ou un ou zéro. Ce qui importe ici, c'est que l'outil donne une sortie erronée et manque des chemins corrects. Et comme je l'ai mentionné, j'ai vérifié cela sur d'autres systèmes avec Debian, ceux avec le noyau 4.9 ont ce problème. Cela pourrait être quelque chose de sérieux au-delà de l'espace utilisateur.

— user2808671

@MarkWagner Non. J'ai rempli un rapport de bogue à la fois sur gnu findutils et sur la liste de diffusion des backports Debian. Cela me semble très grave car la source de ce problème peut affecter bien d'autres choses, même si je ne sais pas si vous êtes d'accord avec moi. Quoi qu'il en soit, "find" est un outil très populaire et sa sortie doit être fiable.

— user2808671

Comment est /lib/systemdmonté? De quel type de système de fichiers s'agit-il? S'il s'agit d'un point de montage séparé, à quelle heure a-t-il été monté?

— Andrew Henle

La version par défaut de findutils qui est installée sur Debian 8 est 4.4.2 et il s'agit de la dernière version sur les dépôts jessie. Je télécharge la dernière version (4.6.0) du code source de findutils et construit les binaires à partir des sources. Ensuite, j'ai fait les mêmes tests et la commande "find" a montré une sortie correcte pour la première exécution.

Ensuite, j'ai téléchargé le code source de findutils version 4.4.2 à partir des archives gnu et l' ai compilé. Le même problème s'est produit pour la commande find compilée. Ce problème ne se produit donc pas avec findutils 4.6.0.

Mais je ne sais toujours pas pourquoi certains utilisateurs n'obtiennent pas les mêmes résultats en utilisant findutils 4.4.2 (la version par défaut de l'utilitaire installé sur Debian), et je ne sais pas pourquoi Debian devrait toujours être publié avec cette ancienne version de findutils et éventuellement d'autres utilitaires Linux et provoquer cette situation problématique. Et la dernière chose est que la raison technique exacte de ce qui s'est étrangement produit est encore inconnue, ce qui n'est pas souhaitable. Parce que je ne sais pas s'il y a quelque chose de préoccupant dans mon environnement de système d'exploitation.

— user2808671
source