# Killng stubborn processes cause of bad hardware.

## dE_logics

Suppose I have a cardreader plugged in, then I start gsmartcontrol, and smartclt starts querying SMART info from the card reader...but it hangs...I mean both smartclt and gsmartcontrol hangs after which sending any sort of signal to either the of the 2 does not help. You have to physically pullout the cardreader.

There're many cases like this, primarily cause of bad hardware and might be cause of external CD/DVD burners.

My question here is, how do I actually kill these processes?

----------

## krinn

you can use kill -9

if it doesn't work, you have to kill the parent process of the zombi : grab PPID from ls -l (won't do it if PPID is init)

and if it still doesn't work and you really wish to kill all zombi, you better try left4dead

----------

## eccerr0r

if it's in uninterruptable sleep ("D" state in ps) even kill -9 won't kill it, you'll have to somehow resolve the dependency.  Apparently unplugging the device seems to finally tell the kernel/processes to give up.  I've never seen a utility that gets processes out of the uninterruptable sleep state, mostly because it is a risk of data loss due to likely mucking with semaphores (and likely any data about to be written would be gone.)

I'm not sure if there's a way to force a USB disconnect/reprobe via software...that would be interesting...

----------

## dE_logics

Yup. Absolutely nothing works except plugging the hardware out.

I tried all sorts of signals though ksysguard.

Maybe there's a kernel config to fix this...

----------

## haarp

Oh, I also wish there was a way to kill these cases. Especially faulty CDs/DVDs or harddisks tend to do that, hanging anything and everything that even remotely comes close to even looking at the hardware. The only way is to wait until it times out 3 days later or use SysRq+u to remount your stuff ro and press the reset button. Incredibly frustrating.

----------

## DirtyHairy

I've also been looking around for a way to get rid of processes in uninterruptable sleep some years ago, and I am pretty sure that it is impossible for exactly the reasons given by eccerr0r: a process in this state is not active at all, but instead waiting for a syscall to finish. The only way to "kill" it would be to abort the syscall, and as far as I know this is not supported by the kernel for safety reasons --- just aborting a syscall might leave pieces of the kernel in an undefined state.

----------

## dE_logics

It will be good if someone notifies this to the kernel devs.

----------

