Killing a stubborn process...

I have a stubborn process on my OpenBSD box that just refuses to die. It is taking up about half a meg of memory and refuses to die. It appears to be an errant gzip process that was executed from the console on 06 Jan 2002.

Here is a snippet of my attempts to kill the gzip process

/home/joeuser $ ps -aux | grep "gzip"
root     13647  0.0  0.1   452   408 C0- DL     6Jan02    4:41.24 gzip -c
/home/joeuser $ kill 13647
/home/joeuser $ ps -aux | grep "gzip"
root     13647  0.0  0.1   452   408 C0- DL     6Jan02    4:41.24 gzip -c
/home/joeuser $ kill -HUP 13647
/home/joeuser $ ps -aux | grep "gzip"
root     13647  0.0  0.1   452   408 C0- DL     6Jan02    4:41.24 gzip -c
/home/joeuser $ kill -9 13647
/home/joeuser $ ps -aux | grep "gzip"
root     13647  0.0  0.1   452   408 C0- DL     6Jan02    4:41.24 gzip -c
/home/joeuser $ kill -9 13647
/home/joeuser $ kill -9 13647
/home/joeuser $ kill -9 13647
/home/joeuser $ ps -aux | grep "gzip"
root     13647  0.0  0.1   452   408 C0- DL     6Jan02    4:41.24 gzip -c

It just refuses to die. According the ps, it has core memory pages locked and some disk access. According to top, the it isn't doing too much and not taking up any CPU time:

13647 root      -5    0  452K  408K idle  physio   4:42  0.00% gzip

Any suggestions on killing this process other than reboot? I really want to keep the uptime high (yeah, cheap bragging rights... :))

/home/joeuser $ uptime
 5:16PM  up 62 days, 23:17, 1 user, load averages: 1.13, 1.12, 1.09

Are you logged in as root on your box when trying to kill the process?
If not,might want to try that...

Jason

:rolleyes:

You may like find the parent PID of the process, and try killing the parent PID.

Milind.

Try this.

Do a ps -aef|grep (your PID#)

# ps -aef |grep 13647

# ps -aef |grep (parent PID#) To find the process that possibly spawned your process "gzip -c".

If it has a parent PID. a process that spawned this process, then you should try to kill that process.

Keep trying to find the parent in this manner until you find the true parent. Then you should be able to kill this PID as well.

Using the -j option of ps under OpenBSD, I was able to identify the PPID.

The PPID? It is 1.

Yeah. I think I am gonna let the gzip -c sit for a while until I absolutely have to reboot the machine (probably sometime in March). It isn't using any more memory and isn't using any CPU so it is really not a problem.

Thanks for the responses!

I wonder what job spawned the gzip with the -c option. I took a look at my cronjob entries and they do not use the -c option. I use gzip --best for my scripts. I need to do some more investigating. There doesn't seem to be any problem with the system over-all.

Weird.

Are you the "root" user when you are trying to Kill this process?

I see that your directory is /home/joeuser. Do an "id" to see if you are root.

If you aren't the Admin, get to root have your Unix Admin try to remove it.

Just a thought...

Yeah. I am root on the machine. It's my firewall/proxy/webserver/packet sniffer machine here at the house. I do some perl/c coding on it from time to time but that is about it.

It's strange that the `gzip -c` has hung the way it has. Sometime in March I am bringing up the 23 rack from the garage to my office and I will have to power down the machine at that point. I reckon it will not be a problem after that.

Your ps output says that the process is waiting on the physio routine. That means it is doing a read or a write to disk and is waiting for it to complete. Unix will not allow the process to die until the i/o completes. This is how it fulfills its promise of atomic disk i/o. I would suspect a hardware error in combination with a disk driver with poor error handling. The other possibility is a pathetic disk driver.