Can't kill hung remote CP copy

Andy Blanchard zocalo at gmail.com
Sat Apr 14 18:42:11 UTC 2012


On 14 April 2012 19:26, Reindl Harald <h.reindl at thelounge.net> wrote:

>
> 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
>

In theory, yes, but the problem would be that the kernel would no longer
have any way of knowing what state the device being waited on is in.
Depending on the device that could be very bad news and potentially result
in trashed data.

The only thing you can do is try to cause an abort/fail on whatever the
device is - in this case the NIC or the remote mount.  Couple of tricks I
used to use on tape drives that snarled up like this were:

1) Unload the device driver with "rmmod" - probably not possible here,
since it would be the NIC.
2) Put the machine into suspend/hibernate and then resume.

Once you've done that, even a SIGTERM might be sufficient to abort the
process.


I think we're looking at the wrong problem though; I'm more curious as to
why cp is being used for the copy instead of rsync, which is much more
tolerant of this kind of problem.  The OP said this was because "rsync was
too slow", but that's not my experience with cp vs rsync at all, especially
on subsequent copies. Perhaps a better angle of attack would be to see
what's taking so long using rsync?

-- 
Andy

*The only person to have all his work done by Friday was Robinson Crusoe*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120414/68933ec8/attachment.html>


More information about the users mailing list