An httpd process won't die with kill -9

[T S_1]

I have a modified stronghold server that would hang once in a while and won't die even with kill -9. I suspect that port 443 is hanging for some reason. Rebooting the machine seems to solve the problem.

Is there a way to kill the process without rebooting?

Thanks

[Ron Cornwell]

What version of stronghold are you using ? the most recent patch for v2 was recently released.

[Vincenzo Restuccia]

Try kill -HUP pid.

[Kenneth Platz]

E. Farah,

"kill -9" is nicknamed "Kill with Extreme Prejudice" for ample reason -- it is a means to kill a process that is generally unavoidable. However, there are several situations where even a kill -9 will not terminate an unwanted process. For example, if the process is hung during a system call or if the process has entered a "zombie" state, it cannot generally be killed except by a reboot.

A "zombie" process can *sometimes* find its way to a peaceful death if and when its PARENT process; however, if this parent process is 1 ("init"), then the only way to terminate the process is to reboot the system.

[T S_1]

Thank you all for your prompt response.

The Stronghold version is 3.0.

I tried killing the process with kill -HUP PID, first but that did not work, that's why I issued the kill -9 PID.

I looked for zombies or defunct processes, but did find any.

The parent process is 1.

The problem is resolved now that the machine has been rebooted, but I like to know in the future if there is another solution.

Thanks,

[Mark Vollmers]

Is the parent process 1 right when you start it up? Normally, the parent switches from what it is normally to 1 when it becomes a zombie (the parent loses the child, so init becomes the parent by default). assuming that the parent is not 1, maybe you can keep an eye on the parent process to see if that is terminating, causing the server to hang.

You might be able just to restart the server process when it hangs; sometimes the zombie processes just hang around but don't use any resources or prevent you from restarting it. You could give that a try.

[T S_1]

Mark,

You are right, when the process starts, it doesn not start with a 1 parent process, it starts with a process owned by root and all the subsequent children are owned by nobody.

When the process hangs, I try to restart it with kill PID, but that only kills all the children and not the parent. If I try to restart it, it does not complain that the process already exist. So after that, I tried kill -HUP or -9 or -17, but none of them works.

I know from an earlier message posted to the Forum, there was a reference to process that might be waiting for another io process and my feeling is that this is a socket that won't get released, or may be some shared memory issue. Could someone advise me along these lines and if there is anything else to watch for?

Thanks

[Kevin Wright]

do a ps -elf, if the PRI is between 128 and 153, you cannot kill the process, as the kernel thinks this process MUST be running for the system to operate.

[Bill Hassell]

Killing a program is an indirect process. The operating system stores the kill signal in the process table which will be checked when the program starts running again. However, any process that is waiting for an I/O operation to complete will not run. If the I/O never completes (ie, there is no driver timeout for problems) then the process never resumes and cannot see the kill signal.

Serial communication (ie, RS-232) is one of the common types of programs that programmers forget to add timeouts--they will hang forever if I/O never completes. Less often (but still possible), LAN communication can get messed up and I/O will not complete.

[jok]

I think there's an executable called "apachectl" for an httpd daemon like;
# /usr/bin/apachectl stop

tnx,

jok

[Sukumar Alagappan]

I had a similar experience with one our programs on a HPUX 11.0 system. We had to
reboot the system to take care of the unkillable process.

This article from HP support site is interesting and could be used to find the reason an contact HP support for HPUX related problems.

Your system might need some patches if it is a HPUX related bug. Otherwise the httpd daemon may have to be updated with the correct patches.