Unable to kill process, in a "stop" state

[Kyle Adamski]

This is a new one for me. I have a user that has a process that he wants to kill. The parent id is 1 and root cannot kill it. I checked to see if there were any semaphores or shared memory segments that might be keeping it around, but it doesn't look like it. I was expecting to see it in a zombie state in top, but it is in a "stop" state. Has anyone come across this before? If so, is there anything short of a boot to get rid of this guy?

here is the output from top:

? 25242 user1 152 20 2408K 2876K stop 0:00 0.04 0.04 mtmain0


Thanks for any input.

[Rita C Workman]

Zombie processes can not "as a general rule" be killed. Showing that the parent process is '1' is telling you this walking dead process is owned by the operating system.

The only way to get rid of it is to reboot.....

Hope this helps,
/rcw

[Rita C Workman]

Well I did a bit more checking on this and came up with this that I think may be a better answer....

SIGSTOP and SIGCONT: Useful signals

There are several useful signals that can be used to suspend and resume tasks. SIGSTOP will stop a task, leaving it in a suspended state. And SIGCONT will resume a task stopped by SIGSTOP. To send these signals to a task, use the kill() function described above. If you want to send a signal to the current running task and you do not know what the process id is, use the getpid() function. See below for an example.

main()
{
int mypid;

printf("\n I'm going to stop myself and I don't know my pid.\n");

/* get my process id */
mypid = getpid();

/* send myself the stop signal */
kill(mypid,SIGSTOP);
}

Regards,
Rita

[Christopher Caldwell]

I'm not sure about your app, but we see similar problems when folks don't sequence the commands for the PFS daemon correctly. For instance, they eject a CD before umounting the CD using the pfs_umount command.

According the HP folks, the problem is that the software gets "hung" out in the hardware device. In effect you can kill the process, but it's "immune" to the kill because it's waiting for I/O from a hardware device that in an unknown state.

Unfortunately, the I/O will never happen, and unfortunately the process will never go away without a reboot, and unfortunately you won't be able to use the device until you reboot.

I don't recall seeing these apps in a STOP state, but you might see if this app could caught up in hardware.

I also wonder if a process in the STOP state
can be killed, since STOP and KILL are the only two signals that cannot be ignored.

Why don't you try to resume the process
kill -26 PID
then try to kill it
kill -9 PID

[Stefan Farrelly]

The zombie is probably being held open by a TCP socket connection to another machine. Use the shareware lsof program to try to find the IP associated with the pid of the zombie, break the tcp connection (reboot remote box, use ndd command to kill the tcp connection) and the zombie should die a peaceful death.

[Jack Werner]

This problem is a "pet peave" of mine.The IBM mainframe OS had this problem about 30 years ago. Of course their program dispatcher is markedly different than Unix's. What an enterprising System Programmer did was write a system routine called "burn" that would terminate a process regardless of its state. It simply removed it from the Program Dispatchers Queue. This is an over simplification of the "burn" process, but it got the job done! You no longer had to re-IPL to clear a "rogue" process. Why such a function is not available in Unix, I'll never know. Certainly, Unix has internal representations of all known processes. A command could be written to locate a process's internal representation(s) and remove them and notify the process's parent that it had terminated! The pat answer given to me by the Unix System support folks, is 'this is not "vanilla" Unix'. Unix uses the signal protocol, which means the intended victim can only be killed if in ceratin states. If they are in Oklahoma for example, waiting for the train to take them to California, KILL cannot touch them since they are in a "wait" state. (ie they will not recognize any signals).

[Kyle Adamski]

I didn't see a socket in use with lsof and ended up just taking the "easy" way out. Thanks for all of the prompt suggestions everyone.

[Wieslaw Krajewski]

Hi,

I think the best thing what can be done is to follow Rita's first advice and reboot system, if you really want to kill this process. But must add, not only zombie precesses we are not able to kill. Any process in a high priority state waiting for sth is robust and does not react on the signal 9 and any other. So in practice only way is to reboot.

Rgds.