Thanks for some further explanation :) at least i can now understand what's going on anyway :)
Jerry. On Wed, 12 Feb 2003 23:03:34 +0100 Benjamin Pflugmann <[EMAIL PROTECTED]> wrote: > On Wed 2003-02-12 at 14:22:41 -0700, [EMAIL PROTECTED] wrote: > [...] > > what i'm doing: > > ps ax | grep <process> > > su > > (passwd) > > kill -s <signal> <pid> > > > > using all kinds of signals.... starting with sigterm, sigkill, > > Those two is all you need. "kill -s TERM" will ask the process to > terminate (the process may refuse), "kill -s KILL" forcefully tries to > kill the process (. > > If it doesn't terminate after a KILL signal, there is no way to do > it. Usually it means that your kernel got a hickup which shouldn't > normally happen. There are cases where the kernel cannot remove a > process due to its internal state[1], but I only encountered these with > either broken kernels (i.e. an update fixed it) or with broken > hardware. > > > signals like sigrtmin+2 even were [and man kill does not say]) > > man 7 signal > > (that's mentioned in "man kill") > > > not wanting to get mucking around too much with something i didn't > > fully understand i didn't use them ALL but it seems like sigkill > > should kill just about anything :-/ > > Correct. If it does not, there is nothing a mere user (or admin) can > do about it. > > HTH, > > Benjamin. > > > [1] AFAIK, a killed process which currently happens to be somewhere in > the "kernel space", will not terminate until it jumped back to > user space. So one explanation for such an unkillable process is > that it got stuck in the kernel space somehow. > -- -- Registered Linux user # 300600 Registered Linux machine # 185855 at http://counter.li.org (¬_ //\ V_/_
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
