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

Comments

[ithildae]

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]

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]

Yeah, enough rope to swing...

[sierra_nevada]

When UNIX does not permit you to kill a process, it is typically because that process has initiated DMA I/O, and a piece of RAM allocated to that process has been marked as either the source or the recipient of the I/O, ergo, that RAM must remain resident, and must remain part of that process (permissions, etc) until the I/O completes.

Failure to ensure this would be bad, e.g. the device completes the I/O ... but into a piece of RAM that belongs to another process. Did it smash something important? You might not find out until much later, if at all.

[unixronin]

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]

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

[unixronin]

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.

[ilcylic]

kill -IN_THE_FACE

[mrmeval]

If qemu matures to the point it can either fully emulate or has some sort of bridge to the real hardware AND it does it's own hardware handling properly. You can just close the window. ;)

It does work now but the emulated PC is ultra vanilla. I use it just to have a sandbox for windows.

It would be pretty cool to have a rack SMOS cardio-486's, one processor per task with the power, reset, etc controlled by another processor. I'd never heard of but they have some gathering dust at work. Credit card sized 486 w/16 megs, video, serial, and some sort of buss connection. They can boot dos with the right breakout. ;)

Yes I lust for it but there is almost ZERO information online about them and ours were just part of another system we sold which is now obsolete.

http://www.thefreelibrary.com/S-MOS+Systems+announces+'486+credit-card+sized+computer.-a015970434