À 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?
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./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é?Réponses:
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.
la source