Lately, I've been noticing that I cannot do a df command, it just
hangs. Then I did a truss on the pid of df and noticed:

statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
NFS server boc-ps3.daleen.com not responding still trying
^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
/home/boca/tstamford/mnt: 

Then I did a fuser to see who is using the file and the results are
above. My question is, how to do I remove this stale mount point w/o
rebooting the server?
I have restarted all the rpc services but that didn't help. Thanks in
advance.

Doggy
Solaris 8 on E5500.

Doggy <tru64dog@yahoo.com> wrote:
> Lately, I've been noticing that I cannot do a df command, it just
> hangs. Then I did a truss on the pid of df and noticed:

> statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
> NFS server boc-ps3.daleen.com not responding still trying
> ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
> /home/boca/tstamford/mnt: 

> Then I did a fuser to see who is using the file and the results are
> above. My question is, how to do I remove this stale mount point w/o
> rebooting the server?

Most of the time a 'umount' should work.  Does it?

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

In article <18239c3a.0404270245.32dcabb3@posting.google.com>,
 tru64dog@yahoo.com (Doggy) wrote:

> Lately, I've been noticing that I cannot do a df command, it just
> hangs. Then I did a truss on the pid of df and noticed:
> 
> statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
> NFS server boc-ps3.daleen.com not responding still trying
> ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
> /home/boca/tstamford/mnt: 
> 

Ah..."/home" and fuser shows nothing...the automounter is in play here. 
fuser won't show nfs as it's a kernel process.

You could try stopping and restarting the automounter, but I don't think 
that would help too much, and it might cause some unexpected 
side-effects.

The only sure way to remove a stale nfs mount is to reboot; it might be 
possible to mount it somewhere else, but where the NFS server isn't 
responding, I don't think that will do much good. There's an outside 
chance that a umount -f *might* work, then the automounter will try to 
pick it up again. I wouldn't hold my breath on it, though.

-- 
Ken

Real address krgray*at*verizon*dot*net

On 27 Apr 2004 03:45:18 -0700
tru64dog@yahoo.com (Doggy) wrote:

> Lately, I've been noticing that I cannot do a df command, it just
> hangs. Then I did a truss on the pid of df and noticed:
> 
> statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
> NFS server boc-ps3.daleen.com not responding still trying
> ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
> /home/boca/tstamford/mnt: 
> 
> Then I did a fuser to see who is using the file and the results are
> above. My question is, how to do I remove this stale mount point w/o
> rebooting the server?
> I have restarted all the rpc services but that didn't help. Thanks in
> advance.
> 

umount /mount/point should clear it when no program has something open
from inside it.
Otherwise, umount -f /mount/point will forcible umount it anyway.
However this leaves the mount point in the busy state, you have to
remove it and recreate it, rmdir, mkdir firste before you can use it
again.


-- 
Barbie - Prayers are like junkmail for Jesus

I have seen things you lusers would not believe.
I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last
week. Time to die.

Try umount -f /home/boca/tstamford/mnt

assuming the above path is the mount point.


tru64dog@yahoo.com (Doggy) wrote in message news:<18239c3a.0404270245.32dcabb3@posting.google.com>...
> Lately, I've been noticing that I cannot do a df command, it just
> hangs. Then I did a truss on the pid of df and noticed:
> 
> statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
> NFS server boc-ps3.daleen.com not responding still trying
> ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
> /home/boca/tstamford/mnt: 
> 
> Then I did a fuser to see who is using the file and the results are
> above. My question is, how to do I remove this stale mount point w/o
> rebooting the server?
> I have restarted all the rpc services but that didn't help. Thanks in
> advance.
> 
> Doggy
> Solaris 8 on E5500.

Darren Dunham <ddunham@redwood.taos.com> wrote in message news:<Jwujc.41626$W54.11442@newssvr29.news.prodigy.com>...
> Doggy <tru64dog@yahoo.com> wrote:
> > Lately, I've been noticing that I cannot do a df command, it just
> > hangs. Then I did a truss on the pid of df and noticed:
>  
> > statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
> > NFS server boc-ps3.daleen.com not responding still trying
> > ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
> > /home/boca/tstamford/mnt: 
>  
> > Then I did a fuser to see who is using the file and the results are
> > above. My question is, how to do I remove this stale mount point w/o
> > rebooting the server?
> 
> Most of the time a 'umount' should work.  Does it?

didn't work this time, I fixed it by going into the /etc/mnttab file
and removing the stale point, then I restarted all rpc services.
Thanks.
Doggy...

Doggy <tru64dog@yahoo.com> wrote:
> Darren Dunham <ddunham@redwood.taos.com> wrote in message news:<Jwujc.41626$W54.11442@newssvr29.news.prodigy.com>...
>> Doggy <tru64dog@yahoo.com> wrote:
>> > Lately, I've been noticing that I cannot do a df command, it just
>> > hangs. Then I did a truss on the pid of df and noticed:
>>  
>> > statvfs64("/home/boca/tstamford/mnt", 0xFFBEFC58) (sleeping...)
>> > NFS server boc-ps3.daleen.com not responding still trying
>> > ^Cdtie5500 # fuser -cu /home/boca/tstamford/mnt
>> > /home/boca/tstamford/mnt: 
>>  
>> > Then I did a fuser to see who is using the file and the results are
>> > above. My question is, how to do I remove this stale mount point w/o
>> > rebooting the server?
>> 
>> Most of the time a 'umount' should work.  Does it?

> didn't work this time, I fixed it by going into the /etc/mnttab file
> and removing the stale point, then I restarted all rpc services.
> Thanks.
> Doggy...

*blink* *blink*... On Solaris 8?

/etc/mnttab isn't a regular file on that version of Solaris, and you
shouldn't be able to modify it, not even as root...

# echo "new line" >> /etc/mnttab
/etc/mnttab: cannot create
# uname -r
5.8
# df -k -F mntfs
Filesystem            kbytes    used   avail capacity  Mounted on
mnttab                     0       0       0     0%    /etc/mnttab


-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Doggy wrote:

> 
> didn't work this time, I fixed it by going into the /etc/mnttab file
> and removing the stale point,

No you didn't.  Not if you're really running Solaris 8.


-- 
Tony

"Tony Walton" <tony.walton@s_u_n.com> wrote in message
news:408FC970.1030203@s_u_n.com...
> Doggy wrote:
>
> >
> > didn't work this time, I fixed it by going into the /etc/mnttab file
> > and removing the stale point,
>
> No you didn't.  Not if you're really running Solaris 8.
>
>

Blimey! I just checked my /etc/mnttab on Solaris 8 and it is definately
text!

proteus# file mnttab
mnttab:         ascii text
proteus# uname -a
SunOS proteus 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-Enterprise

Mark <mark.wooldridge@camnospamcon.co.uk> wrote:
>> >
>> > didn't work this time, I fixed it by going into the /etc/mnttab file
>> > and removing the stale point,
>>
>> No you didn't.  Not if you're really running Solaris 8.

> Blimey! I just checked my /etc/mnttab on Solaris 8 and it is definately
> text!

> proteus# file mnttab
> mnttab:         ascii text
> proteus# uname -a
> SunOS proteus 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-Enterprise

You can read it, and yes it contains ascii text.  You cannot
directly modify the "file".

# file /etc/mnttab
/etc/mnttab:    ascii text
# uname -r
5.8
# echo "foo" > /etc/mnttab
/etc/mnttab: cannot create
# df -k -F mntfs
Filesystem            kbytes    used   avail capacity  Mounted on
mnttab                     0       0       0     0%    /etc/mnttab

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Wed, 28 Apr 2004, Mark wrote:

> Blimey! I just checked my /etc/mnttab on Solaris 8 and it is definately
> text!

Yes, but it's not a real text file.  From the mnttab man page:

	rich@zaphod5588# man mnttab

	File Formats                                            mnttab(4)

	NAME
		 mnttab - mounted file system table

	DESCRIPTION
		 The file /etc/mnttab is really a file system  that  provides
		 read-only  access  to  the table of mounted file systems for
		 the current host...

'Nuff said!

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Mark wrote:
 > "Tony Walton" <tony.walton@s_u_n.com> wrote in message
 > news:408FC970.1030203@s_u_n.com...
 >
 >> Doggy wrote:
 >>
 >>
 >>> didn't work this time, I fixed it by going into the /etc/mnttab
 >>> file and removing the stale point,
 >>
 >> No you didn't.  Not if you're really running Solaris 8.
 >>
 >>
 >
 >
 > Blimey! I just checked my /etc/mnttab on Solaris 8 and it is
 > definately text!
 >
 > proteus# file mnttab mnttab:         ascii text


It *looks* like ASCII text. In fact it *is* ASCII text.  But it isn't a
file.

mnttab on /etc/mnttab type mntfs read/write/setuid/dev=43c0000 on Wed
Mar 24 10:18:37 2004

The mntfs filesystem type looks at the actual mount information in the
kernel and presents it as ASCII text in real time.  However you can't
edit it, you can't remove it, you can't over-write it, you can't, in
fact, manipulate it in any way except indirectly by mounting or
unmounting something.

Attempt to write it with vi and:

"/etc/mnttab" Operation not applicable

Try to scribble over it from the command line:

# echo "I wear a black hat" > /etc/mnttab
/etc/mnttab: cannot create
#

How about removing it:

# rm /etc/mnttab
rm: /etc/mnttab: override protection 444 (yes/no)? y
rm: /etc/mnttab not removed: Device busy
#

(and that's unlink() failing, not some pattern-matching code in rm that
specifically refuses to rm that file).

And so on.

You could unmount it

# umount /etc/mnttab
#

And commands that used it would get confused:

# df
#

And you can mount it again:

# mount -F mntfs mnttab /etc/mnttab
# df
/                  (/dev/dsk/c0t0d0s0 ): 1376698 blocks   382085 files
/devices           (/devices          ):       0 blocks        0 files
/proc              (/proc             ):       0 blocks     7809 files
/dev/fd            (fd                ):       0 blocks        0 files
/var/run           (swap              ):  487424 blocks    45263 files
/tmp               (swap              ):  487424 blocks    45263 files
(and so on)

Why?  Having /etc/mnttab as an ASCII text file hanging about in the
filesystem was always asking for trouble. Things could write to it
completely asynchronously with respect to "real" mount requests
happening in the kernel; several mounts and/or unmounts happening
simultaneously could cause truncation and/or corruption of mnttab (there
was no mandatory locking protocol for making changes to the file), and
so on.

So mntfs avoids these by simply presenting mnttab as a "window" into the
real situation in the kernel moment-by-moment (and all the locking of
things is handled where it should be, in the kernel).

-- 
Tony

"Tony Walton" <tony.walton@s_u_n.com> wrote in message >

< lots of interesting explainations... >


Nice one Tony, and thanks for pointing that out.
Amazing, learn something new everyday.

Mark

"Mark" <mark.wooldridge@camNOSPAMcon.co.uk> wrote in message news:<4090d014$0$25325$ed9e5944@reading.news.pipex.net>...
> "Tony Walton" <tony.walton@s_u_n.com> wrote in message >
> 
> < lots of interesting explainations... >
> 
> 
> Nice one Tony, and thanks for pointing that out.
> Amazing, learn something new everyday.
> 
> Mark

I'm the guy that started this thread and fixed it. By the way, It was
Solaris 7, sorry--my bad.

Doggy

Barbie LeVile <barbie@gods-inc.de> wrote:
> umount /mount/point should clear it when no program has something open
> from inside it.
> Otherwise, umount -f /mount/point will forcible umount it anyway.
> However this leaves the mount point in the busy state, you have to
> remove it and recreate it, rmdir, mkdir firste before you can use it
> again.

Is this true?  I just did a SAN migration and had to umount -F
a few filesystems on the EMC and re-mounted without doing any
of the above.

Doggy wrote:

> Then I did a fuser to see who is using the file and the results are
> above. My question is, how to do I remove this stale mount point w/o
> rebooting the server?

Check all processes and kill anything that *might* be using it.
I have had that problem on our Solaris 7 server several times,
with fuser showing nothing, and most of the time there were
connections (pop3d, imapd, sshd) from users with home directories in the
stale filesystem.  Those were kind of obvious to kill, but
I've also had to kill ftpd processes that should have nothing
to do with those filesystems.