On Sat, 2012-04-14 at 20:26 +0200, Reindl Harald wrote: > > Am 14.04.2012 20:19, schrieb Patrick O'Callaghan: > >> When you do a "kill" you are sending a "signal" to a process and that process will > >> act upon it depending on the signal. For example, if you did a "kill -1" to the > >> named process it will cause it to reread its configuration files and zone files. > >> > >> Whatever process you send the kill to must be in a state where it can receive and > >> process the signal. > > > > Exactly. The correct view of "kill -9" is not that you kill the process > > but that you order the process to commit suicide. If it's not listening, > > no amount of shouting is going to make a difference. > > that is all correct > > on the other hand i am missing understanding that there > is no root-command to kill such processes without > "their help" > > the kernel should be able to kill anything > sounds like a missing interface for me Privilege has nothing to do with it. The process cannot be killed because it is in a state where it will not wake up in order to process the kill signal, which in turn is because it's waiting on something which "has to happen". "D" state is meant for waiting on events which will definitely happen and happen quickly, e.g. an interrupt signalling completion of a DMA transfer; unfortunately most of the filesystem interface was designed when the only filesystems were on directly-attached disks and if an expected interrupt didn't happen then you had a hardware issue. The problem arises when we try to apply this to network-attached devices, where things are much more uncertain. We want network disks to look like local disks to the applications programmer, but once in a while reality has a way of intruding. The non-interruptible nature of some states is a fundamental part of how Unix/Linux processes work at the kernel level. Changing it would require a radical redesign. Perhaps some of the real-time project work would be relevant, but good luck getting that accepted into the mainline kernel. poc -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
