# Unable to kill process "ls"



## tulamidan (Aug 12, 2019)

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:


```
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.

```
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%


----------



## SirDice (Aug 12, 2019)

You should read the rules.

FreeBSD 7.2 has been end-of-life since June 2010 (that's almost 10 years!) and is not supported any more. FreeNAS is not supported at all here.

Topics about unsupported FreeBSD versions
PC-BSD, FreeNAS, XigmaNAS, and all other FreeBSD Derivatives









						Unsupported FreeBSD Releases
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## _martin (Aug 12, 2019)

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).


----------



## tulamidan (Aug 12, 2019)

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 (Aug 12, 2019)

tulamidan said:


> 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_.


----------



## _martin (Aug 12, 2019)

tulamidan said:


> 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.


----------



## Bobi B. (Aug 12, 2019)

truss(1) would not help if process is locked in the kernel, but procstat(1) might give you a tip: `procstat -kk $PID`.


----------

