Команда пошуку Linux неправильно поводиться

Шукаючи сервісно вирішеної служби після недавнього розкриття вразливості, я виявив дуже дивну поведінку від команди find.

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

Команда повертає 0 або два рядки як вихід для першого запуску. Але якщо я запускаю команду вдруге, я отримую:

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

Це означає, що перший раз "знайти" насправді не знайде все. Також це відбувається лише один раз. Наступне виконання команди показує правильний вихід. Я перевірив це на деяких інших системах із встановленою Debian 8 (jessie). У тих, хто має Kernel 4.9+, ця точна проблема завжди виникає, але в системах з ядром 3.16 цього не відбувається.
Після перезавантаження системи все це повториться. Але поведінка однакова для кожної окремої системи. Це означає, що якщо тестування на певній системі повертає (помилково) два рядки виводу для першого запуску та правильний вихід для другого запуску, то перший запуск команди після перезавантаження системи знову надрукує 2 рядки. Тож системи демонструють однакову поведінку після кожного перезавантаження (згідно з моїми тестами). Деталі файлів такі:

-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: Для всіх тих, хто пропонує проблему, можливо, пов’язану з конкретним випадком для цих конкретних файлів: " вирішено системою " є лише прикладом. Це трапляється і під час пошуку інших ключових слів. Це ще один приклад, який дає неправильні результати для першого запуску:

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

Ніхто тут не в змозі перевірити цю проблему на Debian 8 із останнім ядром із сховища backport?

linux find

— user2808671
джерело

Чи можете ви спробувати порівняти сліди двох дзвінків, наприклад, використовуючи strace? На якій ОС ви спостерігали помилкову поведінку? Що ви маєте на увазі під "повертає 0 або два результати, як вище"? Нуль або два рядки виведення, або вихідний код 0 + два рядки? Чи відбувається це знову після запуску нової оболонки або перезавантаження? Може бути доречним, що перший дзвінок повертає лише файли, а другий повертає файли та каталоги.

— l0b0

@ l0b0 Як я вже говорив, це трапляється на Debian із Kernel 4.9 у багатьох системах. Я не перевіряв інших дистрибутивів. 0 або 2 означає нуль або два рядки виводу. Це відбувається після кожного перезавантаження. Ваше останнє твердження тут не поширюється. Це намагається повернути все. І каталоги, і файли.

— user2808671

@ l0b0 Ну я не впевнений, що ти шукаєш, але, як ви бачите, я згадав команду, щоб можна було відтворити проблему. Ця команда повинна повертати всі шляхи, що містять "вирішено системою", але це не буде. Усього існує п’ять шляхів, що задовольняють цій умові, але програма "знайти" повертає лише два з них або один або нуль. Тут важливо те, що інструмент дає неправильний висновок і пропускає деякі правильні шляхи. І як я вже згадував, я перевіряв це на інших системах з Debian, у тих, хто має ядро 4.9, є ця проблема. Це може бути щось серйозне за межами користувальницького простору.

— user2808671

@MarkWagner Ні. Я заповнив звіт про помилки як до списку розсилки gnu findutils, так і до списку розсилки Debian. Мені це здається дуже серйозним, оскільки джерело цієї проблеми може вплинути на багато інших речей, хоча я не знаю, чи згодні ви зі мною. У будь-якому разі "знайти" - це дуже популярний інструмент, і його вихід повинен бути надійним.

— користувач2808671

Як /lib/systemdмонтується? Що це за файлова система? Якщо це окрема точка кріплення, на який час він був встановлений?

— Ендрю Генле

Версія findutils за замовчуванням, встановлена на Debian 8, становить 4.4.2, і це остання версія в сховищах jessie. Я завантажую останню версію (4.6.0) вихідного коду findutils і будую двійкові файли з вихідного. Тоді я робив ті ж тести і команда "find" показала правильний вихід для першого запуску.

Потім я завантажив вихідний код findutils версії 4.4.2 з архіву gnu і скомпілював його. Така ж проблема трапилася і для складеної команди find. Тож ця проблема не трапляється з findutils 4.6.0.

Але я досі не знаю, чому деякі користувачі не отримують однакових результатів за допомогою findutils 4.4.2 (версія за замовчуванням утиліти, встановленої на Debian), і не знаю, чому Debian все ж слід випускати з цією старою версією findutils і, можливо, інші утиліти Linux і спричинить цю проблематичну ситуацію. І останнє, що точна технічна причина того, що дивно сталося, досі невідома, що небажано. Тому що я не впевнений, чи є щось тривожне в моєму середовищі ОС.

— user2808671
джерело