Bdtyktl

I am using archlinux and I was trying to delete core dumps file to save space on the root partition.

I stupidly ran this which I found in internet without really understanding it:

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

from what I understand so far. It will delete everything under root '/' that has the exact name 'core' except anything under '/lib'

and this is the output I got

 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

So, all of the matches are directory, and because I use rm without the -r option, it should not delete directories, which means it should delete nothing.

However, after I ran the command, most of the things in my system broke, e.g., zsh, i3. and when I reboot my PC, I got a kernel panic, bad rip value or something.

I could reinstall again since I have separate root and home partition. But I'm very curious why it broke the system.

Some relevant fragments of find specification:

-xdev

The primary shall always evaluate as true; it shall cause find not to continue descending past directories that have a different device ID […]. If any -xdev primary is specified, it shall apply to the entire expression even if the -xdev primary would not normally be evaluated.

-prune

The primary shall always evaluate as true; it shall cause find not to descend the current pathname if it is a directory. […]

[…]

The primaries can be combined using the following operators (in order of decreasing precedence):

[…]

expression [-a] expression

Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.

expression -o expression

Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.

Now your command (just to have it in sight):

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

Some conclusions and facts:

1. 
   -xdev applies to everything, even to the part after -o.


2. Because juxtaposition (or -a) precedes -o, your command is like ( expression1 ) -o ( expression2 ) (compare this answer).


3. All the output you saw came from -ls.


4. Whenever -ls worked, the first expression was true, so the second one was not evaluated (which means matches you saw were not removed).


5. 
   -path "/lib*" matches these objects:
   
   
   
   
   • directories with names matching lib* directly in /,
   
   
   • non-directories with names matching lib* directly in /,
   
   
   • 
     all objects inside directories from the first bullet point (not in your case, because of -prune).
   
   
   
   

So rm was invoked for any object that fulfills all of the following conditions:

1. It belongs to the same filesystem as / (because of -xdev).


2. It's not named core (because of how -o works).


3. It's directly in / and its name matches lib*.

I run this in my Kubuntu to print such objects:

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

and the result was

/lib

/lib64

/lib32

Each of these is a directory, sole rm (without -r) cannot remove it. I'm pretty sure in my case your original command wouldn't break the system. However if any matching object was not a directory, rm would most likely remove it.

FHS - Filesystem Hierarchy Standard says:

/lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.

I guess your /lib may have been a symlink and rm had no problem removing it. This location is for essential shared libraries and kernel modules (see FHS or this answer), no wonder you broke your system. I can't be sure there was no other lib* non-directory which was also removed; but if I'm right about /lib then maybe recreating the symlink is all you need to fix the system.

In another answer of mine the first advice is

Write 100 times "I won't run commands I don't understand as root". :)

but it looks like you have already learnt your lesson.