From: Ian Kent <raven@themaw.net>
To: Greg Wooledge <wooledg@eeg.ccf.org>
Cc: autofs@linux.kernel.org
Subject: Re: How to reload /net "maps"
Date: Mon, 13 Sep 2010 09:27:18 +0800 [thread overview]
Message-ID: <1284341238.3027.2.camel@localhost> (raw)
In-Reply-To: <x49pqwm8z0c.fsf@segfault.boston.devel.redhat.com>
On Thu, 2010-09-09 at 16:04 -0400, Jeff Moyer wrote:
> Greg Wooledge <wooledg@eeg.ccf.org> writes:
>
> > Debian 5.0, autofs 4.1.4, kernel 2.6.26-2-686
>
> Very old autofs version. You should transition to version 5.
>
> > I may be overlooking some documentation, but I couldn't find out how to
> > do this. Occasionally one of our NFS servers adds a new entry to its
> > /etc/exports file, and we'd like the clients to be able to use it.
> >
> > The clients look like:
> >
> > # grep -v '^#' /etc/auto.master
> > /net /etc/auto.net
> >
> > At some point in the past, autofs will have contacted this host and
> > somehow "cached" the fact that it was sharing /home, /data, etc.
> > Now I've added /opt to the exports file. But when I do "ls /net/servername"
> > I still only see home and data, not opt.
>
> /etc/auto.net is a program map that returns a multimount entry. What
> that means is that once you traverse into the directory /net/servername,
> autofs no longer traps lookups (it does it for the initial mount, but
> that's it). You can get the new export to show up if you managed to get
> all applications out of that directory hierarchy, then forced automount
> to expire the mount, and then accessed it again.
>
> > Rebooting the client works -- after a reboot, I can see home, data and opt.
> >
> > I'm trying to find a way to get autofs to reload the server's list of
> > shared file systems without totally rebooting the client. If I issue
> > a "/etc/init.d/autofs reload" command, I get a few normal-looking messages,
> > but no change in the list of results. If I try "/etc/init.d/autofs restart"
> > it tell me it cannot stop the /net daemon, and cannot start a new one.
> > Manually attempting "kill PID" or "kill -HUP PID" has no visible effect.
>
> autofs version 5 may be better in this regard. I'll let Ian comment on
> whether what you want to work is expected to work.
We still can't change entries with possible hierarchic relationships
while they are in use in version 5, because of the potential
dependencies.
>
> Cheers,
> Jeff
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
prev parent reply other threads:[~2010-09-13 1:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 18:27 How to reload /net "maps" Greg Wooledge
2010-09-09 20:04 ` Jeff Moyer
2010-09-13 1:27 ` Ian Kent [this message]
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=1284341238.3027.2.camel@localhost \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=wooledg@eeg.ccf.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.