Unix administration - 'kill' does not reclaim the process' resources, causes memory leak

This is Interesting: Free IT Magazines  
Home > Archive > Unix administration > January 2006 > 'kill' does not reclaim the process' resources, causes memory leak





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author 'kill' does not reclaim the process' resources, causes memory leak
guybas@yahoo.com

2006-01-15, 7:49 am

This is my problem on a number of systems (including embedded):

I have to run arbitrary binary programs, killing each "from outside".
This is done for a few hundred times, under speed measurements.

It seems that each 'kill'/'killall' causes the system to leak memory.
Thus, the system slows down and speed measurements degrade.

Did somebody encounter such or similar problem? Any solution?
Is there some trick to kill a process and reclaim all its resources?

Mark Rafn

2006-01-15, 5:52 pm

<guybas@yahoo.com> wrote:
>I have to run arbitrary binary programs, killing each "from outside".
>This is done for a few hundred times, under speed measurements.


What a horrible design.

>It seems that each 'kill'/'killall' causes the system to leak memory.
>Thus, the system slows down and speed measurements degrade.


Kill itself almost certainly does not leak memory. If you have binaries that
don't clean up properly when killed, they can leak resources. In Unix, it's
fairly difficult for this to happen, though, if all the processes are really
gone.

>Did somebody encounter such or similar problem? Any solution?
>Is there some trick to kill a process and reclaim all its resources?


When a process dies, all it's resources should be released. If that's not
happening, you'll need to figure out what specific resources these specific
binaries are failing to release and why.

My first guess would be that you're looking in the wrong place. Something
else is causing the slowdown.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
Helmut Kreft

2006-01-15, 5:52 pm

On 15 Jan 2006 03:24:53 -0800, guybas@yahoo.com wrote:
>
> It seems that each 'kill'/'killall' causes the system to leak memory.
> Thus, the system slows down and speed measurements degrade.
>


Usually this happens if System V IPC resources were allocated by the
programs in question. These resources will not be cleared automatically
if a program is terminated. The command ipcs can be used to show the
active message queues/semaphores/shared memory segments.

Helmut

--
Almost everything in life is easier to get into than out of.
(Agnes' Law)
Bill Vermillion

2006-01-16, 2:50 am

In article <1137324293.779005.31240@f14g2000cwb.googlegroups.com>,
<guybas@yahoo.com> wrote:
>This is my problem on a number of systems (including embedded):
>
>I have to run arbitrary binary programs, killing each "from outside".
>This is done for a few hundred times, under speed measurements.
>
>It seems that each 'kill'/'killall' causes the system to leak memory.
>Thus, the system slows down and speed measurements degrade.
>
>Did somebody encounter such or similar problem? Any solution?
>Is there some trick to kill a process and reclaim all its resources?
>


kill -15 gives an app time to clean up after itself.
kill -9 is 'shoot on site' and can leave files open - including any
temp things that may have been used. Could that have anything to
do with your problem?

Bill
--
Bill Vermillion - bv @ wjv . com
mtfester@netMAPSONscape.net

2006-01-16, 2:50 am

Mark Rafn <dagon@dagon.net> wrote:
> <guybas@yahoo.com> wrote:
[vbcol=seagreen]
> What a horrible design.


[vbcol=seagreen]
> Kill itself almost certainly does not leak memory. If you have binaries that
> don't clean up properly when killed, they can leak resources. In Unix, it's
> fairly difficult for this to happen, though, if all the processes are really
> gone.


You haven't worked with many perle programmers.

Mike
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com