From owner-freebsd-current Sat Jul 24 18:52: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id D60B014D07 for ; Sat, 24 Jul 1999 18:51:56 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id UAA23051; Sat, 24 Jul 1999 20:51:37 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907250151.UAA23051@celery.dragondata.com> Subject: Re: Unkillable processes In-Reply-To: from Kris Kennaway at "Jul 25, 1999 11:15:24 am" To: kkenn@rebel.net.au Date: Sat, 24 Jul 1999 20:51:37 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 24 Jul 1999, Kevin Day wrote: > > > For one, do another 'ps' with the 'l' option, so you can see what it's stuck > > on. > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) > 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) > > 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi > 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) > > > The second process is a zombie, which isn't killable until the parent tells > > it to go away. (Which could very possibly be the first kvt) > > Both still present empty terminal windows on my desktop and were spawned > from the KDE panel. The second one was running a copy of pine and was in > the same state as the other initially, until I kill -KILL'ed the pine > process, at which point it changed to what it is now. > > Kris Well, since the CPU time in the active process (92724) went up since your last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the STAT), it looks like the process is just spinning, eating CPU. The tcsh listed below that is a zombie of the running kvt. If you can somehow kill that kvt, the tcsh will go away. The top kvt (1103) is also a zombie, waiting for it's parent to reap it. Whatever process 1086 is decided not to clean it up, you may want to see what it's doing. Will process 92724 die if you kill -9 it? This seems to be more of a kvt bug than a freebsd bug. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message