Prev: firefox and NSPlugin Wrapper (aka "flash")
Next: bash script
From: Grant on 23 May 2010 03:29
On Sun, 23 May 2010 00:37:19 +0100, The Natural Philosopher <tnp(a)invalid.invalid> wrote:

>Robert Heller wrote:
>> At Sat, 22 May 2010 13:41:47 +0000 (UTC) "James H. Markowitz" <noone(a)nowhere.net> wrote:
>>
>>> I have an NFS partition P mounted locally from a remote machine.
>>> The problem is that the remote machine has died. When I do
>>>
>>> umount -f P
>>>
>>> I get a diagnostic whereby somebody is still using P. I try to find out
>>> who by means of fuser, and fuser hangs, apparently forever.
>>>
>>> How can I get rid of P without rebooting my box?
>>
>> One of the (unfortunate) things about NFS is that it does not really
>> handle this situation well (never has). Once you start getting wedged
>> processes (often df's), the only solution is a reboot. OTOH, the hung
>> processes don't really consume much in the way of resources and there is
>> little chance of system breakage, so you can take your time and schedule
>> the reboot at some time that is otherwise least distruptive (like at 2am
>> or something).
>>
>
>Seconded in every respect.

Doesn't intr option in fstab stop and nfs mount from wedging?

I forget, been years since I've had an nfs mount crash so hard I had
to reboot a machine.

Grant.
--
http://bugs.id.au/
From: unruh on 23 May 2010 13:15
On 2010-05-23, Grant <omg(a)grrr.id.au> wrote:
> On Sun, 23 May 2010 00:37:19 +0100, The Natural Philosopher <tnp(a)invalid.invalid> wrote:
>
>>Robert Heller wrote:
>>> At Sat, 22 May 2010 13:41:47 +0000 (UTC) "James H. Markowitz" <noone(a)nowhere.net> wrote:
>>>
>>>> I have an NFS partition P mounted locally from a remote machine.
>>>> The problem is that the remote machine has died. When I do
>>>>
>>>> umount -f P
>>>>
>>>> I get a diagnostic whereby somebody is still using P. I try to find out
>>>> who by means of fuser, and fuser hangs, apparently forever.
>>>>
>>>> How can I get rid of P without rebooting my box?
>>>
>>> One of the (unfortunate) things about NFS is that it does not really
>>> handle this situation well (never has). Once you start getting wedged
>>> processes (often df's), the only solution is a reboot. OTOH, the hung
>>> processes don't really consume much in the way of resources and there is
>>> little chance of system breakage, so you can take your time and schedule
>>> the reboot at some time that is otherwise least distruptive (like at 2am
>>> or something).
>>>

This is not "crashing". Have an external machine from which you mount
a directory by nfs on your machines. cd into that directory.
Switch off that external machine, or
unplug its ethernet cable. It is now impossible to unmount the directory
on your local machine. df may well go into an eternal wait for the
output from that external machine. etc.
If you have some way of avoiding that, I at least would be extremely
grateful.
>>
>>Seconded in every respect.
>
> Doesn't intr option in fstab stop and nfs mount from wedging?
>
> I forget, been years since I've had an nfs mount crash so hard I had
> to reboot a machine.
>
> Grant.
From: Maxwell Lol on 23 May 2010 16:25
unruh <unruh(a)wormhole.physics.ubc.ca> writes:

>> for any command that might access the file descriptor on the remote
>> machine, run it in the background. (i.e. type & at the end of the
>> line).
>
> ??? Since almost any program could, that would essentially mean running
> all programs in background, including the ones from the gui.


Yes, any shell program COULD access the NFS mounted directory.

One of the things you can do to protect yourself is to minimize the
number of NFS-mounted directories in your searchpath. I suggest you
eliminate all of them.

I created a directory on the local system that had symlinks to the
remote executables on all of the remote servers. That way, my shell
only hangs when I executed a command on a remote server.

From: unruh on 23 May 2010 18:30
On 2010-05-23, Maxwell Lol <nospam(a)com.invalid> wrote:
> unruh <unruh(a)wormhole.physics.ubc.ca> writes:
>
>>> for any command that might access the file descriptor on the remote
>>> machine, run it in the background. (i.e. type & at the end of the
>>> line).
>>
>> ??? Since almost any program could, that would essentially mean running
>> all programs in background, including the ones from the gui.
>
>
> Yes, any shell program COULD access the NFS mounted directory.
>
> One of the things you can do to protect yourself is to minimize the
> number of NFS-mounted directories in your searchpath. I suggest you
> eliminate all of them.

This is absurd. Computers are here to help us, not to bend our behaviour
to their whims. If nfs refuses to unmount even when the remote end has
died, it is a bug in nfs. The purpose of nfs mounted drives is precisely
to have access to the files, and to run programs. Demanding that all
programs be run in the background (useless if the purpose of the program
is to produce console or gui output) or that nfs mounts not be in your
searchpath is simply idiotic.


>
> I created a directory on the local system that had symlinks to the
> remote executables on all of the remote servers. That way, my shell
> only hangs when I executed a command on a remote server.

And what do symlinks do for you. If you need something from the nfs
filesystem the symlink does not prevent the attempt to access the nfs
partition. Or the "in use" error.

>
From: Robert Heller on 23 May 2010 21:42
At Sun, 23 May 2010 22:30:13 GMT unruh <unruh(a)wormhole.physics.ubc.ca> wrote:

>
> On 2010-05-23, Maxwell Lol <nospam(a)com.invalid> wrote:
> > unruh <unruh(a)wormhole.physics.ubc.ca> writes:
> >
> >>> for any command that might access the file descriptor on the remote
> >>> machine, run it in the background. (i.e. type & at the end of the
> >>> line).
> >>
> >> ??? Since almost any program could, that would essentially mean running
> >> all programs in background, including the ones from the gui.
> >
> >
> > Yes, any shell program COULD access the NFS mounted directory.
> >
> > One of the things you can do to protect yourself is to minimize the
> > number of NFS-mounted directories in your searchpath. I suggest you
> > eliminate all of them.
>
> This is absurd. Computers are here to help us, not to bend our behaviour
> to their whims. If nfs refuses to unmount even when the remote end has
> died, it is a bug in nfs. The purpose of nfs mounted drives is precisely
> to have access to the files, and to run programs. Demanding that all
> programs be run in the background (useless if the purpose of the program
> is to produce console or gui output) or that nfs mounts not be in your
> searchpath is simply idiotic.

NFS works fine, so long as the NFS server is 'well armored' -- that is
the server needs to be a solidly reliable system. NFS does not work
well with a server system that might crash randomly or can be shutdown
on a whim. I would not use NFS for occasional access -- using scp or
some on-demand / as needed method is better.

>
>
> >
> > I created a directory on the local system that had symlinks to the
> > remote executables on all of the remote servers. That way, my shell
> > only hangs when I executed a command on a remote server.
>
> And what do symlinks do for you. If you need something from the nfs
> filesystem the symlink does not prevent the attempt to access the nfs
> partition. Or the "in use" error.
>
> >
>

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller(a)deepsoft.com -- Contract Programming: C/C++, Tcl/Tk


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: firefox and NSPlugin Wrapper (aka "flash")
Next: bash script