Destroying processes

Destroying processes

[Justin Hibbits]

Hey 00ber-geeks,

I'm not subscribed (yet....still too lazy to subscribe ;P ), but I have a
question and/or suggestion.

Is there a system call that would destroy a process?  Sometimes I end up with
zombie processes, other times I end up with a process attaching to a device
driver, and hanging, so I want to be able to completely destroy the
process...image, file handle, driver hooks, everything.  If there isn't one,
and noone wants to do it, I'll gladly do it (may take a few weeks tho).  I just
don't wanna do what someone else has already done.

Thanks,

Justin Hibbits

-- 
Registered Linux user 260206

"One World, One Web, One Program"
	- Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer"
	- Adolf Hitler

I'm not paranoid.  They really *are* out to get me!

Re: Destroying processes

[Robert Love]

On Wed, 2002-12-11 at 14:01, Justin Hibbits wrote:

> Is there a system call that would destroy a process?  Sometimes I end up with
> zombie processes, other times I end up with a process attaching to a device
> driver, and hanging, so I want to be able to completely destroy the
> process...image, file handle, driver hooks, everything.  If there isn't one,
> and noone wants to do it, I'll gladly do it (may take a few weeks tho).  I just
> don't wanna do what someone else has already done.

Cases where kill -9 fail to work are cases where it is supposed to fail.

You cannot kill zombies, that would break POSIX compliance when the
parent's called wait.  If you task's parents are not properly calling
wait() that is an application bug.  If the parent exits, the children
should be reparented to init and init will reap them via wait().

You also cannot kill tasks that are sleeping (D in ps/top).  They may
hold a semaphore or otherwise be in the middle of a critical section. 
Killing them would be bad bad bad.

	Robert Love

Re: Destroying processes

[Justin Hibbits]

On Wed, Dec 11, 2002 at 02:21:55PM -0500, Robert Love wrote:
> Cases where kill -9 fail to work are cases where it is supposed to fail.
> 
> You cannot kill zombies, that would break POSIX compliance when the
> parent's called wait.  If you task's parents are not properly calling
> wait() that is an application bug.  If the parent exits, the children
> should be reparented to init and init will reap them via wait().
> 
> You also cannot kill tasks that are sleeping (D in ps/top).  They may
> hold a semaphore or otherwise be in the middle of a critical section. 
> Killing them would be bad bad bad.
> 
> 	Robert Love

Ok, thanks for clearing that up.  My reasoning for wanting this is because a CD
I had mounted with cdfs was screwed up in the mount (file sizes were
misreported, etc), and I couldn't umount it, even tho I could eject it with
cdrecord -eject.  The umount process then went to sleep (with teh 'D' showing
in ps/top), and I couldn't use that drive again until after a reboot.  That's
when I got the idea that I should be able to destroy the process completely,
annihilating everything with it, destroying any connections it has with the
kernel, etc.  I guess it's a bad idea, given your statement :P

Anyway, thanks for the reply,

Justin

-- 
Registered Linux user 260206

"One World, One Web, One Program"
	- Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer"
	- Adolf Hitler

I'm not paranoid.  They really *are* out to get me!

Re: Destroying processes

[Robert Love]

On Wed, 2002-12-11 at 14:30, Justin Hibbits wrote:

> Ok, thanks for clearing that up.  My reasoning for wanting this is because a CD
> I had mounted with cdfs was screwed up in the mount (file sizes were
> misreported, etc), and I couldn't umount it, even tho I could eject it with
> cdrecord -eject.  The umount process then went to sleep (with teh 'D' showing
> in ps/top), and I couldn't use that drive again until after a reboot.  That's
> when I got the idea that I should be able to destroy the process completely,
> annihilating everything with it, destroying any connections it has with the
> kernel, etc.  I guess it's a bad idea, given your statement :P

Yah you do not want to be able to kill that hung task.

At the same time, this is a cdfs so we DO want to fix that. I.e., while
it is unsafe and not clean to kill a sleeping task, you should never
need to.  So this bug should be fixed.

	Robert Love

Re: Destroying processes

[Richard B. Johnson]

On Wed, 11 Dec 2002, Justin Hibbits wrote:

> Hey 00ber-geeks,
> 
> I'm not subscribed (yet....still too lazy to subscribe ;P ), but I have a
> question and/or suggestion.
> 
> Is there a system call that would destroy a process?  Sometimes I end up with
> zombie processes, other times I end up with a process attaching to a device
> driver, and hanging, so I want to be able to completely destroy the
> process...image, file handle, driver hooks, everything.  If there isn't one,
> and noone wants to do it, I'll gladly do it (may take a few weeks tho).  I just
> don't wanna do what someone else has already done.
> 
> Thanks,
> 
> Justin Hibbits

A process gets destroyed when it calls exit() (actually sys_exit()
in the kernel). However, in Unix/Linux machines, it will wait until
somebody executes wait(), wait3(), or similar procedures to get the
return status of the task. A task that is waiting to be "reaped"
in this manner is called a zombie task and it shows up in `ps` with
a state of "Z".

If you have zombie tasks, they are caused by incorrectly written
programs that fork() child tasks without either setting up a signal
handler for SIGCHLD or, at least executing a wait() to get the
return status. The zombie must be reaped by its parent. This means
that if the parent task didn't do this, or no longer exists, the
zombie will remain until all possible parents (parents of parents)
exit. In that case, the parent of a parents, "init" will (should)
reap the status of the child and throw it away.

So, if you run programs that create zombies, the zombies should
go away as soon as you log-off. If you are running from X-Windows,
you may need to get out of X completely. If the zombies don't go away,
you have a broken `init` which should be replaced. You need to add
the proper code to programs that execute fork(), so that they don't
generate zombies.

Programs that exit always end up closing all file-handles. The kernel
does this automatically. Therefore, there should never be any hung
processes attaching a device driver unless there are errors inside
the device driver. In that case, you need to fix the device driver.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.