Hi, I read somewhere that no process can have its own signal handler for KILL, is that still correct? I''m asking because so many apps these days (qmail, umount, etc) don''t seem to get killed with that. Anyway, my real question here being that is there any brute force method to kill a process? I was just running "top" on my servers and I see a process called "umount /backup" taking up like 99% of one of the CPUs (running for like the last 12 hours). Anyway, since this is something I don''t need it, I''ve tried everything from -KILL, -STOP, -QUIT, -ABRT but this process won''t terminate. It just sits there doing nothing, yet taking all the CPU. I don''t want to reboot because it''ll cause more than 5 minutes of unnecessary downtime and I also want to learn how to deal with such nasty processes that won''t kill. If anybody knows, please let me know. Thanks, San P.S: If its of any use, I''m running the following, Linux 2.4.22-1.2115.nptlsmp ---- #!/usr/bin/perl print length "The answer to life,universe and everything";

have a look at the man page for kill, ie. "man kill"

"kill -9 <pid>" will forcibly kill a proccess, unless it''s locked in a IO-state

quote: Original post by Anonymous Poster
have a look at the man page for kill, ie. "man kill"

"kill -9 <pid>" will forcibly kill a proccess, unless it''s locked in a IO-state

thanks for the reply.. but already did that.. it appears that for some reason, none of the signals work to have it killed

Have you try to just log out. That maybe is''nt the "best" way to do it, but give it a shot.

http://www.cis.gsu.edu/~shong/oojokes/

quote: Original post by danne89
Have you try to just log out. That maybe is''nt the "best" way to do it, but give it a shot.

Yes, tried that several times too. I''ve logged in and logged out like 20 times since yesterday night to check if the stupid process died of its age.. but noooo, its just likes to sit there are take 99% CPU.. therez gotta be a murphy law about such processes too

have you tried pkill?

e.g. pkill -u (this will of course log you out) or pkill -u qmail-user

Just to confirm, you are using kill -9 as root, yes?

Thanks, but the process finally died by itself before i could have used pkill or maybe the hosting rebooted it afterall, not sure. But I will definitely try this command the next time something like this happens.

@debaere: yes, I''ve been executing all these commands as root.. after a lot of googling, I see the process could have been some sort of a kernel/debug/zombie process. Atleast the caldera''s site says that such processes can''t be killed without rebooting.. guess that explains it.

If it was a zombie, odds are it wouldn''t be affecting system performance, init should have cleaned it up and would definitely be gone after a reboot. If they require a reboot, odds are its a driver bug hanging on open descriptors.

You can find out if a reboot took care of your problem by checking your dmesg output, see when your system was last booted, or using uptime to see how long its been running. If you know your system you can deduce if it was rebooted recently.

Some processes are now managed by a master process that respawns them when you run a kill. In which case you need to use the scripts supplied with the daemon to manage the process, or you need to kill the master process first.

Int.

It''s possible that there''s some sort of IO problem causing these processes to be blocked in the "D" (IO wait) state.

Killing such a process won''t affect it until it becomes unblocked, as signals get queued or something until then.

If that happens, more than likely they''re trying to access a slow device which is not cooperating, like a scratched CD-ROM (or dodgy hard drive).

But they won''t show as using 100% CPU, but may contribute to some measurements if it counts IOwait as being "used" time (even though it''s not technically using the CPU)

Zombies can''t be killed because they''re dead already (and zombies can''t use CPU or memory and can''t have open files I think)

Kernel daemons cannot generally be killed (although some can) - but they should not be killed. Kernel daemons are not always easy to identify, but they often have low PIDs (2,3,4 etc) and show up as using no memory. They don''t normally do very much, so shouldn''t be busy.

There isn''t a naming convention for kernel daemons, and different kernel versions have different ones (some drivers also create their own). IMHO they shouldn''t appear on the process list because they aren''t really processes.

Mark