4:43 a.m.
Hi
Fedora 16 x86_64 Kernel 3.3.1-3.fc16.x86_64 #1 SMP
I have cif mount over a VPN to a remote windows share which I have a
local
"cp -fLruv" to.
If this "cp -fLruv" hangs because a VPN problem broke the connection
temporarily. I can't kill the CP and the system won't restart due to the
CIF mount which it can't umount as it is busy with the hung cp
operation !
I have you manually hit reset to get it back!!
How can I kill the broken cp operation ?
I have tried rsync but it takes too long
--
Andrew Gray <andrewg(a)linnetsol.co.uk>
Linnet Solutions Ltd
5:16 p.m.
On 14 April 2012 20:25, Michael Hennebry <hennebry(a)web.cs.ndsu.nodak.edu>wrot$
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
On Sat, 14 Apr 2012, Alan Cox wrote:
When it leaves the system in an unstable state or where corruption
could
follow. Far better then to leave that process stuck unless things sort
out.
In the case of NFS btw read the mount page for the "soft" and "intr"
options and also read about umount -f.
Amazing. Not in a good way.
The corruption would be at the client end, correct?
Is there a reason that the client could not just report back
"taking to long to mount" and leave its data uncorrupted?
Would similar corruption take place if the process had just
termintated itself without waiting for NFS to succeed?
On Sat, 14 Apr 2012, Andy Blanchard wrote:
Waiting for a timeout implies a reasonably sane state of affairs
regarding
any data in transit, and if the worst has already happened then it's not
going to make any difference. Either way, it forces the end user to make a
hopefully sensible decision about how to reset the device and recover from
the situation.
If, on the otherhand, you do a soft reset of the device and resume
transfering data... Well, think about the garbage that can come out of a
printer when jobs go wrong, now imagine that being written to a hard disk,
tape drive, etc.
Don't resume tranfering data as though nothing had gone wrong.
Possibly don't resume transfering data at all.
Unless the human says otherwise,
assume one will not be allowed to transfer any more data on that channel.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword." -- Lily
11:22 p.m.
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
2:37 p.m.
On 04/14/2012 12:13 PM, My Usenet wrote:
Typically if you need to do a bios reset - then unplugging the
battery
will be helpful.
I take it that you didn't bother to read my original post. I was
talking about a computer hanging while processing an interrupt with
interrupts disabled. Not something that's likely to happen because of a
simple page fault or other error, or even at all.[1] Think of it as a
black swan: something that's not supposed to exist, but does, once in a
great while. Fixing it doesn't require a BIOS reset, just restarting
the computer, and under the circumstances, that generally requires[2]
pulling the plug.
[1]That's the type of bug that's supposed to be swatted before the BIOS
goes into production.
[2]or did back when I was on the phones
3:11 p.m.
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
When it leaves the system in an unstable state or where corruption could
follow. Far better then to leave that process stuck unless things sort
out.
In the case of NFS btw read the mount page for the "soft" and "intr"
options and also read about umount -f.
Alan
3:30 p.m.
On 04/14/2012 04:11 PM, Alan Cox wrote:
> Under what circumstance would killing a waiting process
> be worse than a process that should have waited,
> but terminated instead?
When it leaves the system in an unstable state or where corruption could
follow. Far better then to leave that process stuck unless things sort
out.
But, drivers can also be reset. And resetting a driver should, in
theory, reset the hardware. So a system should never be left in an
unstable state. But, what if there are other requests pending of that
same hardware? The only alternative is to invalidate those requests and
issue an I/O error. But the app-handlers should catch these and deal
with them reasonably.
Then there's the question of what could require an infinite amount of
time for a driver to return? How long will a human wait? I can't think
of a request that isn't bounded by some physical time limit except for a
requested sleep alarm. And I can't think of a request that I'm willing
to wait on for 3 days. There really shouldn't be a "wait-forever" state
because that just means "wait until the user powers me off". I think
all states should be bounded. At least bounded from the standpoint of
returning to user-level for further action (either re-invocation of the
wait or exiting). Let the app-layer determine what to do if the lower
level can't do something - the app-layer is free to re-invoke the kernel
request.
Shane
3:21 p.m.
On Sat, 14 Apr 2012 21:11:36 +0100
Alan Cox wrote:
In the case of NFS btw read the mount page for the "soft"
and "intr"
options and also read about umount -f.
One of my favorite near infinite hangs is a giant process that
decides to core dump across NFS. I don't know if it is still
the case, but once upon a time when linux started writing
a core file, it would never stop for any reason till it was
done.
When you do the math and find that it will take several days
to finish the core dump across the NFS link, pulling the plug
on the machine becomes the best option :-).
2:54 p.m.
On 14 April 2012 20:37, jdow <jdow(a)earthlink.net> wrote:
I was about to comment a little more acerbicly that he's
obviously a
youngster.
Killing power used to be the only way to shut down a locked up computer
with
ANY then available OS on it. I remember those bad old days too well.
{^_-}
Shudder. I remember those days too.
Of course, these days we thankfully have an excellent operating system
available that lets us perform a clean shutdown from all but the most
severe of lockups using a combination of "SysReq" and some other key. :)
--
Andy
*The only person to have all his work done by Friday was Robinson Crusoe*
2:52 p.m.
On 04/14/2012 12:40 PM, jdow wrote:
As long as that is enabled in the BIOS it will perform a hard
shutdown. Of course, if the heart is racing sometimes it is wise to tell
the
poor victim, hold it in for 30 seconds or until the computer shuts down.
Back when I was on the phone, you sometimes needed to power down a
computer, leave it off long enough for the RAM to go blank and then turn
it on. I never told them how long to leave their computer off; I had
them turn it off, counted quietly to fifteen (or watched my watch) and
then told them to turn it back on. Probably, if I'd had to do what you
suggest, I'd have them push AND HOLD the power button while I counted
off the seconds. The advantage, of course, is the fact that my emotions
aren't involved, so I'm more likely to get the count right.
And, to comment on something in your other post, there was a time, when
I was doing senior tech support, that I was very impatient with junior
techs who didn't see, understand or do things I considered obvious.
Then I realized that most of them didn't have the experience to be aware
of these things and that it wasn't fair of me to expect them to know
most of what I did. I suspect that I was much, much easier to work with
after that, although I'm sure that the Zoloft helped.
2:48 p.m.
On 14 April 2012 20:25, Michael Hennebry <hennebry(a)web.cs.ndsu.nodak.edu>wrote:
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
Waiting for a timeout implies a reasonably sane state of affairs regarding
any data in transit, and if the worst has already happened then it's not
going to make any difference. Either way, it forces the end user to make a
hopefully sensible decision about how to reset the device and recover from
the situation.
If, on the otherhand, you do a soft reset of the device and resume
transfering data... Well, think about the garbage that can come out of a
printer when jobs go wrong, now imagine that being written to a hard disk,
tape drive, etc.
--
Andy
*The only person to have all his work done by Friday was Robinson Crusoe*
2:43 p.m.
On 14 April 2012 20:06, Joe Zeff <joe(a)zeff.us> wrote:
I'd think that there'd have to be a special command,
requiring root, to do
it for exactly that reason. There's no way you can safely automate that
decision, and it's probably best if the average user doesn't have direct
access to it; if nothing else, having to use either su or sudo along with a
password (and possibly a confirmation dialog) would remind people that this
isn't something you do lightly. How it gets done, alas, is beyond me
because I don't know enough about such things.
I'm not an expert at this low a level of the kernel either, but I think
that it would, in theory, be possible for the kernel to forcibly unload a
program, then try to cleanly close any open file handles and similar "tidy
up" operations.
That still leaves the problem of dealing the actual device which caused the
lockup in the first place, which is now in an unknown state. Depending on
what it is you might want to "offline" it until the next reboot,
"reset" it
(rmmod, insmod), or even perform an immediate shutdown of the system. In
many cases the kernel just isn't going to know the correct course of
action, especially if the device is remote or a more unusual peripheral.
Could get messy, and who is the user going to blame for *their* incorrect
call? I'd assume that the current status quo is the safest bet with
regards to potential data loss.
--
Andy
*The only person to have all his work done by Friday was Robinson Crusoe*
2:42 p.m.
On 04/14/2012 12:25 PM, Michael Hennebry wrote:
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
I think that the idea is that if the process is in an uninterruptable
sleep, it's for a good reason and the kernel is expected to assume that
the programmer knew what he was doing and why. Most of the time, that's
a good assumption; in fact, almost always. Alas, there's currently no
way to override that on the very rare occasions that it's wrong.
2:40 p.m.
On 2012/04/14 12:37, Joe Zeff wrote:
On 04/14/2012 12:13 PM, My Usenet wrote:
> Typically if you need to do a bios reset - then unplugging the battery
> will be helpful.
I take it that you didn't bother to read my original post. I was talking about a
computer hanging while processing an interrupt with interrupts disabled. Not
something that's likely to happen because of a simple page fault or other error,
or even at all.[1] Think of it as a black swan: something that's not supposed to
exist, but does, once in a great while. Fixing it doesn't require a BIOS reset,
just restarting the computer, and under the circumstances, that generally
requires[2] pulling the plug.
[1]That's the type of bug that's supposed to be swatted before the BIOS goes
into production.
[2]or did back when I was on the phones
In today's terms with the momentary contact ON button the OFF feature, unless
disabled in the BIOS, will turn it off after 2 to 5 seconds camped on the
power button. As long as that is enabled in the BIOS it will perform a hard
shutdown. Of course, if the heart is racing sometimes it is wise to tell the
poor victim, hold it in for 30 seconds or until the computer shuts down. 5
seconds can often seem like an eternity. (Yes, I have met at least one BIOS
that had a "what do I do with the power button press" that could disable the
hard reboot.)
{^_^}
2:37 p.m.
On 2012/04/14 12:30, Joe Zeff wrote:
On 04/14/2012 12:07 PM, Reindl Harald wrote:
> every computer i know does a hard power-off pressing the power-button
> for 5 seconds if all other things are failing
This was about ten or twelve years ago. I'm not sure, but I might have even had
them try that. (Please note that even then, their laptop was so old that they
needed a screwdriver to remove the battery. Don't know what happened after that,
as I ended the call and told them to call back after they'd gotten control of
the computer back.) I do know that when it happened to me at home, it didn't
matter how long I held down the power button, nothing happened. Only pulling the
plug worked. Still, it's nice to know that current computers don't have that
problem.
I was about to comment a little more acerbicly that he's obviously a youngster.
Killing power used to be the only way to shut down a locked up computer with
ANY then available OS on it. I remember those bad old days too well.
{^_-}
2:30 p.m.
On 04/14/2012 12:07 PM, Reindl Harald wrote:
every computer i know does a hard power-off pressing the
power-button
for 5 seconds if all other things are failing
This was about ten or twelve years ago. I'm not sure, but I might have
even had them try that. (Please note that even then, their laptop was
so old that they needed a screwdriver to remove the battery. Don't know
what happened after that, as I ended the call and told them to call back
after they'd gotten control of the computer back.) I do know that when
it happened to me at home, it didn't matter how long I held down the
power button, nothing happened. Only pulling the plug worked. Still,
it's nice to know that current computers don't have that problem.
2:25 p.m.
On Sat, 14 Apr 2012, Andy Blanchard wrote:
On 14 April 2012 19:26, Reindl Harald <h.reindl(a)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.
Of course the kernel has no way of knowing that the bad news has not already
happened and that continued waiting is not just making things worse.
It would seem sensible to be able to kill
any process that is not reset immune.
For that matter, it would seem sensible to be able to
kill any process that is not power button immune.
Perhaps kill --with-extreme-prejudice and kill --with-all-prejudice .
Under what circumstance would killing a waiting process
be worse than a process that should have waited,
but terminated instead?
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword." -- Lily
2:13 p.m.
On 04/14/2012 01:07 PM, Reindl Harald wrote:
Am 14.04.2012 20:55, schrieb Joe Zeff:
> Once, the computer was a laptop and the caller had to go hunt up a screwdriver to
take the battery out.
not really
every computer i know does a hard power-off pressing the power-button
for 5 seconds if all other things are failing
Typically if you need to do a bios reset - then unplugging the battery
will be helpful. Of course you can also reset the CMOS by jumper at
that point - but I don't see that being an issue in a page fault or
any other likely multi-pipe error. Everything that could cause such a
fault would have to be post-mutex layer. Resetting the machines power
should take care of it - but this is a very strange error to be
hypothesizing in the first place. I'd be curious to know if both
systems bash is of the same release or not..
2:06 p.m.
On 04/14/2012 11:42 AM, Andy Blanchard wrote:
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.
I'd think that there'd have to be a special command, requiring root, to
do it for exactly that reason. There's no way you can safely automate
that decision, and it's probably best if the average user doesn't have
direct access to it; if nothing else, having to use either su or sudo
along with a password (and possibly a confirmation dialog) would remind
people that this isn't something you do lightly. How it gets done,
alas, is beyond me because I don't know enough about such things.
1:55 p.m.
On 04/14/2012 11:19 AM, Patrick O'Callaghan wrote:
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.
As another example, your CPU sometimes disables interrupts while it's
processing one because what it's doing is too time-bound to be broken
into. If something happens and it hangs, even pushing the reset button
(assuming your box has one) will work; it takes power cycling. I had
that happen, occasionally, when I was doing tech support and I'd have to
tell callers to pull the power cord for a few seconds. (It also
happened to my own box once or twice, years ago.) Once, the computer
was a laptop and the caller had to go hunt up a screwdriver to take the
battery out.
1:42 p.m.
On 14 April 2012 19:26, Reindl Harald <h.reindl(a)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*
1:26 p.m.
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
1:19 p.m.
On Sat, 2012-04-14 at 23:14 +0800, Ed Greshko wrote:
On 04/14/2012 10:54 PM, Hal wrote:
>
>
> On 4/14/2012 8:08 AM, suvayu ali wrote:
>> On Fri, Apr 13, 2012 at 21:09, Andrew Gray<andrewg(a)linnetsol.co.uk>
wrote:
>>> Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
>> I'll repeat myself: "The only way to get rid of these processes is to
>> wait or reboot."
>>
>
> Pardon my stupidity, if you can observe ot determine the process number for the cp
> operation it appears one could use 'kill' and one of its options to remove
the
> process.
>
>
Ahhhh.....no....
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.
poc
10:28 a.m.
On 04/14/2012 11:22 PM, Hal wrote:
FINE..then REBOOT the darn thing and quit wasting time ..!!
Actually, the only time wasted was yours in answering a question erroneously.
I view correcting your response as a community service. :-) :-)
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
10:22 a.m.
On 4/14/2012 11:15 AM, suvayu ali wrote:
Hi Hal,
On Sat, Apr 14, 2012 at 16:54, Hal<hal(a)faams.net> wrote:
> On 4/14/2012 8:08 AM, suvayu ali wrote:
>> On Fri, Apr 13, 2012 at 21:09, Andrew Gray<andrewg(a)linnetsol.co.uk>
>> wrote:
>>> Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
>> I'll repeat myself: "The only way to get rid of these processes is to
>> wait or reboot."
>>
> Pardon my stupidity, if you can observe ot determine the process number for
> the cp operation it appears one could use 'kill' and one of its options to
> remove the process.
And I will repeat myself again: You _cannot_ kill a process in
uninterruptible sleep. Only way to get rid of this is to wait for it to
finish, or reboot the system. If you could interrupt it (sending SIGKILL
is a type of interruption), it wouldn't be called uninterruptible sleep
would it?
Some reference:
<http://stackoverflow.com/questions/223644/what-is-an-uninterruptable-proc...
FINE..then REBOOT the darn thing and quit wasting time ..!!
10:15 a.m.
Hi Hal,
On Sat, Apr 14, 2012 at 16:54, Hal <hal(a)faams.net> wrote:
On 4/14/2012 8:08 AM, suvayu ali wrote:
>
> On Fri, Apr 13, 2012 at 21:09, Andrew Gray<andrewg(a)linnetsol.co.uk>
> wrote:
>>
>> Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
>
> I'll repeat myself: "The only way to get rid of these processes is to
> wait or reboot."
>
Pardon my stupidity, if you can observe ot determine the process number for
the cp operation it appears one could use 'kill' and one of its options to
remove the process.
And I will repeat myself again: You _cannot_ kill a process in
uninterruptible sleep. Only way to get rid of this is to wait for it to
finish, or reboot the system. If you could interrupt it (sending SIGKILL
is a type of interruption), it wouldn't be called uninterruptible sleep
would it?
Some reference:
<http://stackoverflow.com/questions/223644/what-is-an-uninterruptable-proc...
--
Suvayu
Open source is the future. It sets us free.
10:14 a.m.
On 04/14/2012 10:54 PM, Hal wrote:
On 4/14/2012 8:08 AM, suvayu ali wrote:
> On Fri, Apr 13, 2012 at 21:09, Andrew Gray<andrewg(a)linnetsol.co.uk> wrote:
>> Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
> I'll repeat myself: "The only way to get rid of these processes is to
> wait or reboot."
>
Pardon my stupidity, if you can observe ot determine the process number for the cp
operation it appears one could use 'kill' and one of its options to remove the
process.
Ahhhh.....no....
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.
If you process is stuck in a WAIT state it won't "catch" the signal. The
same is
true of Zombie processes. Zombies are child processes whose parent process has died
unexpectedly.;
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
9:54 a.m.
On 4/14/2012 8:08 AM, suvayu ali wrote:
On Fri, Apr 13, 2012 at 21:09, Andrew
Gray<andrewg(a)linnetsol.co.uk> wrote:
> Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
I'll repeat myself: "The only way to get rid of these processes is to
wait or reboot."
Pardon my stupidity, if you can observe ot determine the process number
for the cp operation it appears one could use 'kill' and one of its
options to remove the process.
YMMV...
--Hal.
2:31 p.m.
On Fri, 2012-04-13 at 20:09 +0100, Andrew Gray wrote:
On Fri, 2012-04-13 at 15:22 +0100, Andrew Gray wrote:
> On Fri, 2012-04-13 at 15:59 +0200, suvayu ali wrote:
> > On Fri, Apr 13, 2012 at 15:22, Kevin Martin <kevintm(a)ameritech.net>
wrote:
> > >
> > >
> > > On 04/13/2012 05:55 AM, suvayu ali wrote:
> > >> On Fri, Apr 13, 2012 at 11:47, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> > >>>> How can I kill the broken cp operation ?
> > >>> killall -s SIGKILL cp
> > >> This might not work always. I have faced similar issues with
processes
> > >> waiting to access a filesystem over the network. In these cases if
there
> > >> is a problem with the network it might get into an UNINTERRUPTIBLE
SLEEP
> > >> since it is waiting for I/O. The only way to get rid of these
processes
> > >> is to wait or reboot. In my case this was a tape drive over a network
> > >> filesystem.
> > >>
> > >> The OP can check if this is indeed the case by doing
> > >>
> > >> $ ps uf
> > >>
> > >> If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE
of the
> > >> process should be D. If not then you can ignore my comment.
> > >>
> > > What happens if you ifdown the nic (if you are on the console
> > > obviously)? Would that allow the cif mount and/or the cp to become
> > > available for umount/kill?
> >
> > That is a good question. I don't know what would happen then. I guess if
> > the filesystem implementation is smart enough to return an error when
> > the network goes down, then the I/O wait is over and the application
> > gets file read error of some kind and "wakes up" from its
> > UNINTERRUPTIBLE SLEEP. But then, this is just a hypothesis which I
> > cannot test (I do not have admin privileges to test this).
> >
> > --
> > Suvayu
> >
> > Open source is the future. It sets us free.
>
> Thanks for your help
>
> I will try all the suggestions next time, including disabling the NIC
> to see if it free's the CP or allows umount ?
>
>
I have had another cp hung, with NIC disabled:-
killall -s SIGKILL cp Doesn't kill the hung cp
ps -uf show the cp is in STATE D hence UNINTERRUPTIBLE SLEEP
So the only thing to do is restart though it will hang going down trying
to umount the CIF mount held my the hung cp.
Only thing then is to then hit the system reset and FORCE restart
Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
You said it yourself: force restart. Uninterruptible means what it says.
It doesn't mean "high priority" or "only killable by root". It
means
"the process is waiting on something which has to happen and there's no
Plan B if it doesn't happen". Needless to say, network disconnection or
latency is a fact of life, but if it wasn't anticipated by the designer
then you're screwed.
NFS allows you to "soft-mount" remote filesystems to avoid this sort of
problem. Not sure about CIF though.
Some background: http://lwn.net/Articles/288056/
poc
2:09 p.m.
On Fri, 2012-04-13 at 15:22 +0100, Andrew Gray wrote:
On Fri, 2012-04-13 at 15:59 +0200, suvayu ali wrote:
> On Fri, Apr 13, 2012 at 15:22, Kevin Martin <kevintm(a)ameritech.net> wrote:
> >
> >
> > On 04/13/2012 05:55 AM, suvayu ali wrote:
> >> On Fri, Apr 13, 2012 at 11:47, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
> >>>> How can I kill the broken cp operation ?
> >>> killall -s SIGKILL cp
> >> This might not work always. I have faced similar issues with processes
> >> waiting to access a filesystem over the network. In these cases if there
> >> is a problem with the network it might get into an UNINTERRUPTIBLE SLEEP
> >> since it is waiting for I/O. The only way to get rid of these processes
> >> is to wait or reboot. In my case this was a tape drive over a network
> >> filesystem.
> >>
> >> The OP can check if this is indeed the case by doing
> >>
> >> $ ps uf
> >>
> >> If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE of
the
> >> process should be D. If not then you can ignore my comment.
> >>
> > What happens if you ifdown the nic (if you are on the console
> > obviously)? Would that allow the cif mount and/or the cp to become
> > available for umount/kill?
>
> That is a good question. I don't know what would happen then. I guess if
> the filesystem implementation is smart enough to return an error when
> the network goes down, then the I/O wait is over and the application
> gets file read error of some kind and "wakes up" from its
> UNINTERRUPTIBLE SLEEP. But then, this is just a hypothesis which I
> cannot test (I do not have admin privileges to test this).
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
Thanks for your help
I will try all the suggestions next time, including disabling the NIC
to see if it free's the CP or allows umount ?
I have had another cp hung, with NIC disabled:-
killall -s SIGKILL cp Doesn't kill the hung cp
ps -uf show the cp is in STATE D hence UNINTERRUPTIBLE SLEEP
So the only thing to do is restart though it will hang going down trying
to umount the CIF mount held my the hung cp.
Only thing then is to then hit the system reset and FORCE restart
Again how do you kill a cp in UNINTERRUPTIBLE SLEEP !!!
--
Andrew Gray <andrewg(a)linnetsol.co.uk>
Linnet Solutions Ltd
9:22 a.m.
On Fri, 2012-04-13 at 15:59 +0200, suvayu ali wrote:
On Fri, Apr 13, 2012 at 15:22, Kevin Martin
<kevintm(a)ameritech.net> wrote:
>
>
> On 04/13/2012 05:55 AM, suvayu ali wrote:
>> On Fri, Apr 13, 2012 at 11:47, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
>>>> How can I kill the broken cp operation ?
>>> killall -s SIGKILL cp
>> This might not work always. I have faced similar issues with processes
>> waiting to access a filesystem over the network. In these cases if there
>> is a problem with the network it might get into an UNINTERRUPTIBLE SLEEP
>> since it is waiting for I/O. The only way to get rid of these processes
>> is to wait or reboot. In my case this was a tape drive over a network
>> filesystem.
>>
>> The OP can check if this is indeed the case by doing
>>
>> $ ps uf
>>
>> If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE of the
>> process should be D. If not then you can ignore my comment.
>>
> What happens if you ifdown the nic (if you are on the console
> obviously)? Would that allow the cif mount and/or the cp to become
> available for umount/kill?
That is a good question. I don't know what would happen then. I guess if
the filesystem implementation is smart enough to return an error when
the network goes down, then the I/O wait is over and the application
gets file read error of some kind and "wakes up" from its
UNINTERRUPTIBLE SLEEP. But then, this is just a hypothesis which I
cannot test (I do not have admin privileges to test this).
--
Suvayu
Open source is the future. It sets us free.
Thanks for your help
I will try all the suggestions next time, including disabling the NIC
to see if it free's the CP or allows umount ?
--
Andrew Gray <andrewg(a)linnetsol.co.uk>
Linnet Solutions Ltd
8:59 a.m.
On Fri, Apr 13, 2012 at 15:22, Kevin Martin <kevintm(a)ameritech.net> wrote:
On 04/13/2012 05:55 AM, suvayu ali wrote:
> On Fri, Apr 13, 2012 at 11:47, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>>> How can I kill the broken cp operation ?
>> killall -s SIGKILL cp
> This might not work always. I have faced similar issues with processes
> waiting to access a filesystem over the network. In these cases if there
> is a problem with the network it might get into an UNINTERRUPTIBLE SLEEP
> since it is waiting for I/O. The only way to get rid of these processes
> is to wait or reboot. In my case this was a tape drive over a network
> filesystem.
>
> The OP can check if this is indeed the case by doing
>
> $ ps uf
>
> If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE of the
> process should be D. If not then you can ignore my comment.
>
What happens if you ifdown the nic (if you are on the console
obviously)? Would that allow the cif mount and/or the cp to become
available for umount/kill?
That is a good question. I don't know what would happen then. I guess if
the filesystem implementation is smart enough to return an error when
the network goes down, then the I/O wait is over and the application
gets file read error of some kind and "wakes up" from its
UNINTERRUPTIBLE SLEEP. But then, this is just a hypothesis which I
cannot test (I do not have admin privileges to test this).
--
Suvayu
Open source is the future. It sets us free.
8:22 a.m.
On 04/13/2012 05:55 AM, suvayu ali wrote:
On Fri, Apr 13, 2012 at 11:47, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>> How can I kill the broken cp operation ?
> killall -s SIGKILL cp
This might not work always. I have faced similar issues with processes
waiting to access a filesystem over the network. In these cases if there
is a problem with the network it might get into an UNINTERRUPTIBLE SLEEP
since it is waiting for I/O. The only way to get rid of these processes
is to wait or reboot. In my case this was a tape drive over a network
filesystem.
The OP can check if this is indeed the case by doing
$ ps uf
If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE of the
process should be D. If not then you can ignore my comment.
What happens if you ifdown the nic (if you are on the console obviously)? Would
that allow the cif mount and/or the cp to become
available for umount/kill?
Kevin
5:55 a.m.
On Fri, Apr 13, 2012 at 11:47, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> How can I kill the broken cp operation ?
killall -s SIGKILL cp
This might not work always. I have faced similar issues with processes
waiting to access a filesystem over the network. In these cases if there
is a problem with the network it might get into an UNINTERRUPTIBLE SLEEP
since it is waiting for I/O. The only way to get rid of these processes
is to wait or reboot. In my case this was a tape drive over a network
filesystem.
The OP can check if this is indeed the case by doing
$ ps uf
If the "cp" process is in UNINTERRUPTIBLE SLEEP, the STATE of the
process should be D. If not then you can ignore my comment.
--
Suvayu
Open source is the future. It sets us free.
4:47 a.m.
Am 13.04.2012 11:43, schrieb Andrew Gray:
Hi
Fedora 16 x86_64 Kernel 3.3.1-3.fc16.x86_64 #1 SMP
I have cif mount over a VPN to a remote windows share which I have a
local
"cp -fLruv" to.
If this "cp -fLruv" hangs because a VPN problem broke the connection
temporarily. I can't kill the CP and the system won't restart due to the
CIF mount which it can't umount as it is busy with the hung cp
operation !
I have you manually hit reset to get it back!!
How can I kill the broken cp operation ?
killall -s SIGKILL cp
6:50 a.m.
Amazing. Not in a good way.
The corruption would be at the client end, correct?
Is there a reason that the client could not just report back
"taking to long to mount" and leave its data uncorrupted?
Would similar corruption take place if the process had just
termintated itself without waiting for NFS to succeed?
With properly written apps NFS soft and intr etc are all fine. The
problem is that a lot of apps are badly written and don't check for short
writes to disk or for close() erroring.
Same apps that break on disk full.
Alan
4425
days inactive
4428
days old
37 comments
15 participants
participants (15)
-
Alan Cox -
Andrew Gray -
Andy Blanchard -
Ed Greshko -
Hal -
jdow -
Joe Zeff -
Kevin Martin -
Michael Hennebry -
My Usenet -
Patrick O'Callaghan -
Reindl Harald -
Shane -
Suvayu Ali -
Tom Horsley