Not entirely random thought

[unixronin]

Mainly directed at folks such as robbat2 and zaitcev:

What would it take to add the ability into a *nix kernel to kill a process that's in uninterruptible sleep due to, say, a hardware fault?  Say I have an external device, and it hangs up, and I can reset the device, but the daemon that was controlling it is still in uninterruptible sleep.  I really should be able to tell the kernel, "Look, I don't care that the process isn't responding, I SAID KILL IT, RIGHT NOW", and have the kernel do it.  Never mind trying to play nice with the process, just forcibly terminate its execution and free all of its allocated memory, ports, sockets etc.  Sort of a kill -9 on steroids.  SIG_TERM, SIG_KILL, SIG_EXTREME_PREJUDICE.  If the process is non-responsive and in uninterruptible sleep, that's most likely the reason WHY I want it terminated, without having to rely on the target process doing anything in response to a signal.  (OK, for that reason it wouldn't really actually be a signal, it'd be more of a kernel-instigated purge-process facility.  And per the point raised by ithildae, it should probably require UID0 to call it.)

Would there be any downsides to doing so?  Reasons why the capability would be a bad idea?

Being able to do that could save a reboot, or at least let you postpone a reboot until you're done with whatever it was you were working on.  It's always seemed odd to me that even a SIGKILL requires at least minimal cooperation on the part of the process being killed.

Comments

[unixronin.livejournal.com]

Yeah, I can see how that would be bad. However, in a case where the device locked up and you had to reset it, but the controlling process is still hung ...

I think it'd be a useful capability to have, with the provisos that (a) you should only use it if you're sure you know what you're doing, and (b) you're going to reboot the machine as soon as you safely can anyway, but it would really be a pain in the ass to have to do it right now. But let's face it, (a) applies to a LOT of things that you have to be root to do. A significant part of the fu of root is knowing when, how, and under what circumstances it can be made relatively safe to do those potentially highly dangerous things.

[gdmusumeci.livejournal.com]

With that caveat, why not just let the process merrily sit there doing nothing until you get around to scheduling a reboot?

[unixronin.livejournal.com]

Well, you probably can, as long as it doesn't have some resource locked that you need access to in order to finish what you were doing before you can reboot. Say, for example, the device that you just had to reset.