Bug 1283939

(In reply to Petter Reinholdtsen from comment #0)
> Description of problem:
> 
> We use autofs to automatically make NFS mounts available, but run into a
> problem
> with the autofs clients when adding new NFS export points on the NFS server.
> The clients do not discover the new mount points before we restart autofs,
> either
> using 'service autofs restart' or by rebooting the client.
> 
> We use the /net/<hostname>/ directory on the client, and only those exports
> that were visible when autofs was started or restarted show up there.

Originally these mounts didn't pick up new mounts at all.

I did work on this a while back but I can't remember the details.
It may be that automount(8) needs to be sent a HUP signal to update
the mounts but you shouldn't need to restart or reboot for simple
mount tree changes.

In any case updating the mount tree topology can easily cause
unrecoverable problems if you change the topology of the mount
tree in ways introduce dependencies between mounts that are in
use and it may be possible to introduce problems, in some cases,
when the dependent mounts aren't even in use.

That's the reasoning behind the behaviour your seeing.

> 
> As far as I can remember, the Solaris autofs system would discover new
> exports without manual intervention.  Why isn't the Redhat autofs
> automatically discovering new mount points?

See above.

> 
> As we do not have a complete list of all clients, it is not practical to
> restart autofs on all clients whenever one of the NFS servers get a new
> export.

Understood.

> 
> Are we using the wrong configuration?  We have not really touched the autofs
> configuration.

I don't think so.

I'll have a look through the hosts map code and let you know
what I believe the current situation is and we can work from
that.

Ian

(In reply to Ian Kent from comment #2)
> (In reply to Petter Reinholdtsen from comment #0)
> > Description of problem:
> > 
> > We use autofs to automatically make NFS mounts available, but run into a
> > problem
> > with the autofs clients when adding new NFS export points on the NFS server.
> > The clients do not discover the new mount points before we restart autofs,
> > either
> > using 'service autofs restart' or by rebooting the client.
> > 
> > We use the /net/<hostname>/ directory on the client, and only those exports
> > that were visible when autofs was started or restarted show up there.

Can you tell me which mechanism your using in the master map
for this, the internal -hosts option to /net or the auto.net
script?

snip ...

> > 
> > Are we using the wrong configuration?  We have not really touched the autofs
> > configuration.
> 
> I don't think so.
> 
> I'll have a look through the hosts map code and let you know
> what I believe the current situation is and we can work from
> that.

I'm not sure where to start in describing the problem, it's
got a number of facets that aren't straight forward but let
me try with an example.

First, when an export is not currently known the kernel won't
call back to the daemon so the daemon has no way to know the
export list might need updating.

That's the case in the kernel for a couple of reasons but one
of them can be used to explain one of the problems we have with
recognising newly added exports.

Suppose that on server server1 you have the exports:
/exports/apps
/exports/apps/myapp

then autofs will use a map entry like:
server1    /apps       server1:/exports/apps \
           /apps/myapp server1:/exports/apps/myapp

When /net/server1/apps is accessed the NFS share
server1:/exports/apps is mounted over /net/server1/apps and
directories within it are no longer within an autofs file
system so the daemon will not get call backs when directories
within this mount are accessed.

What autofs does in order to get called back to mount
/net/server1/apps/myapp is to mount what it calls an offset
trigger on /net/server1/apps/myapp so that it does get a call
back and can perform the mount.

So, if the offset isn't already known an offset trigger can't
be mounted.

The situation gets more complicated if the NFS export is itself
set to handle automounting when crossing mount points. This
is handled by NFS and not autofs.

So the point is, if the export is not already known the
automount(8) daemon won't get called back and won't be able to
update the export list unless it is told to and a HUP signal is
currently used to do that.

I'm not going to try and describe the difficulties that would
be encountered wrt. updating the map (and possibly file system
mount point paths) while the kernel is walking the path of a
non-existent offset mount (an added export in this case) which
are significant. It presents a chicken before the egg situation
and has been a problem for autofs in various ways over a long time.

So I'm not really sure that I can do anything to help with this
other than to say a HUP signal to the daemon on the client is
needed to update the exports list of a hosts mount.

Ian

(In reply to Ian Kent from comment #3)
> 
> Suppose that on server server1 you have the exports:
> /exports/apps
> /exports/apps/myapp
> 
> then autofs will use a map entry like:
> server1    /apps       server1:/exports/apps \
>            /apps/myapp server1:/exports/apps/myapp

Ha, that's not actually correct.

The map entry would be:
server1    /exports/apps       server1:/exports/apps \
           /exports/apps/myapp server1:/exports/apps/myapp

> Can you tell me which mechanism your using in the master map
> for this, the internal -hosts option to /net or the auto.net
> script?

We use the default autofs setup in RHEL 6 for this.  We have not modified the
configuration at all, and use symlinks into /net/ to avoid having to modify
the autofs setup.

-- 
Happy hacking
Petter Reinholdtsen

(In reply to Petter Reinholdtsen from comment #6)
> > Can you tell me which mechanism your using in the master map
> > for this, the internal -hosts option to /net or the auto.net
> > script?
> 
> We use the default autofs setup in RHEL 6 for this.  We have not modified the
> configuration at all, and use symlinks into /net/ to avoid having to modify
> the autofs setup.

IIRC autofs version 5 was available from RHEL-6 GA so the default
would be the internal -hosts map.

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/