Have you tried killall <
http://en.wikipedia.org/wiki/Killall>?
-Shane
On 7/5/07, Shawn Badger <
badger.shawn@gmail.com> wrote:
>
> I don't see any child processes under the rpm's PID and no parent
> processes either. I even killed the shell process that I used to launch the
> rpm command from. I left it running all day yesterday in hopes that it
> would be cleaned up, but no such luck.
>
> On 7/5/07, Dan Lund <situationalawareness@gmail.com> wrote:
> >
> > The problem with rpm is that you can leave that process there for a
> > week and it won't reap itself.
> > Its a very odd scenario.
> >
> >
> >
> > On 7/5/07, Darrin Chandler < dwchandler@stilyagin.com> wrote:
> > > On Thu, Jul 05, 2007 at 08:09:54AM -0700, Dan Lund wrote:
> > > > On 7/5/07, Matt Graham <danceswithcrows@usa.net> wrote:
> > > > > On Thursday 05 July 2007 10:27, after a long battle with
> > technology,
> > > > > Shawn Badger wrote:
> > > > > > how do you kill something when kill -9 doesn't work?
> > > > >
> > > > > You don't, generally. SIGKILL will kill anything that isn't
> > waiting on
> > > > > a syscall to return. If something is waiting on a syscall to
> > return
> > > > > for more than about 0.5 seconds, you've got a hardware problem, a
> > > > > kernel bug, or a dead NFS server. (There's currently a live
> > thread on
> > > > > comp.os.linux.misc about SIGKILL, oddly enough.)
> > > > >
> > > >
> > > > No, it does happen with the rpm application rarely, and almost
> > always
> > > > its so honked up that a SIGKILL won't terminate it.
> > > > I've seen it once or twice myself, and it almost always has to do
> > with
> > > > a corrupted rpm database.
> > > > As far as killing it, that's something that I'd love to figure
> > out....
> > > > Though I've only ran into this on new installs when I'm applying
> > > > patches. I've always just figured itd take less man hours to
> > > > re-install.
> > >
> > > No, he's got it right. There's nothing that -9 won't kill unless the
> > > kernel looks at it and says "oh, I'm not killing that!" The most
> > common
> > > form of this is a zombie process, which is a dead process that the
> > > kernel keeps around waiting for the zombie's child to finish. Let the
> > > child exit on it's own, or kill the child process, and then kernel
> > will
> > > (sooner or later) clean up the zombie itself.
> > >
> > > --
> > > Darrin Chandler | Phoenix BSD User Group | MetaBUG
> > > dwchandler@stilyagin.com | http://phxbug.org/ |
> > http://metabug.org/
> > > http://www.stilyagin.com/ | Daemons in the Desert | Global BUG
> > > Federation
> > > ---------------------------------------------------
> > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> > > To subscribe, unsubscribe, or to change your mail settings:
> > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> > >
> >
> >
> > --
> > "Courage is like love; it must have hope to nourish it."
> > -Napoleon Bonaparte
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)