NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/admin/4885

Internet Message Format | 1992-09-07 | 3.7 KB

Xref: sparky comp.unix.admin:4885 comp.sys.hp:10077
Path: sparky!uunet!pmafire!news.dell.com!swrinde!cs.utexas.edu!rutgers!homecare!quaker!raymond
From: [e-mail] (Raymond C. Leung)
Newsgroups: comp.unix.admin,comp.sys.hp,ctp.it
Subject: Re: Unkillable processes
Message-ID: <[e-mail]>
Date: 3 Sep 92 21:27:14 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Raymond C. Leung)
Organization: Quaker Oats Company
Lines: 64

In article <[e-mail]> [e-mail] (Jason May) writes:
>
>HP 9000/847, running HPUX 8.02.
>
>From time to time, I see processes that get into such a state in
>which they cannot be killed.  By 'cannot', I mean that kill -9
>as root does not work.  I had formerly been under the impression
>that root kill -9 meant absolute instantaneous death, but apparently
>this is not the case (or there are some serious bugs).
>
>One case is when a process crashes and is attempting to write
>out a large core file across the network (eg. to a remote-mounted
>NFS partition).  Under the coredump is finished, the process won't
>die.  Another case appears to have something to do with sockets;
>the process won't die while it thinks it has active remote
>connections.
>
>If these situations are not indicative of an OS bug, has anyone
>built up a list of conditions in which a process cannot be killed?
>
>Any assistance is greatly appreciated,
>- Jason ([e-mail])

I have similar processes on my HP-9000/832 machine running HP-UX
7.02 (now upgraded to 8.00).  Users report that their terminals are
stuck and I cannot kill processes attached to their tty ports.
Rebooting the system will always work but it is a bit overkill.
Use `sysdiag` to run "pmuxdiag" is the best way for me - it clears the
mux port without affecting any other system users.

Not quite like yours, these processes are either logging in onto the
system or logging out off the system.  I can tell by looking at the
screens of these terminals or use the `ps` command.  HP Response Center
Engineers explain this scenario as that once a process is pending on
I/O, it will not receive the kill signal and that is how the system is
designed.  My HP CE blame it to the data communication cable which might
pick up some noice causing the mux port hung.

Anyway, these processes are quite annoying and they used to give me a
lot of pain because the `pmuxdiag` program on my system didn't work
until recent system upgrade and I didn't have enough spare mux ports
for users with hung terminals until I got the budget to purchase an
additional mux this Summer.  The result was considerable amount of
user complaints about system down time.  Sigh!

By the way, I have another type of unkillable processes which are
zombies left by some software applications.  Use command `ps` I can see
they are "<defunc>" and `top` shows the number of zombies on my system.
They are not attached to any terminal port so `pmuxdiag` won't help.
Fortunately, they didn't tie up any user and no one notice anything
damaging.  HP people blame the application not handling exit properly.
They said their parent process should wait() for their child processes
before termination.  However, vendor engineer of that software told me
that zombie is normal!  S o o o, I wouldn't worry about it.  :^)

I am interected in hearing other cases of unkillable processes and their
fixes.  Please send me a copy of your final conclusion/summary after
you have collected all the follow-ups.  Thanks!

--
Raymond C. Leung           UUCP:     ...!rutgers!homecare!quaker!raymond
Quaker Oats Company        Internet:     [e-mail]
96 Quaker Oats Dr.         Phone:       [phone]                |
Jackson, TN, USA 38301     Fax:         [phone]    ____________|