Thanks also to:
Annie Austin <Austin.Annie@mtvne.com>
David L. Markowitz <David.Markowitz@litronic.com>
Gary Mulder <gary@cgen.com>
Richard Quinn <rquinn@sight-n-sound.com>
Mike Salehi <mike.salehi@kodak.com>
These more recent suggestions were concise and varied so
I'll include them all.
Ms. Austin also suggested killing the PPID. I'll try that
next time, if there is a next time and it is possible.
Mr. Markowitz though my guess (in original summary below)
was very good.
(It might be possible to use lsof, per Mr. Quinn, or fuser
to see if my guess is correct next time I run into this
issue. If not, maybe I'll at least find out what the cause
of the persistent process is.)
Mr. Mulder wrote:
I have limited knowledge of exactly what happens, but if a process in running
in kernel space it may either choose to ignore signals, or the kernel may
prevent it recieving signals until it exits kernel space. I've had some similar
experiences with progams that directly interface to device drivers, I couldn't
kill them until the driver request they made had completed.
Mr. Quinn wrote:
I've ran into the same thing myself.
A lot of times when a proc won't die when you kill -9 it, it's because it is
holding a key file open.
I would run an lsof against the pid in question to see what it is holding open.
Perhaps it is an nfs mounted
file ( a lot of times that was the case for me). In which case I'd try to
bounce the nfs daemons and then
kill the pid in question. But I'd always do an lsof first just to see what is
being held open.
Mr. Salehi wrote:
Try other signals too, try to kill its parent, it may also exit once it
cannot get any more memory, but kill is the only way.
Plan for a reboot.
(I did that. Specifically, I tried SIGINT (2) and SIGHUP (1)
before I tried SIGKILL (9). Unfortunately, no success. I tried
no others.)
>X-Unix-From: bking@mail.yipes.com Wed Nov 15 02:48:58 2000
>Delivered-To: bking@mail.nanospace.com
>Delivered-To: yipes-yipes-com-bking@yipes.com
>Date: Tue, 14 Nov 2000 18:48:54 -0800 (PST)
>From: Brooke King <bking@mail.yipes.com>
>Subject: SUMMARY: process runs but does not die
>To: sun-managers@sunmanagers.ececs.uc.edu
>MIME-Version: 1.0
>Content-MD5: hl7/SK3NC+K4LRgKbaAoJA==
>
>Thanks to:
>
>Jonathan Loh, jloh@brodia.com
>Annette Lee, LeeE@fnmoc.navy.mil
>Ed Crotty, ecrotty@vantage.com
>Kent Perrier, Kent.Perrier@Oneco.net
>Eric S. Bryant, esbryan@biw.com
>
>There was a lot of good humor.
>
>The common suggestion was to kill the parent process.
>Unfortunately, that was init, you know, PID 1.
>
>Ms. Lee made an intriguing addition to the discussion: "I read
>some obscure document once about locating the PID down in
>/proc and doing an rm -f on the PID, but SUN Support
>practically had a stroke when I asked 'em about it."
>
>Sadly for knowledge's sake and happily for the server's sake,
>the process seems to have terminated itself or somehow paid
>attention to my signals on a delayed basis. A core file was
>created so my belief is that the process was already dumping
>core when I tried to signal it. The process was so huge (the
>core file is more than 1.5GB) that it took substantial time
>and some noticeable CPU to write the core file. That's my
>guess, anyway.
>
>Original question:
>
>>X-Unix-From: bking@mail.yipes.com Wed Nov 15 01:23:08 2000
>>Delivered-To: bking@mail.nanospace.com
>>Delivered-To: yipes-yipes-com-bking@yipes.com
>>Date: Tue, 14 Nov 2000 17:23:06 -0800 (PST)
>>From: Brooke King <bking@mail.yipes.com>
>>Subject: process runs but does not die
>>To: sun-managers@sunmanagers.ececs.uc.edu
>>MIME-Version: 1.0
>>Content-MD5: c3E5HhK8Gu52R6w4kaiY8g==
>>
>>One of my users has started a memory hungry process that still
>>accumulates CPU time but does not die, even when signaled with
>>kill -9.
>>
>>Any idea how to kill it without rebooting the box?
>>
>>--
>>
>>Brooke King direct: +1.415.901.2207 fax: +1.501.423.9037
>>brooke.king@yipes.com
>>Yipes Communications
>>114 Sansome Street, Ninth Floor, San Francisco, CA 94104 USA
>>
>
>--
>
>Brooke King direct: +1.415.901.2207 fax: +1.501.423.9037
>brooke.king@yipes.com
>Yipes Communications
>114 Sansome Street, Ninth Floor, San Francisco, CA 94104 USA
>
--Brooke King direct: +1.415.901.2207 fax: +1.501.423.9037 brooke.king@yipes.com Yipes Communications 114 Sansome Street, Ninth Floor, San Francisco, CA 94104 USA
S U BEFORE POSTING please READ the FAQ located at N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq . and the list POLICY statement located at M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy A To submit questions/summaries to this list send your email message to: N sun-managers@sunmanagers.ececs.uc.edu A To unsubscribe from this list please send an email message to: G majordomo@sunmanagers.ececs.uc.edu E and in the BODY type: R unsubscribe sun-managers S Or . unsubscribe sun-managers original@subscription.address L To view an archive of this list please visit: I http://www.latech.edu/sunman.html S T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:23 CDT