SIGKILL failures

[Michael Soulier]

Here I am, with a process failing to exit on its own, so after trying a SIGTERM, I use a SIGKILL. Now, I know that the process can't catch a SIGKILL, because it's handled by the OS, and the OS is God with respect to system resources.

To my astonishment, the process casually ignores the SIGKILL.

This should never, ever happen, and it has only happened to me on HPUX. Not Solaris, not Linux, just HPUX. I'm very curious as to why this is, and what is being done to fix it. I use HPUX 10.20 all day, so this is rather important.

Thanks people,

Mike

[Andreas Voss]

Hi,

in my knowledge one thing that could prevent a kill -9 is an open to an I/O device by the proccess for e. g. a tar command exits after I/O has been satisfied.

[Patrick Wessel]

If a process is hung awaiting the completion of I/O, it may not receive the signal and hence die.

[Michael Soulier]

Well, both of the cases where this keeps plaguing me is with regards to networking. Either a server bound to a port that refuses to die, or a client connecting to a port that refuses to.

This shouldn't happen to my knowledge. This feels like a bug.

[Michael Soulier]

On every other Unix I've been on, the OS interrupts the waiting I/O and kills it. Why not on HPUX?

[Ralf Hildebrandt]

Is the process you're trying to kill listed as ? If so, it's a zombie. Zombies cannot be killed (unless you kill their parent). If init (process 1) is the parent, all you can do is reboot.

[Michael Soulier]

No, the processes weren't zombies, and yes, they were inherited by init.

Why does that matter? I kill processes under init owned by myself in a standard account in Linux all the time. This really feels like a bug to me.

[Tim Malnati]

Each case that I've seen like this seems to be associated with memory management. Something like a runaway has gobbled up 500 Meg of memory and the system seems to keep the process alive until it's given back to the system. Not that this is correct, but it's what I've seen.