Re: [autofs] Bug in autofs4_d_automount()?
On Sat, 2011-06-18 at 00:29 +0100, David Howells wrote: Hi Ian, At the top of autofs4_d_automount() you have: /* The daemon never triggers a mount. */ if (autofs4_oz_mode(sbi)) return NULL; I think this should be returning -EISDIR. If by some chance we do get here in Oz mode, this will cause the kernel to just loop forever. A return of NULL is meant to indicate that you got a collision and that it should recheck the mountpoint - but it does not advance path in follow_managed(). I think your mistaken this time. That was done to work around the fact that -EISDIR can't be returned in the case where the dentry doesn't and (and won't have) a explicit mount on it without entering an ELOOP situation. IIRC I needed to return NULL here and handle it in -d_manage() to make this work. -EISDIR is the return to indicate this is to be treated as a normal directory. That would be the better way to do it but the logic doesn't allow it ATM. David ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH] AUTOFS4: Fix the return from autofs4_d_automount() and simplify autofs4_d_manage()
On Sat, 2011-06-18 at 01:11 +0100, David Howells wrote:
autofs4_d_automount() returns 0 if it detects that the calling process is in
Oz
mode (ie. it's the autofs userspace daemon). This return, however, is meant
to
indicate to follow_automount() that the caller should retry the check on the
the current path point. In the Oz mode case, this is a bad idea because
nothing has changed on the path, and follow_managed() will just repeat until
follow_automount() hits the total_link_count limit and returns -ELOOP.
What it should do is return -EISDIR to indicate to the callers that actually
it
wants the daemon to see this directory as an ordinary directory.
No, not unless the check below can be changed to somehow not trigger
when LOOKUP_CONTINUE is set for autofs automount dentrys that don't
actually end up with a mount on them, but are automount triggers never
the less:
if (PTR_ERR(mnt) == -EISDIR (flags LOOKUP_CONTINUE))
return -EREMOTE;
return PTR_ERR(mnt);
Fact is in our discussions on this we could never reach agreement so I
worked around it by breaking out of the follow_managed() loop using
-d_managed() instead, thinking that the above check must remain to
satisfy the needs of other kernel users.
Now, given that change outlined above, it is then unnecessary for
autofs4_d_manage() to return -EISDIR if the current path point is not a
mountpoint. If it returns 0 instead, and the path point isn't a mountpoint,
then follow_managed() will skip the attempt to transit to the mounted
filesystem and proceed to call autofs4_d_automount(), which will return
-EISDIR.
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/autofs4/root.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index f55ae23..a6dc11c 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -334,7 +334,7 @@ static struct vfsmount *autofs4_d_automount(struct path
*path)
/* The daemon never triggers a mount. */
if (autofs4_oz_mode(sbi))
- return NULL;
+ return ERR_PTR(-EISDIR);
/*
* If an expire request is pending everyone must wait.
@@ -435,13 +435,8 @@ int autofs4_d_manage(struct dentry *dentry, bool
rcu_walk)
dentry, dentry-d_name.len, dentry-d_name.name);
/* The daemon never waits. */
- if (autofs4_oz_mode(sbi)) {
- if (rcu_walk)
- return 0;
- if (!d_mountpoint(dentry))
- return -EISDIR;
+ if (autofs4_oz_mode(sbi))
return 0;
- }
/* We need to sleep, so we need pathwalk to be in ref-mode */
if (rcu_walk)
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Odd NIS map failure with mount point creation time in the future?
On Fri, 2011-06-17 at 15:12 +0100, James Pearson wrote: I using CentOS 5 on a large number of boxes with a NIS indirect automount map. I've been using the following syntax in /etc/auto.master: /mntpointyp:custom.map And this has worked fine for ages Recently, I wanted to provide some custom local overrides to mount points in the NIS map, so I've changed /etc/auto.master to be: /mntpointcustom.map and created a file called /etc/custom.map which contains something like: host1host:/disk1 +custom.map i.e. include the NIS map after any local mount point settings On most machines, this works fine - but on a number of machines, after a reboot, the mounts from the NIS map fail to mount - although the other mounts from /etc/custom.map mount fine. One thing I noticed in common on all the machines with this problem is that datestamp on the automount mount point (/mntpoint) was in the future - by an hour or two. I guess the hardware clock is an hour or two ahead of the real time. ntp runs on all these boxes - but starts after autofs - however if I change ntp to startup before autofs, then autofs works fine after a reboot ... Any idea why autofs fails to read entries from the included NIS map when the creation date of the map mount point is in the future? - but works fine when the same NIS map is referenced directly from /etc/auto.master? Don't know about the timestamp but there were some included map fixes in RHEL-5.7, at least one was a fix for a regression. Versions? James Pearson ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] nesting automount maps in ldap
On Fri, 2011-06-17 at 10:40 -0400, Jimmy Dorff wrote: Hello, I'm attempting to migrate an existing (and working) nis automount system to ldap. We have several layers of nested maps and I'm attempting to recreate that in LDAP. # Automount master for /foo dn: cn=/foo, ou=auto.master,dc=phy,dc=duke,dc=edu objectClass: automount cn: /foo automountInformation: ldap ldapserver:ou=auto.phy,dc=phy,dc=duke,dc=edu dn: ou=auto.phy, dc=phy,dc=duke,dc=edu objectClass: top objectClass: automountMap ou: auto.phy # mounting /foo/web works great! dn: cn=web, ou=auto.phy, dc=phy,dc=duke,dc=edu objectClass: automount cn: web automountInformation: -fstype=nfs nfsserver01:/srv/httpd # here is my attempt at nesting another level dn: cn=project, ou=auto.phy,dc=phy,dc=duke,dc=edu objectClass: automount cn: project automountInformation: ldap ldapserver:ou=auto.project,dc=phy,dc=duke,dc=edu I'm not sure about using this older syntax. Even if it is correct and we find a bug with it I'd be inclined to recommend using the newer syntax if possible. That would be (IIRC): automountInformation: ldap://ldapserver/ou=auto.project,dc=phy,dc=duke,dc=edu # This fails. I get automount: failed to mount /foo/project dn: ou=auto.project, dc=phy,dc=duke,dc=edu objectClass: top objectClass: automountMap ou: auto.project # this never shows up (ghosting enabled) dn: cn=linux, ou=auto.project, dc=phy,dc=duke,dc=edu objectClass: automount cn: linux automountInformation: -fstype=nfs nfsserver02:/srv/linux I can't see to find an example of nest ldap maps. I'm using autofs-5.0.5-31.el6 if that makes any difference. Log a RHEL bug (you probably should go via support actually) and include a full debug log. That is set LOGGING=debug in /etc/sysconfig/autofs and ensure that daemon.* output is being captured by syslog. Thanks! Jimmy Dorff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] nesting automount maps in ldap
On Fri, 2011-06-17 at 16:40 -0400, Jimmy Dorff wrote: On 06/17/2011 10:40 AM, Jimmy Dorff wrote: # here is my attempt at nesting another level dn: cn=project, ou=auto.phy,dc=phy,dc=duke,dc=edu objectClass: automount cn: project automountInformation: ldap ldapserver:ou=auto.project,dc=phy,dc=duke,dc=edu My problem was the lack of -fstype=autofs. Oh .. yeah, that may well be it, but that should have been needed in the original map. Maybe a look at a debug log would be useful and that should show pretty quickly if it is just the missing fstype option. This works: dn: cn=project,ou=auto.phy,dc=phy,dc=duke,dc=edu objectClass: automount cn: project automountInformation: -fstype=autofs ou=auto.project,dc=phy,dc=duke,dc=edu I also think this is called layering rather than nesting.. but I'm not sure. Maybe, but the terminology I've always used for these is submount, as in a sub autofs mount. Ian ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Odd NIS map failure with mount point creation time in the future?
Ian Kent wrote: Any idea why autofs fails to read entries from the included NIS map when the creation date of the map mount point is in the future? - but works fine when the same NIS map is referenced directly from /etc/auto.master? Don't know about the timestamp but there were some included map fixes in RHEL-5.7, at least one was a fix for a regression. Versions? Sorry, I should have said - this is CentOS 5.5 with autofs 5.0.1-0.rc2.143.el5_5.6 - and I've also tried it with 5.0.1-0.rc2.143.el5_6.2 - with the same result. It is easy to reproduce - with an included NIS map - if I do: /etc/init.d/autofs stop; date -s 1 minute; /etc/init.d/autofs start; date -s -1 minute This creates the automount mount point 1 minute into the future. Then if I try to access a server defined in the NIS map, the mount fails. However, if I wait a minute (i.e until the system clock passes the date stamp of the mount point), the automount of file systems in the NIS map works fine. Is it possible to get a copy of the autofs RPM for RHEL-5.7 to test? Thanks James Pearson ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Odd NIS map failure with mount point creation time in the future?
On Sat, 2011-06-18 at 21:08 +0100, James Pearson wrote:
James Pearson wrote:
Sorry, I should have said - this is CentOS 5.5 with autofs
5.0.1-0.rc2.143.el5_5.6 - and I've also tried it with
5.0.1-0.rc2.143.el5_6.2 - with the same result.
It is easy to reproduce - with an included NIS map - if I do:
/etc/init.d/autofs stop; date -s 1 minute; /etc/init.d/autofs start;
date -s -1 minute
This creates the automount mount point 1 minute into the future.
Then if I try to access a server defined in the NIS map, the mount fails.
However, if I wait a minute (i.e until the system clock passes the date
stamp of the mount point), the automount of file systems in the NIS map
works fine.
Is it possible to get a copy of the autofs RPM for RHEL-5.7 to test?
I had a look at the RHEL5 5.0.1-0.rc2.143.el5_6.2 source - and the
following patch appears to 'fix' my problem - it's a bit of a hack - as
in the included NIS map case, it just resets the age of the map to
'now', if it is in the future.
James Pearson
plain text document attachment (autofs-5.0.1-future.patch)
--- ./daemon/lookup.c.mpc 2011-06-18 20:04:51.076507000 +0100
+++ ./daemon/lookup.c 2011-06-18 20:52:18.436154033 +0100
@@ -848,6 +848,12 @@ int lookup_nss_mount(struct autofs_point
struct map_source *map;
enum nsswitch_status status;
int result = 0;
+ time_t now = time(NULL);
+
+ if (entry-age now) {
+ debug(ap-logopt, map %s age in the future - changing it to
now, entry-path);
+ entry-age = now;
+ }
/*
* For each map source (ie. each entry for the mount
That sounds a bit like bug
https://bugzilla.redhat.com/show_bug.cgi?id=632471
It was fixed in development revision 152, which I happen to have on
people.redhat.com. You could give that a try.
http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.152.el5/
Keep in mind that there were a few other fixes that went into the final
release version so your mileage may vary.
Ian
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
