Unable to kill process "ls"

Hi Forum

I have an issue trying to kill a long running process:
My FreeBSD is FreeBSD 7.2-RELEASE-p6 an old FreeNAS system.

Top shows two ls processes:

Code:
last pid:  8735;  load averages:  2.00,  2.00,  2.00                                                                                                  up 2+12:44:51  09:20:39
28 processes:  3 running, 25 sleeping
CPU:  0.0% user,  0.0% nice, 50.2% system,  0.2% interrupt, 49.6% idle
Mem: 13M Active, 265M Inact, 123M Wired, 48K Cache, 100M Buf, 486M Free
Swap:

  PID USERNAME      THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
 3824 root            1  -8    0  3436K  1256K CPU1   1  23.9H 100.00% ls
 3801 root            1  -8    0  3436K  1264K CPU3   3  23.4H 100.00% ls

Which are all in the "R" State.
Code:
ps -U root |grep ls
 3801  ??  R    1404:20.20 ls -la /mnt/raid/...
 3807  ??  D      0:00.01 ls -la /mnt/raid/...
 3824  ??  R    1432:47.22 ls -la /mnt/raid/..

The issue appeared when tried to acess my geom 5 RAID device which in in the "rebuilding" state.

Is there maybe an other way? like unmounting the raid, or a different kill command?
My SCP tool was unable to list the director and aborted. The remainders where these two ls commands that currently use 50% CPU (i.e. two cores)

I have tried all tricks in the book (I know of) with kill -9, kill 11, kill -15

But the processes are still there.

A reboot would do the trick but as the raid is rebuilding I do not necessarily want to spoil this. After two days it is at 16% and a reboot will likely reduce this to 0%
 
When it comes to the FreeBSD part of the thing - you can't kill a process that is waiting for something (that D state of process, PID 3807) because that signal is not yet delivered (process won't get it till the condition it's waiting for gets triggered). Your best option here is to wait for rebuilt to finish.

I have 0 experience with FreeNAS so I don't know how it offers to build an array. But journaling could speed up these rebuilds. It's been more over a decade since I used geom device, so I don't recall the details (once I switched to ZFS I didn't want to go back).
 
Hi Martin,
The process in the 3807 in D State is not my concern. The both processes PID: 3801 & 3824 are.

I know that the FreeNAS etc. systems are not supported and FreeBSD 7.2 is end of life. But does it hurt to look if someone has a hint? It is most likely not a FreeNAS issue to kill the processes. I can not upgrade to anything newer unless this is fixed.

EDIT: I was able to STOP one of the processes with: probably withc kill -s STOP 3801 (I have tried quite a few...). So this is good enough for now.
 

SirDice

Administrator
Staff member
Administrator
Moderator
The process in the 3807 in D State is not my concern. The both processes PID: 3801 & 3824 are.
It is a problem. One process will lock up disk access so any other process is going to have to wait too. Just that one process will cause a cascading effect locking all disk access and eventually all processes are affected.

Not being able to kill a process is a symptom, not a cause.
 
But does it hurt to look if someone has a hint?
It doesn't - that's why I gave it even though it's FreeNAS and out of support OS :). You should wait and then maybe if you stick to geom providers do look up the gjournal(8).

To see what is process doing you could also connect with truss(1): truss -p $PID where $PID is the pid of the program to trace.
 
Top