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

[ithildae.livejournal.com]

Without the control structures within the process, can the kernel determine what memory, process, ports and sockets are being used by the process? It has been a while, but I thought that the answer was, 'no'.

It is really kind of strange, but we can't really stop a process under *nix, all we can do is ask it to commit suicide, with varying levels of insistence.

With that capability, could you kill the scheduler? The memory manager? or some other, vital, kernel function? Would it be easy to violently bring the system to a sudden, crashing stop? I know that the *nix philosophy is to allow sysadmins enough rope to swing, (#rm -R .) but killing the kernel seems too easy.

[unixronin.livejournal.com]

Well, I suppose one could argue that if you make it require UID0, then if you have the privileges to use it, you have the privileges to kill the system in any of a hundred other ways anyway.

[ithildae.livejournal.com]

Yeah, enough rope to swing...