Archived

This topic is now archived and is closed to further replies.

how to kill those really nasty processes?

This topic is 4947 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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";

Share this post


Link to post
Share on other sites
Guest 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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
processes stuck in D-state are kernel bugs. if you''re not using any proprietary drivers, linux-kernel might want to hear about it. Make sure you''re running the last kernel first, though.

actually, you should probably go through your vendor instead. file a bug.

Share this post


Link to post
Share on other sites
Processes stuck in the D state are not (necessarily) kernel bugs.

If there is a device, which is not providing data, and a process needs it, it will stay in the D state until it''s there. This applies to most devices, with the exception of certain network filesystems, in which case there are timeouts (only if NFS is mounted soft).

The reason for this is, you can''t just "Abort/Retry/Fail" on an operating system which supports virtual memory; the instruction the processor is running could be trying to read out of IO which has failed - in which case it had better retry until it succeeds, or crash the process.

Mark

Share this post


Link to post
Share on other sites