From: Mike Marion <mmarion@qualcomm.com>
To: "autofs@linux.kernel.org" <autofs@linux.kernel.org>
Subject: Re: 5.0.5 non-expiring mounts
Date: Mon, 14 Feb 2011 17:10:38 -0800 [thread overview]
Message-ID: <20110215011037.GT27735@sunapee.qualcomm.com> (raw)
In-Reply-To: <4D510D53.7010507@gmail.com>
On Tue, Feb 08, 2011 at 01:30:59AM -0800, Philip Ong Jr. wrote:
> I've set the logging level to debug and can see messages of expiring
> mounts in /var/log/messages...but when I check /etc/mtab or /proc/mounts
> or df, i can still see them there. Any ideas if this is a known issue or
> if I can give more info than below?
Out of curiosity... are these direct or indirect mounts? We're seeing an
issue where our huge maps served from LDAP are seeing indirects not umounting
while logging expires just fine, but the direct maps are working great. I
believe a co-worker has replicated this exact same behavior with local files
based maps too though, so pretty sure it's not really related to LDAP at all,
but we've found using LDAP helped clear out a lot of old issues we had a few
years ago related to the hashing bits.
I've even done network sniffing while doing a kill -USR1 and the automount
daemon opens new sockets for each indirect (our homedirs) path it wants to
expire, but there never is any actual network traffic sent across the wire.
Even better, the sockets stay stuck in ESTABLISHED for a long time. Some more
USR1/expires and/or HUPs can help clear is, or I just run a script that does
an fuser then umount on unused homedirs and that flushes the ports out. When
the ports pile up to >300 or so, you start getting NFS failures with syslog
showing "couldn't read superblock."
Oh, and when I say huge maps.. I mean it. We're >10k direct mounts and I don't
know how many indirect mounts, but it's even more then that.
--
Mike Marion-Unix SysAdmin/Staff IT Engineer-http://www.qualcomm.com
Antonio: "It's no fair. Some men drink deep from the fountain of life, while
Antonio takes one sip and it goes down the wrong pipe!"
next prev parent reply other threads:[~2011-02-15 1:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 9:30 5.0.5 non-expiring mounts Philip Ong Jr.
2011-02-11 3:10 ` Ian Kent
2011-02-15 1:10 ` Mike Marion [this message]
2011-02-15 3:11 ` Ian Kent
2011-02-15 3:37 ` Ian Kent
2011-02-15 5:28 ` Mike Marion
2011-02-15 12:28 ` Ian Kent
2011-02-15 18:11 ` Leonardo Chiquitto
2011-02-16 7:08 ` Ian Kent
2011-02-16 12:18 ` Ian Kent
2011-02-23 20:22 ` Leonardo Chiquitto
2011-02-16 12:58 ` Leonardo Chiquitto
2011-03-04 20:10 ` Leonardo Chiquitto
2011-03-05 5:18 ` Ian Kent
2011-03-24 22:03 ` Leonardo Chiquitto
2011-03-28 3:17 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2011-02-17 1:08 Deke Clinger
2011-02-17 7:57 ` Ian Kent
2011-02-17 19:21 Deke Clinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110215011037.GT27735@sunapee.qualcomm.com \
--to=mmarion@qualcomm.com \
--cc=autofs@linux.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.