Il comando find di Linux si sta comportando male

Alla ricerca di un servizio risolto dal sistema a seguito della recente divulgazione di vulnerabilità, sono arrivato a vedere un comportamento molto strano dal 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

Il comando restituisce 0 o due righe come output per la prima esecuzione. Ma se eseguo il comando la seconda volta ottengo:

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

Questo significa che la prima volta, "trova" in realtà non trova tutto. Anche questo succede solo una volta. L'esecuzione del comando la prossima volta mostra l'output corretto. Ho controllato questo su alcuni altri sistemi con Debian 8 (jessie) installato. Su quelli con Kernel 4.9+ questo problema si verifica sempre, ma sui sistemi con kernel 3.16 non succede.
Dopo il riavvio del sistema, tutto ciò accade di nuovo. Ma il comportamento è lo stesso per ogni singolo sistema. Ciò significa che se il test su un sistema specifico restituisce (erroneamente) due righe di output per la prima esecuzione e l'output corretto per la seconda esecuzione, quindi la prima esecuzione del comando dopo il riavvio del sistema stampa nuovamente 2 righe. Quindi i sistemi mostrano lo stesso comportamento dopo ogni riavvio (secondo i miei test). I dettagli dei file sono i seguenti:

-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: A tutti coloro che suggeriscono che il problema potrebbe essere correlato a questo caso specifico per questi file specifici: " risolto dal sistema " è solo un esempio. Questo succede anche quando si cercano altre parole chiave. Questo è un altro esempio che fornisce risultati errati per la prima esecuzione:

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

Nessuno qui è in grado di verificare questo problema su un Debian 8 con l'ultimo kernel dal repository di backport?

linux find

— user2808671
fonte

Puoi provare a confrontare le tracce delle due chiamate, ad esempio usando strace? Su quale sistema operativo hai osservato il comportamento difettoso? Cosa intendi con "restituisce 0 o due risultati come sopra"? Zero o due righe di output o codice di uscita 0 + due righe? Succede di nuovo dopo aver avviato una nuova shell o riavviato? Potrebbe essere rilevante che la prima chiamata restituisca solo file, mentre la seconda restituisca file e directory.

— l0b0

@ l0b0 Come ho detto, succede su Debian con Kernel 4.9 in più sistemi. Non ho controllato altre distro. 0 o 2 significa zero o due linee di uscita. Succede dopo ogni riavvio. La tua ultima affermazione non si applica qui. Tenta di restituire tutto. Sia directory che file.

— user2808671

@ l0b0 Beh, non sono sicuro di quello che stai cercando, ma come puoi vedere ho menzionato il comando in modo che uno sia in grado di riprodurre il problema. Quel comando deve restituire tutti i percorsi contenenti "systemd-resolved" ma non lo farà. Esistono cinque percorsi in totale che soddisfano questa condizione, ma il programma "trova" ne restituisce solo due o uno o zero. Ciò che conta qui è che lo strumento sta dando un output sbagliato e manca alcuni percorsi corretti. E come ho già detto, ho controllato questo su altri sistemi con Debian, quelli con kernel 4.9 hanno questo problema. Questo potrebbe essere qualcosa di grave oltre lo spazio dell'utente.

— user2808671

@MarkWagner No. Ho compilato una segnalazione di bug sia alla gnu findutils che alla mailing list dei backport Debian. Questo mi sembra molto serio poiché la fonte di questo problema potrebbe influenzare molte altre cose, anche se non so se siete d'accordo con me. Comunque "find" è uno strumento molto popolare e il suo output deve essere affidabile.

— user2808671

Come viene /lib/systemdmontato? Che tipo di filesystem è? Se si tratta di un punto di montaggio separato, a che ora è stato montato?

— Andrew Henle,

La versione predefinita di findutils che è installata su Debian 8 è 4.4.2 e questa è la versione più recente sui repository jessie. Scarico l'ultima versione (4.6.0) del codice sorgente di findutils e ho creato i binari dal sorgente. Quindi ho fatto gli stessi test e il comando "trova" ha mostrato l' output corretto per la prima esecuzione.

Quindi ho scaricato il codice sorgente di findutils versione 4.4.2 dall'archivio gnu e l'ho compilato. Lo stesso problema si è verificato per il comando find compilato. Quindi questo problema non si verifica con findutils 4.6.0.

Ma ancora non so perché alcuni utenti non ottengano gli stessi risultati usando findutils 4.4.2 (la versione predefinita dell'utility installata su Debian), e non so perché Debian dovrebbe ancora essere rilasciato con questa vecchia versione di findutils e possibilmente altre utility Linux e causare questa situazione problematica. E l'ultima cosa è che l'esatta ragione tecnica di ciò che è accaduto stranamente è ancora sconosciuta, il che non è desiderabile. Perché non sono sicuro che ci sia qualcosa di preoccupante nel mio ambiente operativo.

— user2808671
fonte