Unkillable processes

[David Demelier]

Hello there,

I've had a process on state "pfault" and it was just unkillable, kill
-9 had no effects and because the script was doing an infinite loop
the machine was slower and slower so the only way to fix that was a
reboot.

Why kill -9 has still no effects on some bad processes?

Regards,

--
Demelier David
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Joshua Isom]

On 5/19/2013 3:00 PM, David Demelier wrote:
> Hello there,
>
> I've had a process on state "pfault" and it was just unkillable, kill
> -9 had no effects and because the script was doing an infinite loop
> the machine was slower and slower so the only way to fix that was a
> reboot.
>
> Why kill -9 has still no effects on some bad processes?
>
> Regards,
>
> --
> Demelier David

A process can be unkillable if it's holding a lock, like reading from
disk. Eventually, the lock will release and it should die. You can use
limits to change how much CPU and memory a process can use. My guess is
what happened is it started using a lot of memory, but you ran out and
have a lot of swap. It was trying to run while using your hard drive
instead of ram. With limits, you should be able to prevent it from
using swap which could help, and cap the amount of ram and cpu.

[David Demelier]

2013/5/19 Joshua Isom <jri...@gmail.com>:

> On 5/19/2013 3:00 PM, David Demelier wrote:
>>
>> Hello there,
>>
>> I've had a process on state "pfault" and it was just unkillable, kill
>> -9 had no effects and because the script was doing an infinite loop
>> the machine was slower and slower so the only way to fix that was a
>> reboot.
>>
>> Why kill -9 has still no effects on some bad processes?
>>
>> Regards,
>>
>> --
>> Demelier David
>
>
> A process can be unkillable if it's holding a lock, like reading from disk.
> Eventually, the lock will release and it should die. You can use limits to
> change how much CPU and memory a process can use. My guess is what happened
> is it started using a lot of memory, but you ran out and have a lot of swap.
> It was trying to run while using your hard drive instead of ram. With
> limits, you should be able to prevent it from using swap which could help,
> and cap the amount of ram and cpu.

Hello, thank you for that precise explanation, I will add limits into
the new rctl.conf, however I don't know how many amount of ram I
should allow, in fact I have absolutely no idea how much of ram an
usual program eats, is 50Mo enough for user applications ?

Regards,

--
Demelier David

[Joshua Isom]

On 5/22/2013 1:47 AM, David Demelier wrote:
> 2013/5/19 Joshua Isom <jri...@gmail.com>:

>>
>> A process can be unkillable if it's holding a lock, like reading from disk.
>> Eventually, the lock will release and it should die. You can use limits to
>> change how much CPU and memory a process can use. My guess is what happened
>> is it started using a lot of memory, but you ran out and have a lot of swap.
>> It was trying to run while using your hard drive instead of ram. With
>> limits, you should be able to prevent it from using swap which could help,
>> and cap the amount of ram and cpu.
>
> Hello, thank you for that precise explanation, I will add limits into
> the new rctl.conf, however I don't know how many amount of ram I
> should allow, in fact I have absolutely no idea how much of ram an
> usual program eats, is 50Mo enough for user applications ?
>
> Regards,
>
> --
> Demelier David
>

A "usual program" on FreeBSD could be anything. Right now my cron's
using about 1.5 megs, while my ZFS ARC is about 20 gigabytes. Firefox
can use a gigabyte somewhat easily. What I'd recommend is using limits
to disable swap for it, and temporarily set the maximum memory to around
2/3's your currently free memory. If it's behaving properly that should
be safe. While it's running properly, get an idea of how much it wants
and set the ram to 1.5 times that number. If it's misbehaving, your
system should still run properly and maybe you can diagnose the problem.