<br><div class="gmail_quote">On 14 April 2012 19:26, Reindl Harald <span dir="ltr"><<a href="mailto:h.reindl@thelounge.net">h.reindl@thelounge.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
on the other hand i am missing understanding that there<br>
is no root-command to kill such processes without<br>
"their help"<br>
<br>
the kernel should be able to kill anything<br>
sounds like a missing interface for me<br clear="all"></blockquote></div><br>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.<br>
<br>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:<br><br>1) Unload the device driver with "rmmod" - probably not possible here, since it would be the NIC.<br>
2) Put the machine into suspend/hibernate and then resume.<br><br>Once you've done that, even a SIGTERM might be sufficient to abort the process.<br><br><br>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?<br>
<br>-- <br>Andy<br><br><i>The only person to have all his work done by Friday was Robinson Crusoe</i><br>