Can't kill hung remote CP copy

Patrick O'Callaghan pocallaghan at gmail.com
Sun Apr 15 04:22:32 UTC 2012


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



More information about the users mailing list