Killing runaway find process?

[danb35]

I wanted to see everywhere on my system that I had .iso files, so I ran "find / -name '*.iso'". It listed a bunch of files in a bunch of locations, and then stopped producing output. However, it's sucking 100% CPU (I assume that's 100% of one core), and I can't kill it:

Code:

[root@freenas2] ~# ps | grep find
50470  5  S+      0:00.00 grep find
34298  1- R+    188:00.46 find / -name *.iso
[root@freenas2] ~# kill 34298
[root@freenas2] ~# kill -9 34298
[root@freenas2] ~# ps | grep find
50535  5  S+      0:00.00 grep find
34298  1- R+    189:18.24 find / -name *.iso

I waited a couple of minutes between the kill -9 and the second ps. What's up? Google found me a number of threads talking about process in IOwait state, which would be denoted by D in the ps output, but this is in state R. I really don't want to reboot the server just because the find process won't stop...

 

[Bidule0hm]

What happens if you send it a SIGSEV signal?

 

[danb35]

I don't find a reference to SIGSEV, do you mean SIGSEGV?

Code:

[root@freenas2] ~# ps | grep find
51136  5  S+      0:00.00 grep find
34298  1- R+    199:48.08 find / -name *.iso
[root@freenas2] ~# kill -11 34298
[root@freenas2] ~# ps | grep find
51138  5  S+      0:00.00 grep find
34298  1- R+    200:06.64 find / -name *.iso

 

[Bidule0hm]

Yep, sorry, I pronounce it sig-sev so yeah...

So, the command is kill -s SIGSEGV 34298 (check the PID is the right one just to be sure).

 

[danb35]

Code:

[root@freenas2] ~# ps | grep find
51773  5  S+      0:00.00 grep find
34298  1- R+    212:17.79 find / -name *.iso
[root@freenas2] ~# kill -s SIGSEGV 34298
SIGSEGV: Unknown signal; kill -l lists signals.
[root@freenas2] ~# kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2 LWP 
[root@freenas2] ~# kill -s SEGV 34298
[root@freenas2] ~# ps | grep find
51955  5  S+      0:00.00 grep find
34298  1- R+    214:38.95 find / -name *.iso

 

[Bidule0hm]

Well, ok, try kill -s ABRT 34298

 

[danb35]

Code:

[root@freenas2] ~# ps | grep find
51955  5  S+      0:00.00 grep find
34298  1- R+    214:38.95 find / -name *.iso
[root@freenas2] ~# kill -s ABRT 34298
[root@freenas2] ~# ps | grep find
52326  5  S+      0:00.00 grep find
34298  1- R+    221:41.97 find / -name *.iso

 

[Bidule0hm]

Well, you created the ultimate unkillable process I think...

 

[danb35]

OK, so what can I do about it? Or more accurately, what can I do to avoid this in the future? Is find / just an unholy abomination that should never be used? Doesn't seem too likely. Similarly, I can't imagine that the -name flag is that dangerous. The command syntax I used is identical, as far as I can tell, to any of the half-dozen top hits on Google for "unix find all files of type". Or is this just a fluke, and I don't need to worry about it in the future?

 

[m0nkey_]

You can either wait it out or schedule a reboot if you can't kill the process. By performing 'find /' will cause it to search all mounted filesystems. You'll be better off in future running 'find ./' which searches the current directory and sub dirs.

 

[danb35]

...or I guess 'find /path/to/root'. I knew that find / would search everything, but I hadn't remembered that in Unix, everything is a file--I'm sure it doesn't need to be searching through /dev or /proc...

 

[danb35]

Even trying to reboot wouldn't fix it--it came up with a message to the effect that "some processes would not die." Had to hard power off the machine and reboot it.

 

[Bidule0hm]

I used find / commands in the past without any problems but on Linux and FreeBSD systems, not FreeNAS. There's maybe something unusual with FreeNAS. Or it can also be a one time bug thing.

Even halt couldn't shutdown it?

 

[danb35]

I'd run the shutdown from the web GUI, and it had gotten to the point of "syncing disks 0 0 0 0...". Shortly above that was a message that some processes couldn't be killed, and somewhere in the immediate vicinity was a message about switching to single user mode (I should have taken a screen shot). I didn't think about trying to ssh in and run halt.

 

[Bidule0hm]

Ok, well, I guess it's a good idea to don't run a find / command anymore :)

 

[Ericloewe]

Ok, well, I guess it's a good idea to don't run a find / command anymore :)

This, critics say, demonstrates why Unix is user-hostile.
This, supporters say, demonstrates why Unix is user-friendly.

 

[danb35]

This, supporters day, demonstrates why Unix is user-friendly.

...but very selective about who it makes friends with.