El comando find de Linux se está portando mal

Al buscar un servicio resuelto por el sistema después de la reciente divulgación de vulnerabilidad, llegué a ver un comportamiento muy extraño del comando find.

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

El comando devuelve 0 o dos líneas como salida para la primera ejecución. Pero si ejecuto el comando la segunda vez que obtengo:

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

Esto significa que la primera vez, "buscar" en realidad no encuentra todo. Además, esto solo ocurre una vez. La ejecución del comando la próxima vez muestra la salida correcta. Lo comprobé en algunos otros sistemas con Debian 8 (jessie) instalado. En aquellos con Kernel 4.9+, este problema exacto siempre ocurre, pero en sistemas con kernel 3.16 no sucede.
Después de reiniciar el sistema, todo esto vuelve a suceder. Pero el comportamiento es el mismo para cada sistema individual. Eso significa que si la prueba en un sistema específico devuelve (incorrectamente) dos líneas de salida para la primera ejecución y la salida correcta para la segunda ejecución, la primera ejecución del comando después de reiniciar el sistema nuevamente imprime 2 líneas. Entonces, los sistemas muestran el mismo comportamiento después de cada reinicio (de acuerdo con mis pruebas). Los detalles de los archivos son los siguientes:

-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

EDITAR: Para todos aquellos que sugieren que el problema puede estar relacionado con este caso específico para estos archivos específicos: " resuelto por el sistema " es solo un ejemplo. Esto sucede al buscar otras palabras clave también. Este es otro ejemplo que da resultados incorrectos para la primera ejecución:

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

¿Nadie aquí puede verificar este problema en un Debian 8 con el último núcleo del repositorio de backport?

linux find

— usuario2808671
fuente

¿Puedes intentar comparar rastros de las dos llamadas, por ejemplo usando strace? ¿En qué sistema operativo observó el comportamiento defectuoso? ¿Qué quiere decir con "devuelve 0 o dos resultados como el anterior"? ¿Cero o dos líneas de salida, o código de salida 0 + dos líneas? ¿Sucede nuevamente después de iniciar un nuevo shell o reiniciar? Puede ser relevante que la primera llamada solo devuelva archivos, mientras que la segunda devuelve archivos y directorios.

— l0b0

@ l0b0 Como dije, sucede en Debian con Kernel 4.9 en múltiples sistemas. No revisé otras distribuciones. 0 o 2 significa cero o dos líneas de salida. Sucede después de cada reinicio. Su última declaración no se aplica aquí. Intenta devolver todo. Tanto directorios como archivos.

— user2808671

@ l0b0 Bueno, no estoy seguro de lo que está buscando, pero como puede ver, he mencionado el comando para poder reproducir el problema. Ese comando debe devolver todas las rutas que contengan "systemd-resolve" pero no lo hará. Hay cinco rutas en total que satisfacen esta condición, pero el programa "buscar" solo devuelve dos de ellas, una o cero. Lo que importa aquí es que la herramienta está dando resultados incorrectos y pierde algunas rutas correctas. Y como mencioné, verifiqué esto en otros sistemas con Debian, aquellos con kernel 4.9 tienen este problema. Esto podría ser algo serio más allá del espacio del usuario.

— user2808671

@ MarkWagner No. Llené un informe de error tanto para gnu findutils como para la lista de correo de Debian. Esto me parece muy grave ya que la fuente de este problema puede afectar muchas otras cosas, aunque no sé si ustedes están de acuerdo conmigo. De todos modos "encontrar" es una herramienta muy popular y su salida debe ser confiable.

— user2808671

¿Cómo se /lib/systemdmonta? ¿Qué tipo de sistema de archivos es? Si es un punto de montaje separado, ¿a qué hora se montó?

— Andrew Henle

La versión predeterminada de findutils que está instalada en Debian 8 es 4.4.2 y esta es la versión más reciente en los repositorios jessie. Descargué la última versión (4.6.0) del código fuente de findutils y construí los archivos binarios desde la fuente. Luego hice las mismas pruebas y el comando "buscar" mostró la salida correcta para la primera ejecución.

Luego descargué el código fuente de findutils versión 4.4.2 del archivo gnu y lo compilé. El mismo problema ocurrió para el comando compilado find. Entonces, este problema no está sucediendo con findutils 4.6.0.

Pero todavía no sé por qué algunos usuarios no obtienen los mismos resultados con findutils 4.4.2 (la versión predeterminada de la utilidad instalada en Debian), y no sé por qué Debian aún debería lanzarse con esta versión antigua de findutils y posiblemente otras utilidades de Linux y causan esta situación problemática. Y lo último es que aún se desconoce la razón técnica exacta de lo que sucedió extrañamente, lo que no es deseable. Porque no estoy seguro de si hay algo preocupante en mi entorno de sistema operativo.

— usuario2808671
fuente