Почему эта сложная для понимания команда 'find' сломала мою систему?

Question

Я использую archlinux, и я пытался удалить файл дампов ядра, чтобы сэкономить место в корневом разделе.

Я тупо запустил то, что нашел в интернете, не понимая этого:

sudo find / -xdev -name core -ls -o -path "/lib*" -prune -exec rm {} \;

из того, что я понимаю до сих пор. Он удалит все под root '/', который имеет точное имя 'core', кроме всего, что находится под '/lib'

и это вывод, который я получил

 399883 4 drwxr-xr-x 2 root root 4096 Sep 21 18:33 /usr/share/lightdm-webkit/themes/litarvan/packages/$sdk/lib/core
401640 4 drwxr-xr-x 11 root root 4096 Sep 21 18:33 /usr/share/lightdm-webkit/themes/litarvan/packages/angular2/src/core
992335 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/log/core
999740 4 drwxr-xr-x 7 root root 4096 Dec 5 14:36 /usr/include/boost/spirit/home/classic/core
999834 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/spirit/home/x3/core
999557 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/phoenix/core
992045 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/hana/fwd/core
992030 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/hana/core
991963 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/geometry/multi/core
991928 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/geometry/core
991626 4 drwxr-xr-x 4 root root 4096 Dec 5 14:36 /usr/include/boost/beast/experimental/core
991622 4 drwxr-xr-x 4 root root 4096 Dec 5 14:36 /usr/include/boost/beast/core
991735 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/contract/detail/inlined/core
991731 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/contract/core
1000174 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/xpressive/detail/core
991744 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/core
1062959 4 drwxr-xr-x 3 root root 4096 Dec 6 01:31 /usr/lib/python3.7/site-packages/ranger/core
1088768 4 drwxr-xr-x 3 root root 4096 Oct 22 21:00 /usr/lib/python3.7/site-packages/core
450582 4 drwxr-xr-x 6 root root 4096 Dec 6 01:07 /usr/lib/ruby/gems/2.5.0/gems/rspec-core-3.8.0/lib/rspec/core
1008621 4 drwxr-xr-x 4 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/sound/core
1008442 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/usb/core
1007844 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/infiniband/core
1008479 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/video/fbdev/core
1007786 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/gpu/drm/tinydrm/core
1008033 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/mmc/core
1008005 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/memstick/core
1008133 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/net/ethernet/mellanox/mlx5/core
1008569 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/net/core
415080 4 drwxr-xr-x 4 root root 4096 Sep 9 09:36 /usr/lib/python2.7/site-packages/wx-3.0-gtk3/wx/lib/pubsub/core
1074158 4 drwxr-xr-x 2 root root 4096 Sep 7 03:10 /usr/lib/python2.7/site-packages/radialnet/core

Итак, все совпадения являются каталогами, и поскольку я использую rm без параметра -r , он не должен удалять каталоги, что означает, что он не должен ничего удалять.

Однако после того, как я запустил команду, большинство вещей в моей системе сломалось, например, zsh, i3. и когда я перезагружаю свой компьютер, у меня возникает паника в ядре, плохое значение копирования или что-то в этом роде.

Я мог бы переустановить снова, так как у меня есть отдельный корневой и домашний раздел. Но мне очень любопытно, почему это сломало систему.

Answer 1

Некоторые соответствующие фрагменты спецификации find:

-xdev
Первичное всегда должно оцениваться как истинное; это должно привести к тому, что find не продолжит убывать прошлые каталоги с другим идентификатором устройства […]. Если указан какой- либо первичный -xdev , он должен применяться ко всему выражению, даже если первичный -xdev обычно не оценивается.

-prune
Первичное всегда должно оцениваться как истинное; это должно привести к тому, что find не опустит текущее имя пути, если это каталог. [...]

[...]

Первичные цвета могут быть объединены с использованием следующих операторов (в порядке уменьшения приоритета):

[...]

expression [-a] expression
Соединение праймериз; Оператор AND подразумевается сопоставлением двух основных цветов или становится явным с помощью необязательного оператора -a . Второе выражение не должно оцениваться, если первое выражение ложно.

expression -o expression
Чередование праймериз; оператор ИЛИ. Второе выражение не должно оцениваться, если первое выражение истинно.

Теперь ваша команда (просто чтобы это было видно):

find / -xdev -name core -ls -o -path "/lib*" -prune -exec rm {} \;

Некоторые выводы и факты:

1. -xdev относится ко всему, даже к части после -o .
2. Поскольку сопоставление (или -a) предшествует -o , ваша команда похожа на ( expression1 ) -o ( expression2 ) (сравните этот ответ).
3. Все результаты, которые вы видели, были получены из -ls .
4. Всякий раз, когда работал -ls , первое выражение было истинным, поэтому второе не оценивалось (что означает, что совпадения, которые вы видели, не были удалены)
5. -path "/lib*" соответствует этим объектам:
   • каталоги с именами, соответствующими lib* непосредственно в / ,
   • не-каталоги с именами, совпадающими с lib* непосредственно в / ,
   • все объекты внутри каталогов с первой точки маркера (не в вашем случае, из-за -prune).

Таким образом, rm был вызван для любого объекта, который удовлетворяет всем следующим условиям:

1. Он принадлежит к той же файловой системе, что и / (из-за -xdev).
2. Он не называется core (из-за того, как работает -o).
3. Он находится прямо в / и его имя соответствует lib* .

Я запускаю это в моем Kubuntu для печати таких объектов:

find / -xdev -name core -o -path "/lib*" -prune -print

и результат был

/lib
/lib64
/lib32

Каждый из них является каталогом, единственный rm (без -r) не может удалить его. Я почти уверен, что в моем случае ваша оригинальная команда не сломает систему. Однако, если какой-либо соответствующий объект не является каталогом, rm , скорее всего, удалит его.

FHS - Стандарт Иерархии Файловой Системы говорит:

/lib32 и /lib64 могут быть каталогами библиотеки, а /lib символическая ссылка на один из них.

Я полагаю, что ваша /lib была символической ссылкой, и rm без проблем удалил ее. Это расположение для основных разделяемых библиотек и модулей ядра (см. FHS или этот ответ), неудивительно, что вы сломали свою систему. Я не могу быть уверен, что не было никакой другой директории lib* которая также была удалена; но если я прав насчет /lib то, возможно, воссоздание символической ссылки - это все, что вам нужно для исправления системы.

В другом моем ответе первый совет

Напишите 100 раз:«Я не буду запускать команды, которые я не понимаю как root». :)

но похоже, что ты уже усвоил урок.