Re: [autofs] Before I start carving wheels....
Vincent Liggio writes: > On Tue, 22 Feb 2011, Lee Damon wrote: > >> Has anyone done the work to get am-utils to compile on RHEL 6? It seems the >> most recent autoconf tools don't like the contents of the 6.1.5 tarball. >> > I'm guessing it won't work even if you get it to compile. We've been > trying to get it to work with the F14 latest kernel, and it just won't > function (we were able to get it to work on F12, but autofs3 refuses > to work on the F14 kernel). The autofs maintainer (Ian Kent) tries to keep the v4 kernel module compatible with v3. However, if you don't report problems, they won't get fixed (most testing these days is with autofs version 5). > It performs horribly with nfs mode. Think it's time to move onto > supported technology unfortunately (autofs5 is no great shakes, we're > going to try autofs4). autofs4 isn't exactly supported technology either. You'd be moving from one dead-end to another. I've CC'd the autofs list. If you have suggestions and/or specific bugs, please let us know. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] How to reload /net "maps"
Greg Wooledge 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. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] debugging the automounter
"Philip Ong Jr." writes: > Are there any good links on how to go about setting up debugging the > automounter using the gdb? Debugging autofs version 4 with gdb is a tough proposition as many of the operations performed by the automounter involve forking off another process. We mostly rely on the debug logs for understanding aberrant behaviour. gdb is can be useful when we get a core file, though. > I’m running rhel3 and trying to figure out an automounter > problem. I’ve installed the debuginfo package so the binary won’t be > stripped. The list of things I ask for when trying to resolve bugs can be found here: http://people.redhat.com/jmoyer/ Look at the text under "Filing bug reports." Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter to dump maps
Ondrej Valousek writes: > Hi Ian / all, > > Is there any way to make automounter dump maps it sees? I was just > thinking about it - with files / NIS / program backend it is not much > needed but it could be quite helpful with ldap backend - restarting > automounter with verbose logging is not too practical in the > production environment. > > I would imagine either some small standalone program using autofs > internals which would dump all (or certain specified) maps or running > a second instance of autofs (with some parameter) which would not > mount anything and just dump the maps and exits. > > Is this a completely misplaced idea or is there a way to achieve this > functionality now? Well, back in the autofs4 days, when way too much logic was put into the init script, we basically had to do this. ;-) See the --dumpmap switch in v4. I can see that it could be a useful aid for administrators to ensure that their maps look like they think they do, especially with nsswitch and included maps, and those pesky null maps. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] make documentation for set-log-priority clearer
Hi, It is not apparent from the documentation of the --set-log-priority option that the option can be used to change the log priority of the damon while it is running. This patch tries to fix that. Cheers, Jeff Signed-off-by: Jeff Moyer diff --git a/man/automount.8 b/man/automount.8 index 9fcaaf4..d9a45c2 100644 --- a/man/automount.8 +++ b/man/automount.8 @@ -77,7 +77,9 @@ changes. For example, if verbose logging is set in the configuration then attempting to set logging to basic logging, by using alert, crit, err or emerg won't stop the verbose logging. However, setting logging to debug will lead to everything (debug logging) being logged witch can then also -be disabled, returning the daemon to verbose logging. +be disabled, returning the daemon to verbose logging. This option can be +specified to change the logging priority of an already running automount +process. .P The \fIpath\fP argument corresponds to the automounted path name as specified in the master map. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] a note on all the patches I just sent
Jeff Moyer writes: > These were a result of running clang against the autofs source tree. > See: > http://clang-analyzer.llvm.org/ > > If you want to run this against autofs, you'll have to make the attached > change to Makefile.rules. I've uploaded the output here: http://people.redhat.com/jmoyer/clang/2009-09-04-1/ Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] a note on all the patches I just sent
These were a result of running clang against the autofs source tree. See: http://clang-analyzer.llvm.org/ If you want to run this against autofs, you'll have to make the attached change to Makefile.rules. Cheers, Jeff diff --git a/Makefile.rules b/Makefile.rules index f2ba386..26da6d8 100644 --- a/Makefile.rules +++ b/Makefile.rules @@ -38,7 +38,7 @@ STRIP = strip --strip-debug endif endif -CC= gcc +# CC= gcc CXX = g++ CXXFLAGS = $(CFLAGS) LD= ld ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] lib/master.c: get rid of unused name variable
Hi, Ian,
Yet another trivial patch.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/lib/master.c b/lib/master.c
index e43f835..8455f40 100644
--- a/lib/master.c
+++ b/lib/master.c
@@ -152,7 +152,7 @@ master_add_map_source(struct master_mapent *entry,
{
struct map_source *source;
char *ntype, *nformat;
- const char **tmpargv, *name = NULL;
+ const char **tmpargv;
source = malloc(sizeof(struct map_source));
if (!source)
@@ -188,10 +188,6 @@ master_add_map_source(struct master_mapent *entry,
source->argc = argc;
source->argv = tmpargv;
- /* Can be NULL for "hosts" map */
- if (argv)
- name = argv[0];
-
master_source_writelock(entry);
if (!entry->maps)
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] sasl_choose_mech could return an uninitialized conn pointer
Hi, Ian,
If a server returns a set of mechanisms that all require authentication,
then the conn pointer is returned to the caller uninitialized. Fix
that.
Cheers,
Jeff
diff --git a/modules/cyrus-sasl.c b/modules/cyrus-sasl.c
index 4c6a671..806bf9f 100644
--- a/modules/cyrus-sasl.c
+++ b/modules/cyrus-sasl.c
@@ -798,7 +798,7 @@ sasl_bind_mech(unsigned logopt, LDAP *ldap, struct
lookup_context *ctxt, const c
sasl_conn_t *
sasl_choose_mech(unsigned logopt, LDAP *ldap, struct lookup_context *ctxt)
{
- sasl_conn_t *conn;
+ sasl_conn_t *conn = NULL;
int authenticated;
int i;
char **mechanisms;
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] autofs_sasl_dispose: ctxt is always valid
If ctxt wasn't valid, other things would explode wildly.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/modules/cyrus-sasl.c b/modules/cyrus-sasl.c
index 04001d0..4c6a671 100644
--- a/modules/cyrus-sasl.c
+++ b/modules/cyrus-sasl.c
@@ -922,7 +922,7 @@ void autofs_sasl_dispose(struct lookup_context *ctxt)
{
int status, ret;
- if (ctxt && ctxt->sasl_conn) {
+ if (ctxt->sasl_conn) {
sasl_dispose(&ctxt->sasl_conn);
ctxt->sasl_conn = NULL;
}
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] mount_autofs.c:mount_mount no need to increment val
No sense incrementing val since we never look at it again.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/modules/mount_autofs.c b/modules/mount_autofs.c
index afb1859..2a5d860 100644
--- a/modules/mount_autofs.c
+++ b/modules/mount_autofs.c
@@ -119,7 +119,7 @@ int mount_mount(struct autofs_point *ap, const char *root,
const char *name,
else if (strncmp(cp, "timeout=", 8) == 0) {
char *val = strchr(cp, '=');
unsigned tout;
- if (val++) {
+ if (val) {
int ret = sscanf(cp, "timeout=%u",
&tout);
if (ret)
timeout = tout;
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] expire_cleanup: check the return code form ops->askumount
Hi, Ian,
This looks like a minor oversight.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/daemon/state.c b/daemon/state.c
index 2eeb4bf..27bc6de 100644
--- a/daemon/state.c
+++ b/daemon/state.c
@@ -160,7 +160,7 @@ void expire_cleanup(void *arg)
* been signaled to shutdown.
*/
rv = ops->askumount(ap->logopt, ap->ioctlfd, &idle);
- if (!idle && !ap->shutdown) {
+ if (!rv && !idle && !ap->shutdown) {
next = ST_READY;
if (!ap->submount)
alarm_add(ap, ap->exp_runfreq);
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] daemon/direct.c: check the return code from stat(2)
Another trivial patch.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/daemon/direct.c b/daemon/direct.c
index 0c78627..9b4e57b 100644
--- a/daemon/direct.c
+++ b/daemon/direct.c
@@ -1245,7 +1245,7 @@ static void *do_mount_direct(void *arg)
}
status = stat(mt.name, &st);
- if (!S_ISDIR(st.st_mode) || st.st_dev != mt.dev) {
+ if (status != 0 || !S_ISDIR(st.st_mode) || st.st_dev != mt.dev) {
error(ap->logopt,
"direct trigger not valid or already mounted %s",
mt.name);
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] parse_sun.c: get rid of unused optlen variable
I couldn't find a reason to keep this around. We don't walk this options string, so it isn't used to make sure we don't walk off the end. So, get rid of it. Cheers, Jeff Signed-off-by: Jeff Moyer diff --git a/modules/parse_sun.c b/modules/parse_sun.c index db36ae2..921daf4 100644 --- a/modules/parse_sun.c +++ b/modules/parse_sun.c @@ -1334,7 +1334,7 @@ int parse_mount(struct autofs_point *ap, const char *name, char *pmapent, *options; const char *p; int mapent_len, rv = 0; - int optlen, cur_state; + int cur_state; int slashify = ctxt->slashify_colons; unsigned int append_options; @@ -1389,7 +1389,6 @@ int parse_mount(struct autofs_point *ap, const char *name, logerr(MODPREFIX "strdup: %s", estr); return 1; } - optlen = strlen(options); p = skipspace(pmapent); ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] Get rid of a bogus assignment in defaults_free_searchdns
tssia.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/lib/defaults.c b/lib/defaults.c
index 17164bd..0aafa8b 100644
--- a/lib/defaults.c
+++ b/lib/defaults.c
@@ -532,7 +532,6 @@ void defaults_free_searchdns(struct ldap_searchdn *sdn)
struct ldap_searchdn *this = sdn;
struct ldap_searchdn *next;
- next = this;
while (this) {
next = this->next;
free(this->basedn);
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] check the return code from ldap_parse_result
Hi, Ian,
Here's another trivialish patch. If ldap_parse_result returns anything
other than LDAP_SUCCESS, the values of the result pointers are
undefined.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/modules/lookup_ldap.c b/modules/lookup_ldap.c
index d0cbdca..33ca23e 100644
--- a/modules/lookup_ldap.c
+++ b/modules/lookup_ldap.c
@@ -2017,6 +2017,12 @@ do_paged:
sp->cookie = NULL;
}
+ if (rv != LDAP_SUCCESS) {
+ debug(ap->logopt,
+ MODPREFIX "ldap_parse_result failed with %d", rv);
+ goto out_free;
+ }
+
/*
* Parse the page control returned to get the cookie and
* determine whether there are more pages.
@@ -2033,8 +2039,8 @@ do_paged:
if (returnedControls)
ldap_controls_free(returnedControls);
+out_free:
ldap_control_free(pageControl);
-
return rv;
}
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] lookup_ldap.c: no need to free a result that is NULL
Hi, Ian,
Here's another trivial patch. If we already know the result pointer is
null, there's no need to call ldap_msgfree on it!
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/Makefile.rules b/Makefile.rules
index f2ba386..26da6d8 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -38,7 +38,7 @@ STRIP = strip --strip-debug
endif
endif
-CC= gcc
+# CC= gcc
CXX = g++
CXXFLAGS = $(CFLAGS)
LD= ld
diff --git a/modules/lookup_ldap.c b/modules/lookup_ldap.c
index 3a31a8e..d0cbdca 100644
--- a/modules/lookup_ldap.c
+++ b/modules/lookup_ldap.c
@@ -400,7 +400,6 @@ static int get_query_dn(unsigned logopt, LDAP *ldap, struct
lookup_context *ctxt
}
if (!result) {
- ldap_msgfree(result);
error(logopt,
MODPREFIX "failed to find query dn under search
base dns");
free(query);
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] lookup_ldap.c: set result pointer to NULL when search fails
Hi, Ian,
It looks like we could end up with a result pointer that is non-null
from a failed call to ldap_search_s. At least, in my brief look at the
library code it looks like this *might* happen. So, to be safe, let's
check for that.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/modules/lookup_ldap.c b/modules/lookup_ldap.c
index 2ecf5fe..3a31a8e 100644
--- a/modules/lookup_ldap.c
+++ b/modules/lookup_ldap.c
@@ -390,6 +390,10 @@ static int get_query_dn(unsigned logopt, LDAP *ldap,
struct lookup_context *ctxt
error(logopt,
MODPREFIX "query failed for search dn %s:
%s",
this->basedn, ldap_err2string(rv));
+ if (result) {
+ ldap_msgfree(result);
+ result = NULL;
+ }
}
this = this->next;
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] alarm.c: don't pass a null pointer to pthread_attr_destroy
Hi, Ian, Here's another variant of the null pointer passed to attr_destroy. Cheers, Jeff Signed-off-by: Jeff Moyer diff --git a/lib/alarm.c b/lib/alarm.c index 46df38a..f403d8f 100755 --- a/lib/alarm.c +++ b/lib/alarm.c @@ -239,7 +239,8 @@ int alarm_start_handler(void) status = pthread_create(&thid, pattrs, alarm_handler, NULL); - pthread_attr_destroy(pattrs); + if (pattrs) + pthread_attr_destroy(pattrs); return !status; } ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] don't pass a null pointer to pthread_attr_destroy
Hi, Ian, pthread_attr_destroy will dereference the pointer that is passed in. Since we can get here with a NULL pattrs, we better check for that. Cheers, Jeff Signed-off-by: Jeff Moyer diff --git a/daemon/state.c b/daemon/state.c index 71af46a..2eeb4bf 100644 --- a/daemon/state.c +++ b/daemon/state.c @@ -1198,7 +1198,8 @@ int st_start_handler(void) status = pthread_create(&thid, pattrs, st_queue_handler, NULL); - pthread_attr_destroy(pattrs); + if (pattrs) + pthread_attr_destroy(pattrs); return !status; } ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch] fix backwards #ifndef INET6
Hi, Ian, Looks like a wire got crossed here. Cheers, Jeff Signed-off-by: Jeff Moyer diff --git a/modules/replicated.c b/modules/replicated.c index a66de9f..7ea86d7 100644 --- a/modules/replicated.c +++ b/modules/replicated.c @@ -231,7 +231,7 @@ static unsigned int get_proximity(struct sockaddr *host_addr) break; case AF_INET6: -#ifndef INET6 +#ifdef INET6 if (host_addr->sa_family == AF_INET) break; ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Using autofs with on non-mounted directory
Lukas Haase writes: > Hi, > > I have the problem that I have an indirect mount in > "/var/lib/vz/root/500/media/media". Unfortunately this directory does > not always exists (particulary not on system startup). So it doesn't get mounted automatically? If it *is* mounted as part of startup, then it sounds like you just need to move that sooner in your boot order. > The directory exists as soon as another filesystem > "/var/lib/vz/root/500" is mounted. I have the possibility to execute a > script when that filesystem is mounted and umounted. > Do I have the possibility to add/remove this indirect mount somehow > "on the fly"? You would have to script this yourself. There is no real api to tell the automounter to add map entries. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch, trivial] fix a typo in the redhat/autofs.init.in usage text
Signed-off-by: Jeff Moyer
diff --git a/redhat/autofs.init.in b/redhat/autofs.init.in
index fded1d8..806302b 100644
--- a/redhat/autofs.init.in
+++ b/redhat/autofs.init.in
@@ -172,7 +172,7 @@ case "$1" in
fi
;;
*)
- echo $"Usage: $0
{start|forcestart|stop|status|restart|orcerestart|reload|condrestart}"
+ echo $"Usage: $0
{start|forcestart|stop|status|restart|forcerestart|reload|condrestart}"
exit 1;
;;
esac
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [patch, rfc] autofs4: add trace points to the mount and unmount paths
Ian Kent writes:
> Steve Dickson wrote:
>> The main point with these two question is I have found it
>> very handy to write system tap scripts that only fire
>> when there is a non-zero status Which means instead
>> of getting pages and pages of info scrolling off the
>> screen, I get one (or few) lines of error conditions that
>> generally have a bit more meaning...
Given Ian's point about logging entire paths, this updated patch will
still log before determining the final status of a request. If you
want, you could cache that in systemtap until the status is received and
try to correlate the two events (which would address your request of
logging only on failures). For the lookup routine, you need to check if
dentry is -ENOENT. for follow_link etc, there's a status code. The
associated systemtap patch can be found here:
http://people.redhat.com/jmoyer/systemtap
Ian, let me know what you think.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index aa39ae8..6c86df9 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -13,6 +13,7 @@
* - */
#include "autofs_i.h"
+#include
static unsigned long now;
@@ -496,6 +497,7 @@ int autofs4_do_expire_multi(struct super_block *sb, struct
vfsmount *mnt,
/* This is synchronous because it makes the daemon a
little easier */
ret = autofs4_wait(sbi, dentry, NFY_EXPIRE);
+ trace_autofs4_do_expire_multi(mnt, dentry, ret);
spin_lock(&sbi->fs_lock);
if (ino->flags & AUTOFS_INF_MOUNTPOINT) {
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index b96a3c5..7cefdad 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -19,6 +19,9 @@
#include
#include "autofs_i.h"
+#define CREATE_TRACE_POINTS
+#include
+
static int autofs4_dir_symlink(struct inode *,struct dentry *,const char *);
static int autofs4_dir_unlink(struct inode *,struct dentry *);
static int autofs4_dir_rmdir(struct inode *,struct dentry *);
@@ -216,6 +219,7 @@ static void *autofs4_follow_link(struct dentry *dentry,
struct nameidata *nd)
(!d_mountpoint(dentry) && __simple_empty(dentry))) {
spin_unlock(&dcache_lock);
+ trace_autofs4_follow_link(nd, dentry);
status = try_to_fill_dentry(dentry, 0);
if (status)
goto out_error;
@@ -237,9 +241,11 @@ follow:
}
done:
+ trace_autofs4_follow_link_status(dentry, 0);
return NULL;
out_error:
+ trace_autofs4_follow_link_status(dentry, status);
path_put(&nd->path);
return ERR_PTR(status);
}
@@ -540,6 +546,8 @@ static struct dentry *autofs4_lookup(struct inode *dir,
struct dentry *dentry, s
dput(expiring);
}
+ trace_autofs4_lookup(nd, dentry);
+
spin_lock(&dentry->d_lock);
dentry->d_flags |= DCACHE_AUTOFS_PENDING;
spin_unlock(&dentry->d_lock);
@@ -595,12 +603,16 @@ static struct dentry *autofs4_lookup(struct inode *dir,
struct dentry *dentry, s
if (unhashed)
dput(unhashed);
+ trace_autofs4_lookup_status(dentry);
return dentry;
}
- if (unhashed)
+ if (unhashed) {
+ trace_autofs4_lookup_status(unhashed);
return unhashed;
+ }
+ trace_autofs4_lookup_status(NULL);
return NULL;
}
diff --git a/include/trace/events/autofs4.h b/include/trace/events/autofs4.h
index 39f04c9..6feae79 100644
--- a/include/trace/events/autofs4.h
+++ b/include/trace/events/autofs4.h
@@ -1,26 +1,115 @@
#if !defined(_TRACE_AUTOFS4_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_AUTOFS4_H
+#include
+#include
+#include
#include
#undef TRACE_SYSTEM
#define TRACE_SYSTEM autofs4
TRACE_EVENT(autofs4_do_expire_multi,
- TP_PROTO(struct vfsmount *mnt, struct dentry *dentry),
- TP_ARGS(mnt, dentry),
+ TP_PROTO(struct vfsmount *mnt, struct dentry *dentry, int status),
+ TP_ARGS(mnt, dentry, status),
TP_STRUCT__entry(
__array(char, comm, TASK_COMM_LEN)
__field(pid_t, pid)
+ __array(char, path, MAX_FILTER_STR_VAL)
+ __field(int, status)
),
TP_fast_assign(
__entry->pid = current->pid;
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ snprintf(__entry->path,
+dentry->d_name.len < MAX_FILTER_STR_VAL ?
+de
Re: [autofs] [patch, rfc] autofs4: add trace points to the mount and unmount paths
Steve Dickson writes:
> Hey,
>
> Comments in-line...
>
> On 06/30/2009 01:08 PM, Jeff Moyer wrote:
>> Hi, Ian,
>>
>> I got a fairly simply request from a customer. They wanted to use
>> systemtap to track automounter mount and unmount activity.
>> Unfortunately, the compiler inlined the expire functions I wanted to
>> instrument, so I needed to add a tracepoint to get at useful
>> information.
>>
>> This patch, then, adds a few trace points so that we don't have to worry
>> about compiler inlining. I have an example script using these trace
>> points that I'll be sending along to the systemtap mailing list
>> shortly. Let me know what you think. If you're interested in trying it
>> out, I've made my systemtap patch available at:
>> http://people.redhat.com/jmoyer/systemtap
>>
>> You can try running testsuite/systemtap.examples/general/autofs.stp. It
>> should run with or without the below patch applied, though the results
>> are not as accurate (can't get full paths for unmounts) without the
>> tracepoint in autofs4_do_expire_multi.
>>
>> Cheers,
>> Jeff
>>
>> Signed-off-by: Jeff Moyer
>>
>> diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
>> index aa39ae8..6c86df9 100644
>> --- a/fs/autofs4/expire.c
>> +++ b/fs/autofs4/expire.c
>> @@ -13,6 +13,7 @@
>> *
>> - */
>>
>> #include "autofs_i.h"
>> +#include
>>
>> static unsigned long now;
>>
>> @@ -496,6 +497,7 @@ int autofs4_do_expire_multi(struct super_block *sb,
>> struct vfsmount *mnt,
>> /* This is synchronous because it makes the daemon a
>> little easier */
>> ret = autofs4_wait(sbi, dentry, NFY_EXPIRE);
>> +trace_autofs4_do_expire_multi(mnt, dentry, ret);
>>
>> spin_lock(&sbi->fs_lock);
>> if (ino->flags & AUTOFS_INF_MOUNTPOINT) {
>> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
>> index b96a3c5..cbb17b7 100644
>> --- a/fs/autofs4/root.c
>> +++ b/fs/autofs4/root.c
>> @@ -19,6 +19,9 @@
>> #include
>> #include "autofs_i.h"
>>
>> +#define CREATE_TRACE_POINTS
>> +#include
>> +
>> static int autofs4_dir_symlink(struct inode *,struct dentry *,const char *);
>> static int autofs4_dir_unlink(struct inode *,struct dentry *);
>> static int autofs4_dir_rmdir(struct inode *,struct dentry *);
>> @@ -216,6 +219,7 @@ static void *autofs4_follow_link(struct dentry *dentry,
>> struct nameidata *nd)
>> (!d_mountpoint(dentry) && __simple_empty(dentry))) {
>> spin_unlock(&dcache_lock);
>>
>> +trace_autofs4_follow_link(nd, dentry);
>> status = try_to_fill_dentry(dentry, 0);
> Would it make sense to put the trace point after the
> try_to_fill_dentry() so the status could be recorded in the
> trace point? Similar to the trace point above?
>
>> if (status)
>> goto out_error;
>> @@ -540,6 +544,8 @@ static struct dentry *autofs4_lookup(struct inode *dir,
>> struct dentry *dentry, s
>> dput(expiring);
>> }
>>
>> +trace_autofs4_lookup(nd, dentry);
> Same kinda idea here... would it make sense to move this
> trace point some where so the status can be recorded?
>
> The main point with these two question is I have found it
> very handy to write system tap scripts that only fire
> when there is a non-zero status Which means instead
> of getting pages and pages of info scrolling off the
> screen, I get one (or few) lines of error conditions that
> generally have a bit more meaning...
>
> Just a suggestion...
Yeah, that's a good suggestion, thanks! I'll respin with that changed after
I've heard from Ian.
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [patch, rfc] autofs4: add trace points to the mount and unmount paths
Hi, Ian,
I got a fairly simply request from a customer. They wanted to use
systemtap to track automounter mount and unmount activity.
Unfortunately, the compiler inlined the expire functions I wanted to
instrument, so I needed to add a tracepoint to get at useful
information.
This patch, then, adds a few trace points so that we don't have to worry
about compiler inlining. I have an example script using these trace
points that I'll be sending along to the systemtap mailing list
shortly. Let me know what you think. If you're interested in trying it
out, I've made my systemtap patch available at:
http://people.redhat.com/jmoyer/systemtap
You can try running testsuite/systemtap.examples/general/autofs.stp. It
should run with or without the below patch applied, though the results
are not as accurate (can't get full paths for unmounts) without the
tracepoint in autofs4_do_expire_multi.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index aa39ae8..6c86df9 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -13,6 +13,7 @@
* - */
#include "autofs_i.h"
+#include
static unsigned long now;
@@ -496,6 +497,7 @@ int autofs4_do_expire_multi(struct super_block *sb, struct
vfsmount *mnt,
/* This is synchronous because it makes the daemon a
little easier */
ret = autofs4_wait(sbi, dentry, NFY_EXPIRE);
+ trace_autofs4_do_expire_multi(mnt, dentry, ret);
spin_lock(&sbi->fs_lock);
if (ino->flags & AUTOFS_INF_MOUNTPOINT) {
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index b96a3c5..cbb17b7 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -19,6 +19,9 @@
#include
#include "autofs_i.h"
+#define CREATE_TRACE_POINTS
+#include
+
static int autofs4_dir_symlink(struct inode *,struct dentry *,const char *);
static int autofs4_dir_unlink(struct inode *,struct dentry *);
static int autofs4_dir_rmdir(struct inode *,struct dentry *);
@@ -216,6 +219,7 @@ static void *autofs4_follow_link(struct dentry *dentry,
struct nameidata *nd)
(!d_mountpoint(dentry) && __simple_empty(dentry))) {
spin_unlock(&dcache_lock);
+ trace_autofs4_follow_link(nd, dentry);
status = try_to_fill_dentry(dentry, 0);
if (status)
goto out_error;
@@ -540,6 +544,8 @@ static struct dentry *autofs4_lookup(struct inode *dir,
struct dentry *dentry, s
dput(expiring);
}
+ trace_autofs4_lookup(nd, dentry);
+
spin_lock(&dentry->d_lock);
dentry->d_flags |= DCACHE_AUTOFS_PENDING;
spin_unlock(&dentry->d_lock);
diff --git a/include/trace/events/autofs4.h b/include/trace/events/autofs4.h
new file mode 100644
index 000..dae6873
--- /dev/null
+++ b/include/trace/events/autofs4.h
@@ -0,0 +1,75 @@
+#if !defined(_TRACE_AUTOFS4_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_AUTOFS4_H
+
+#include
+#include
+#include
+#include
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM autofs4
+
+TRACE_EVENT(autofs4_do_expire_multi,
+ TP_PROTO(struct vfsmount *mnt, struct dentry *dentry, int status),
+ TP_ARGS(mnt, dentry, status),
+ TP_STRUCT__entry(
+ __array(char, comm, TASK_COMM_LEN)
+ __field(pid_t, pid)
+ __array(char, path, MAX_FILTER_STR_VAL)
+ __field(int, status)
+ ),
+ TP_fast_assign(
+ __entry->pid = current->pid;
+ memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ snprintf(__entry->path,
+dentry->d_name.len < MAX_FILTER_STR_VAL ?
+dentry->d_name.len : MAX_FILTER_STR_VAL,
+"%s", dentry->d_name.name);
+ __entry->status = status;
+ ),
+ TP_printk("%s[%d]: expiry of %s %s",
+ __entry->comm, __entry->pid, __entry->path,
+ __entry->status == 0 ? "succeeded" : "failed")
+);
+
+TRACE_EVENT(autofs4_lookup,
+ TP_PROTO(struct nameidata *nd, struct dentry *dentry),
+ TP_ARGS(nd, dentry),
+ TP_STRUCT__entry(
+ __array(char, comm, TASK_COMM_LEN)
+ __array(char, path, MAX_FILTER_STR_VAL)
+ __field(char *, pathptr)
+ __field(pid_t, pid)
+ ),
+ TP_fast_assign(
+ __entry->pid = current->pid;
+ memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
[autofs] [patch] allow the automount daemon to dump core
Hi,
Right now, the automount daemon blocks all signals. We should at least
unblock those that will cause us to dump core. Otherwise, I think the
behaviour could be, umm, interesting.
I tested this by sending SIGBUS and SIGSEGV to the automount daemon.
Cheers,
Jeff
Signed-off-by: Jeff Moyer
diff --git a/daemon/automount.c b/daemon/automount.c
index 80691fa..04fa304 100644
--- a/daemon/automount.c
+++ b/daemon/automount.c
@@ -1324,6 +1324,10 @@ static void *statemachine(void *arg)
sigfillset(&signalset);
sigdelset(&signalset, SIGCHLD);
sigdelset(&signalset, SIGCONT);
+ sigdelset(&signalset, SIGBUS);
+ sigdelset(&signalset, SIGSEGV);
+ sigdelset(&signalset, SIGILL);
+ sigdelset(&signalset, SIGFPE);
while (1) {
sigwait(&signalset, &sig);
@@ -1817,6 +1821,11 @@ int main(int argc, char *argv[])
};
sigfillset(&allsigs);
+ /* allow for the dropping of core files */
+ sigdelset(&allsigs, SIGBUS);
+ sigdelset(&allsigs, SIGSEGV);
+ sigdelset(&allsigs, SIGILL);
+ sigdelset(&allsigs, SIGFPE);
sigprocmask(SIG_BLOCK, &allsigs, NULL);
program = argv[0];
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Autofs Error Messages
Thanh Tran writes: > I've been having problems w/ automount. It does not detect my usb > drive. Looking at the system logs, my kernel seems to see the usb > stick insertion just fine. The automount log indicates it's running. > I get the following message. > > automount[900]: attempting to mount entry /mnt/usbdrive/usbdrive > automount[900]: lookup(program): lookup for usbdrive failed > automount[900]: failed to mount /mnt/usbdrive/usbdrive > > The auto.master: > > /mnt/usbdrive /etc/auto.usbdrive > > The auto.usbdrive: > usbdrive -fstype=vfat,uid=500,gid=500,umask=002 :/dev/sdb1 > > I've done a quick internet search on the issue and the advice I got > was to check the auto.usbdrive file. It seems OK to me. Any other > suggestions? Thanks in advance. Hmm, second report of this sort of thing. Does a chmod -x of /etc/auto.usbdrive make things work? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] writing to fstab or mtab
Stef Bon writes: > Hello, > Now to prevent HAL to try to mount the device at /media, the scripts in > my contruction write a line to /etc/fstab, like: > > /dev/sdb1 /home/sbon/Connections/Devices/USB\040stick auto noauto,user 0 0 > > This works very good, but this setting in fstab confuses the > automounter. I'm not trying to solve my problem here with hal, but how > come the setting in fstab to confuse autofs? Stef, you're going to have to be a bit more specific! What do you mean it confuses the automounter? What behaviour is expected/observed? Do you have a debug log? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] HOST expansion with autofs+LDAP
wsny...@wsnyder.org (Wilson Snyder) writes:
>>Ian Kent wrote:
>>> Wilson Snyder wrote:
I have a suse10.3 system which includes autofs-5.0.2-30.2
I'd like an LDAP entry that makes an autofs mountpoint that
includes the local host's name. If this wasn't under LDAP I
believe "/net/$HOST" would work - creating a
"/net/{name-of-hostname}" mountpoint.
However, if I add a mountpoint with cn=$HOST
cn=$HOST,nismapname=auto.net,dc=company,dc=com
The automounter nicely makes a "/net/$HOST" mount -
*literally* /net/$HOST, that is it doesn't expand $HOST to
the hostname.
Same thing if I use cn=${host}
Any hints? Thanks!
>>>
>>> Oddly enough I think that $HOST should be expanded but I have no idea
>>> how you think this is supposed to work because you haven't provided any
>>> information about the LDAP entry, other than the dn, or provided any
>>> debug log information.
>>
>>Sorry, that isn't correct.
>>Macro expansion is not done on keys and never has been.
>>
>>Which begs the question, is it sensible to do macro expansion on keys
>>from a map before trying to match them against the key string received
>>from the kernel for the lookup?
>
> I'm not sure if I'm decoding the question properly, but I
> suspect it's fast enough to expand on the fly, as that's
> more flexible, but either way works for my application since
> HOST is (well is generally) constant.
>
> Can you point me to the right place in t the 5.0.2 sources
> to patch this in? I see the expansion code in parse_mount
> but am not sure what the best place to call it from is.
Here's a general overview of how things work:
1) A process walks into an automount managed mountpoint and does a lookup
of a directory, in your case, fully.qualified.domain.name.
2) The kernel passes this on to the automount daemon as a lookup of
"fully.qualified.domain.name"
3) the automount daemon checks its maps for an entry with a key of
"fully.qualified.domain.name"
So, the trick is figuring out how the automount daemon is supposed to
know that "fully.qualified.domain.name" belongs to your entry with
cn="$HOST".
You *could* enumerate the entire map on startup, and expand the $HOST in
the automounter's cache. However, not all map sources support
enumeration (hesiod and program maps come to mind). So, what do you do
in those cases?
Further, Ian mentioned that this is a catch 22. You want to parse an
entry in the lookup phase. The automounter is laid out in a bit of a
layered format:
daemon proper |
- |
lookup modules | (looks up keys)
- |
parse modules | (expands *entries*)
- |
mount modules V (mounts expanded entry on dir named by key)
The flow is as the arrow indicates. What you're asking for is parsing
in the lookup module. (It's doable, of course, barring the problem that
it won't work for all map types.)
Now, backing up, here, why do you want to create a directory with the
local host's fqdn? What are you really trying to do? This goes back to
Ian's initial question, I guess.
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Map a single file??
Ian Kent writes: > Stef Bon wrote: >> Hello, >> >> I would like to know is it possible for the automounter to map a single >> file? >> In KDE, the filemanagers Dolphin and Konqueror look for the file >> .directory in every >> directory. In some cases I want to present a special .directory file. >> The automounter is presenting a >> tree which consist of networks, workgroups, servers and shares. For the >> network for example, the windows network folder icon would be something >> like an windows icon. This can be set in the .directory file. Futher I >> want these directories presented as icons, not in list. >> >> So, can the automounter map single files, besides directories mapped to >> networkmountpoints? > > That's not functionality that belongs in the autofs. > > This amounts to being able to "mount a single file" and AFAIK Linux > doesn't have this functionality at all and OSs that do have this only > for files that have specific support for particular files, such as > /etc/mnttab in Solaris. Actually, you *can* bind mount a single file. However, the automount daemon does not support this construct as we mkdir the path and mount on top of that. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Negative caching of failed mount attempts
Leonardo Chiquitto writes: >> So what do you have, 4.1.4 will all the patches from kernel.org or the >> SLES 10 package, or an SLES 10 update of some sort? > > Sorry for not being specific here. > > I'm using the latest SLES10 update, which basically is 4.1.4 + some > patches from kernel.org + distribution specific configuration and build > changes + a couple of other bug fixes that are not upstream. > > To make things easier to everyone, I grabbed the latest tarball and > patches from kernel.org and applied autofs-4.1.4-negative-timeout.patch > from RHEL 4 (credits to Jeff Moyer). Just one chunk was rejected (the > one from lookup_hesiod.c). Please find the refreshed patch attached, > minimally tested so far. > > I'd appreciate if it could be merged upstream (after proper testing, of > course). I think you need at least two more patches: autofs-4.1.3-negative-timeout-doc-update.patch autofs-4.1.3-teach-cache-about-negative-mapents.patch There may be more, though. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Negative caching of failed mount attempts
Ian Kent writes: > Leonardo Chiquitto wrote: >> Hello, >> >> Three years ago, commit 2d753e62b8 removed kernel-side caching >> of mount attempts that returns -ENOENT. Apparently it wasn't >> working as it should. > > It stopped working when 2.6 was released due to changes in the VFS. > These changes made it extremely hard to do in the kernel module. Efforts > to do it in the kernel module have been abandoned at this stage. > >> I see that this feature is now implemented in the user land AutoFS 5 >> daemon, but it wasn't back ported to AutoFS 4. I understand that >> version 4 is not maintained anymore, but I'd like to ask if someone >> has a patch around that implements this feature. > > I guess that's what it amounts to, since all the effort is going into v5. > > I have a bunch of patches for v4 from Jeff Moyer that I've not got > around to looking closely at and applying. We didn't get as far as the > negative lookup caching patch though. In fact I don't think it had been > written then. Tough call on what to do here. I don't like that we have all of these patches in RHEL only. At the same time, new distribution versions should be using autofs5. So, I'm having a hard time justifying the work of merging all of the work we've done in the RHEL package. Are people still looking for new features in autofs 4? If so, why? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] make an executable map rerun.
Stef Bon writes: > Jeff Moyer wrote: >> Stef Bon writes: >> >> >>> Hello, >>> >>> I've been working on a solution to make networkresources available >>> via autofs on a dynamic way. After login with help >>> from ConsoleKit a mountpoint is added to the master file of the >>> automounter. This mountpoint is in the homedirectory of the user >>> logging in. >>> >>> This way I've a browseable network map in my home directory for >>> Windows Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with >>> sshfs/FUSE). Others, like Novell should be possible. >>> >> >> This sounds like interesting work. Do you have it posted somewhere? >> > > Yes, look at: > > http://linux.bononline.nl/linux/automountsmbshares/index.php >> >>> It works with executable maps. Now for some reasons I would like >>> some control over rerrunning the executable map, to make the >>> automounter refresh the autofs data. Now I do not see how to do >>> that. I reload signal does not do that. >>> >>> Is there a way to do this? >>> >> >> No caching is done for program maps. They are consulted for every >> single lookup, so you shouldn't have to do anything special. Is this >> not the behaviour you are observing? >> > No, > > after activating the executable map once, the data provided by the > executable map is kept. I've tested this by > letting the executable map write to an logfile, and it's running seldom. > > I can look at the contents of /proc/mounts and here I see the autofs > tree, which is kept. So I do not understand your remark > saying it is consulted every single lookup. Does the option -browse > mather here? I'm using that and because this forces the automounter to > remember the data right? OK, I was wrong. Sorry about that (I was confused with the fact that program maps don't support the -browse option, since they can't support map enumeration). I admit I am not up to speed on v5. However, it looks to me like a HUP signal will not cause the service thread for your mount point to restart unless the actual program map changed. This means the cache will still be in tact, as you observed. I suspect we should probably clear the cache for any maptype that does not support enumeration upon receiving a HUP signal. Ian, what do you think? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] make an executable map rerun.
Stef Bon writes: > Hello, > > I've been working on a solution to make networkresources available via > autofs on a dynamic way. After login with help > from ConsoleKit a mountpoint is added to the master file of the > automounter. This mountpoint is in the homedirectory of the user logging in. > > This way I've a browseable network map in my home directory for Windows > Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). > Others, like Novell should be possible. This sounds like interesting work. Do you have it posted somewhere? > It works with executable maps. Now for some reasons I would like some > control over rerrunning the executable map, to make the automounter > refresh the autofs data. Now I do not see how to do that. I reload > signal does not do that. > > Is there a way to do this? No caching is done for program maps. They are consulted for every single lookup, so you shouldn't have to do anything special. Is this not the behaviour you are observing? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs mounting certain home directories for no reason
Ian Kent writes: > Krish Pillai wrote: >> I just upgraded from Fedora 8 to Fedora 10 >> (2.6.27.19-170.2.35.fc10.x86_64) on some of my machines and autofs seems >> to be acting up. My server is running fc7. >> I have ypbind and automount running on all clients and the clients seem >> to be repeatedly sending mount/umount requests to the server on behalf >> of users who are not even trying to log in. As a result I see home >> directories getting mounted on the clients and getting unmounted all the >> time. Is this a known problem? If so, is there a fix? > > I'm not aware of a problem. > > You probably should collect information as described at > http://people.redhat.com/jmoyer and log a bug. The debug log and autofs > maps are probably the most important bits initially. This is most likely some application in F10 (like the gnome trash daemon) that is triggerring lookups in the home directory. Automount, in and of itself, doesn't usually try to do extra work. ;) -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs5 early daemonization side effects
Leonardo Chiquitto writes: > Hello, > > I've been doing some tests with AutoFS5 and I'd like to confirm that > the behavior I'm seeing during the daemon initialization is expected > or not. > > The problem: when the autofs initscript returns, autofs is not really > ready. Strange. I originally wrote the code to return a status via a pipe, so that the init script would not return status until the daemon was ready to service requests. It also took care of the problem of the init script returning success when the daemon actually failed. Ian, has this changed? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] ghost parameter not working
Nathan Huesken writes: > Hi, > > I am on arch-linux. > I have installed autofs 4.1.4 > My auto,master: > /media/auto /etc/autofs/auto.misc --timeout=1 --ghost > > /etc/autofs/auto.misc: > cdrom -fstype=iso9660,ro,nodev,nosuid :/dev/cdrom > usbstick -fstype=auto,async,nodev,nosuid,umask=000 :/dev/sdb1 > > It all works! I can change into /media/auto/usbstick and see the > usbstick. > But the ghost option does not work! If I do ls /media/auto it shows not > directories at all. > What could be wrong? Please post a debug log, and let us know your kernel version. Directions for obtaining a debug log can be found on my people page: http://people.redhat.com/jmoyer Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 1/4] Make hash table scale to thousands of entries
Paul Wankadia writes: > On 1/16/09, Ian Kent wrote: > >>> Sure, just read the whole map. Even large maps aren't that big. What >>> are we talking, 10k? 50k? You're better off reading the whole thing in >>> at once. >> >> Yeah, that would be best. I'll have a think about how to detect when to >> do that. Maybe we can rip out that convoluted change detection logic for >> file maps, after all they should be fairly simple to deal with. > > If inotify can play nicely with the existing event handling, then it > could be worth considering. Ian was coming up with a scheme to only read part of the map. Because the map is just a flat file, he surmised that a lookup could happen like so: first lookup, start at the beginning of the file walk the entries, adding each to the cache until you find the entry you're looking for cache the offset into the file and stop reading When a cache miss comes in, start reading the file again at the last offset (so long as the file hasn't changed on disk) My argument is that you're not really saving much. Just cache the whole file. I agree that you probably want to detect changes, still. For that, you can use mtime or inotify. You could make a case for either side, though I think I'd argue for keeping the mtime approach (as the map may change multiple times before we actually try to read it, and doing the read in the lookup path really shouldn't be that big of a deal). Of course, I haven't profiled this, so that may be worth doing. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 1/4] Make hash table scale to thousands of entries
Ian Kent writes: > But onto the problem. > > It should be fairly straight forward to start using the map mtime again. > The time stamp on cache entries that have been added will be later than > the mtime if the file map hasn't changed so we can use that. But we also > need to prevent re-reading the map from the beginning as we populate the > cache. I was thinking that I could add each entry read during a lookup > to the cache so that they would be found on subsequent lookups (as long > as the mtime is earlier than the time stamp). Additionally, I could keep > track of the file position so I don't read entries already read. It > likely won't be quite as simple in the end but we really need to do > something to for really large maps. > > Any other thoughts? Sure, just read the whole map. Even large maps aren't that big. What are we talking, 10k? 50k? You're better off reading the whole thing in at once. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 1/4] Make hash table scale to thousands of entries
Valerie Aurora Henson writes:
> From: Paul Wankadia
> Signed-off-by: Valerie Aurora Henson
Most patches of this nature come with some description of a performance
problem and how the patch solves it. Which caching algorithm is
implemented below? There are, of course, many hashing algorithms for
variable length strings. Can we get some rationale for the change? I'm
not against it, I'd just like a *little* explanation.
Cheers,
Jeff
> ---
> include/automount.h |2 +-
> lib/cache.c | 29 ++---
> 2 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/include/automount.h b/include/automount.h
> index 1ba0d3c..2a082b5 100644
> --- a/include/automount.h
> +++ b/include/automount.h
> @@ -126,7 +126,7 @@ struct autofs_point;
> #define CHE_DUPLICATE0x0020
> #define CHE_UNAVAIL 0x0040
>
> -#define HASHSIZE 77
> +#define HASHSIZE 4096
> #define NEGATIVE_TIMEOUT 10
> #define UMOUNT_RETRIES 8
> #define EXPIRE_RETRIES 3
> diff --git a/lib/cache.c b/lib/cache.c
> index ce47e04..36b8294 100644
> --- a/lib/cache.c
> +++ b/lib/cache.c
> @@ -281,20 +281,27 @@ struct mapent_cache *cache_init_null_cache(struct
> master *master)
> return mc;
> }
>
> -static unsigned int hash(const char *key)
> +static u_int32_t hash(const char *key)
> {
> - unsigned long hashval;
> + u_int32_t hashval;
> char *s = (char *) key;
>
> - for (hashval = 0; *s != '\0';)
> - hashval += *s++;
> + for (hashval = 0; *s != '\0';) {
> + hashval += (unsigned char) *s++;
> + hashval += (hashval << 10);
> + hashval ^= (hashval >> 6);
> + }
> +
> + hashval += (hashval << 3);
> + hashval ^= (hashval >> 11);
> + hashval += (hashval << 15);
>
> return hashval % HASHSIZE;
> }
>
> -static unsigned int ino_hash(dev_t dev, ino_t ino)
> +static u_int32_t ino_hash(dev_t dev, ino_t ino)
> {
> - unsigned long hashval;
> + u_int32_t hashval;
>
> hashval = dev + ino;
>
> @@ -303,7 +310,7 @@ static unsigned int ino_hash(dev_t dev, ino_t ino)
>
> int cache_set_ino_index(struct mapent_cache *mc, const char *key, dev_t dev,
> ino_t ino)
> {
> - unsigned int ino_index = ino_hash(dev, ino);
> + u_int32_t ino_index = ino_hash(dev, ino);
> struct mapent *me;
>
> me = cache_lookup_distinct(mc, key);
> @@ -325,7 +332,7 @@ struct mapent *cache_lookup_ino(struct mapent_cache *mc,
> dev_t dev, ino_t ino)
> {
> struct mapent *me = NULL;
> struct list_head *head, *p;
> - unsigned int ino_index;
> + u_int32_t ino_index;
>
> ino_index_lock(mc);
> ino_index = ino_hash(dev, ino);
> @@ -371,7 +378,7 @@ struct mapent *cache_lookup_first(struct mapent_cache *mc)
> struct mapent *cache_lookup_next(struct mapent_cache *mc, struct mapent *me)
> {
> struct mapent *this;
> - unsigned long hashval;
> + u_int32_t hashval;
> unsigned int i;
>
> if (!me)
> @@ -532,7 +539,7 @@ int cache_add(struct mapent_cache *mc, struct map_source
> *ms, const char *key, c
> {
> struct mapent *me, *existing = NULL;
> char *pkey, *pent;
> - unsigned int hashval = hash(key);
> + u_int32_t hashval = hash(key);
> int status;
>
> me = (struct mapent *) malloc(sizeof(struct mapent));
> @@ -752,7 +759,7 @@ int cache_update(struct mapent_cache *mc, struct
> map_source *ms, const char *key
> int cache_delete(struct mapent_cache *mc, const char *key)
> {
> struct mapent *me = NULL, *pred;
> - unsigned int hashval = hash(key);
> + u_int32_t hashval = hash(key);
> int status, ret = CHE_OK;
> char *this;
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 2/4] Make MAX_ERR_BUF and PARSE_MAX_BUF use easier to audit
Valerie Aurora Henson writes:
> Signed-off-by: Valerie Aurora Henson
> @@ -1524,18 +1525,12 @@ int lookup_read_master(struct master *master, time_t
> age, void *context)
> goto next;
> }
>
> - blen = strlen(*keyValue) + 1 + strlen(*values) + 2;
> - if (blen > PARSE_MAX_BUF) {
> + if (snprintf(parse_buf, sizeof(parse_buf), "%s %s",
> + *keyValue, *values) > sizeof(parse_buf)) {
I think this should be >=.
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] automounter segfaults when using negative cache?
Ian Kent <[EMAIL PROTECTED]> writes: > On Fri, 2008-12-05 at 11:00 -0500, Jeff Moyer wrote: >> >> The negative caching is done in userspace. I'm not sure I understand >> your question. > > Me neither but I'm working on the negative caching of non-existent map > keys. Turns out to be a bit tricky when multiple nsswitch sources can be > tried for each mount since the map may not exist within a given source > and so we get NSS_STATUS_UNAVAIL instead of NSS_STATUS_NOTFOUND. Maybe I > should just cache the unavailable in the same way? Ian, this is autofs version 4. It's been a while since I implemented the negative caching there, but I'd be interested in knowing if you think I got it wrong for the case above! Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] more than 1024 mounts ==>hangs
Ian Kent <[EMAIL PROTECTED]> writes: > On Thu, 2008-12-04 at 14:13 +0100, Martin Vogt wrote: >> >> Hello list, >> >> I'm currently experimenting with autofs on SuSE 11.1 rc1 >> >> -autofs-5.0.3-82.19 > > I don't know what this means in terms of patches applied, but ok. > >> >> Around the 1024th mount, autofs hangs and the machine needs a reboot -f. >> >> I have here >2000 mount points which usually look like this: >> >> /homes/vogt0001 --fstype=bind :/net/fsA/home/user/vogt0001 >> /homes/vogt0002 --fstype=bind :/net/fsB/home/user/vogt0002 >> [..] >> /homes/vogt2000 --fstype=bind :/net/fsC/home/user/vogt2000 > > So a direct map? > With many active real mounts, is that what you're saying? > >> >> >> Further debugging revealed: >> >> pxe1:/home/demo1 # lsof -p >> [...] >> automount 5111 root 1022r DIR 0,2280 13029 /u/itwm/hinojosa >> automount 5111 root 1023r DIR 0,5610 13362 /u/itwm/andrejs >> automount 5111 root 1024r FIFO0,7 0t0 26910 pipe >> >> The 1024 really looks like some limit, which is hit by the automount >> process. > > Quite possibly, but I don't think there is anything autofs can do about > it since in autofs we see: > ... > #define MAX_OPEN_FILES 10240 > ... > rlim.rlim_cur = MAX_OPEN_FILES; > rlim.rlim_max = MAX_OPEN_FILES; > res = setrlimit(RLIMIT_NOFILE, &rlim); > if (res) > warn(logging, > "can't increase open file limit - continuing"); > > Unless I've not got this correct in some way the open file limit should > be much higher. But there are ways the OS configuration can limit this. I'm pretty sure root processes bypass the max open fds check. [snip] >> Ah, the behavoir by autofs is: >> >> - It hangs on duing a mount operation: >> >> root 5111 0.0 0.1 97200 2936 pts/0Sl+ 13:30 0:01 >> /usr/sbin/automount -d -f -t 600 -p /var/run/automount.pid -O ro >> root 9541 0.0 0.0 0 0 pts/0Z+ 13:31 0:00 [mount] >> > > So maybe mount(8) and its relatives are the problem, not sure I can do > much about that either. Yeah, strange. Can we figure out what the mount commandline was for this zombie? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] automounter segfaults when using negative cache?
Ondrej Valousek <[EMAIL PROTECTED]> writes: > Interesting thing: > I have 2 identical login01 and login02 machines (Rhel4, full updates). > login01 is running old kernel (2.6.9-42.ELsmp), login02 is running the > latest one (2.6.9-78.0.8.ELsmp). Both have autofs debug enabled and are > running the latest autofs (autofs-4.1.3-234). > Now: > 1) login01: > [EMAIL PROTECTED] ondrejv]# cat /var/log/debug.log* | grep "Dec 4 09:15:09" > Dec 4 09:15:09 login01 automount[3939]: handle_packet: type = 0 > Dec 4 09:15:09 login01 automount[3939]: handle_packet_missing: token > 3533, name .raw_data > Dec 4 09:15:09 login01 automount[3939]: attempting to mount entry > /proj/.raw_data > Dec 4 09:15:09 login01 automount[1649]: lookup(yp): looking up .raw_data > Dec 4 09:15:09 login01 automount[3939]: mt->key set to .raw_data > Dec 4 09:15:09 login01 kernel: automount[1649]: segfault at > rip 002a95916be0 rsp 007fbfffd5c8 error 4 > Dec 4 09:15:09 login01 automount[3939]: handle_child: got pid 1649, sig > 1 (11), stat 0 > Dec 4 09:15:09 login01 automount[3939]: sig_child: found pending iop > pid 1649: signalled 1 (sig 11), exit status 0 > Dec 4 09:15:09 login01 automount[3939]: send_fail: token=3533 > Dec 4 09:15:09 login01 automount[3939]: handle_packet: type = 0 > Dec 4 09:15:09 login01 automount[3939]: handle_packet_missing: token > 3534, name .raw_data > Dec 4 09:15:09 login01 automount[3939]: attempting to mount entry > /proj/.raw_data > Dec 4 09:15:09 login01 automount[1650]: lookup(yp): looking up .raw_data > Dec 4 09:15:09 login01 automount[3939]: mt->key set to .raw_data > Dec 4 09:15:09 login01 kernel: automount[1650]: segfault at > rip 002a95916be0 rsp 007fbfffd5c8 error 4 Can you enable core dumps and get us a stack trace of this? > Note that .raw_data map does not exist in the yp map so it should go > into the negative cache - which happens correctly on login02: > ov 28 23:27:43 login01 automount[4201]: attempting to mount entry > /proj/.raw_data > Nov 28 23:27:43 login01 automount[13394]: lookup(yp): looking up .raw_data > Nov 28 23:27:43 login01 automount[4201]: mt->key set to .raw_data > Nov 28 23:27:43 login01 automount[13394]: lookup(yp): key ".raw_data" > not found in map. > Nov 28 23:27:43 login01 automount[13394]: failed to mount /proj/.raw_data > Nov 28 23:27:43 login01 automount[13394]: umount_multi: > path=/proj/.raw_data incl=1 > Nov 28 23:27:43 login01 automount[4201]: handle_child: got pid 13394, > sig 0 (0), stat 3 > Nov 28 23:27:43 login01 automount[4201]: sig_child: found pending iop > pid 13394: signalled 0 (sig 0), exit status 3 > Nov 28 23:27:43 login01 automount[4201]: update_negative_cache: key: > .raw_data > Nov 28 23:27:43 login01 automount[4201]: Adding negative cache entry for > key .raw_data > Nov 28 23:27:43 login01 automount[4201]: Key .raw_data added to negative > cache > Nov 28 23:27:43 login01 automount[4201]: send_fail: token=15625 > > I thought all the negative caching is done in user space, but apparently > kernel has some influence here > Any explanation? The negative caching is done in userspace. I'm not sure I understand your question. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] automount usb key (vfat and ntfs)
"Paolo Minazzi" <[EMAIL PROTECTED]> writes: > Hi, > I'd like to use automount in an arm embedded system to mount > automatically usb keys. > I have done it for vfat and all is OK. > Now I'd like to include also ntfs file system, so my system can > automount also ntfs filesystems. > > I have searched in this list, but I have not found a post that shows > how do it in a CLEAN way. > > This is my /etc/auto.misc > /etc/auto.misc > pen -fstype=vfat :/dev/sda1 > > I run automount in this way : /sbin/automount --timeout=20 /media file /etc/auto.misc > > I would like to add ntfs (using ntfs-3g fuse driver). > I have tried two ways to do it, but no one is very good. > > ** 1 ** > I have tried this /etc/auto.misc: > > pen -fstype=vfat:/dev/sda1 > pen -fstype=ntfs-3g :/dev/sda1 > > ** 2 ** > I have tried an executable map, but in this way I will need to > identify the filesystem type (for example using fdisk -l) and I will > prefer to avoid to do in this way. > > > > > In my opinion the best way should be the ** 1**. > Automount should try first to mount as vfat, and if it fails try ** 2 > **(ntfs-3g) > But the syntax I used does not work ok. > > There is a way to do it ? In my opinion, mount should automatically mount the file system without having to be told the fstype. If that doesn't work, then I'd suggest a program map. Something simple should work: ---[cut here]--- #!/bin/bash ntfs-3g.probe /dev/sda1 if [ $? -eq 0 ]; then ntfs-3g /dev/sda1 /media/$1 RET=$? else mount -t vfat /dev/sda1 /media/$1 RET=$? fi exit $RET ---[cut here]--- I know this is an embedded system, but don't you still have hal/udev and hotplug events? Personally, I have no experience wiring these things up, but I think that's the right place for this sort of thing. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] hung server again
Joe Pruett <[EMAIL PROTECTED]> writes: i did some testing with a single level /home and if i touch all entries in /home, i eventually ran into some resource limits. maybe there is some tuning i can do? i could go back to /home just being full of symlinks, but that has so many issues of it's own. i'm looking for feedback of other users that might have servers with a thousand or more active mounts and how that works for you. or some other good ideas of how people handle this kind of thing. >>> >>> it looks like centos 4 (2.6.9 based) uses one tcp connection per mount, >>> but centos 5 (2.6.19) uses one tcp connection per server. without delving >>> into the kernel source, i haven't come up with any answers from google >>> yet. can anyone on this list speak to this issue? >> >> This is the much debated superblock sharing. Did you have a more >> specific question, other than to verify your findings? > > yes, i'm curious if my findings are right. and i guess since you > characterize it as much debated, is it now settled? i've seen some Yes. I mention it as much debated as the initial implementation caused some (arguably broken) configurations to change behaviour (break). > discussions (about other oses) of making it tunable in some fashion, > and i could see it being nice to allow up to N mounts to share a > single tcp connection. but for my setup, just a single one will > probably be good enough, although with my recent nss netid discovery, > a lot of my resource issues may go away. I don't think Linux allows tuning of this (aside from explicitly stating that two mounts should not share a cache, which is dangerous). Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] hung server again
Joe Pruett <[EMAIL PROTECTED]> writes: >> i did some testing with a single level /home and if i touch all entries in >> /home, i eventually ran into some resource limits. maybe there is some >> tuning i can do? i could go back to /home just being full of symlinks, but >> that has so many issues of it's own. i'm looking for feedback of other users >> that might have servers with a thousand or more active mounts and how that >> works for you. or some other good ideas of how people handle this kind of >> thing. > > it looks like centos 4 (2.6.9 based) uses one tcp connection per mount, > but centos 5 (2.6.19) uses one tcp connection per server. without delving > into the kernel source, i haven't come up with any answers from google > yet. can anyone on this list speak to this issue? This is the much debated superblock sharing. Did you have a more specific question, other than to verify your findings? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Suspected problem w/ autofs and xauth
Steven Hirsch <[EMAIL PROTECTED]> writes: > I've been battling with an extremely annoying issue that I believe is > related to autofs. My home directory is mounted over NFS using autofs > 4.1.4 (as supplied with Kubuntu Hardy). I've used this setup for > years over perhaps a dozen different distributions without any > particular problems. > > Since moving to the Hardy distro, the problem is this: If I leave the > system idle at the KDE desktop for more than a few minutes, any and > all attempts at opening new windows fail with an error that they > cannot obtain X authorization. If I simply do an 'ls' in my home > directory and try again, it works fine. I believe this is being > caused by the automounter timing out, but I do not find any log > messages from the automounter under any circumstances, so it's > difficult to prove. If I do an strace on the X application, it > appears to be unable to read ~/.Xauthority (which is there and can be > read after triggering a remount). > > Is it possible that autofs behavior changed in a manner such that a > stat of ~/.Xauthority is no longer sufficient to trigger the mounter? > > Any suggestions (or even WAGs) appreciated. I'd love to swat this > annoyance. In theory, the directory shouldn't be unmounted. Try typing just 'mount' to see what's mounted when the problem occurs. What's the kernel version? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] AutoFS5 for 2.6.27.x?
Carsten Aulbert <[EMAIL PROTECTED]> writes: > Hi all > > Jeff Moyer wrote: >> The kernel module is named autofs4 for reasons I won't get into. The >> latest userspace package is autofs version 5. The autofs4 kernel >> modules speaks the autofs version 5 protocol. >> >> In short, you want the autofs version 5 userspace packages. > > Jumping up and down too early I guess: > > I've userland autofs5 version 5.0.3 installed, the kernel 2.6.27.2 has > AUTOFS4 set > $ zgrep AUTOFS /proc/config.gz > CONFIG_AUTOFS_FS=y > CONFIG_AUTOFS4_FS=y Don't build them both into the kernel. Ian, we should see if there's a way to disallow that. You want: CONFIG_AUOTFS_FS=n CONFIG_AUTOFS4_FS=m Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] AutoFS5 for 2.6.27.x?
Carsten Aulbert <[EMAIL PROTECTED]> writes: > Hi all, > > I'm reading/skimming this list for quite a bit of time, but somehow I > lost track. In the mainline kernel 2.6.27.4 there seems to be only > autofs4 not autofs5, right? At least I'm only seeing CONFIG_AUTOFS_FS > and CONFIG_AUTOFS4_FS. > > On the ftp server of kernel.org I found 5.0.3 patches from January, but > that seems quite old to me. The golden question: Is this the correct > tarball to use or is there some git repo were I should pull the patches > - and how? The kernel module is named autofs4 for reasons I won't get into. The latest userspace package is autofs version 5. The autofs4 kernel modules speaks the autofs version 5 protocol. In short, you want the autofs version 5 userspace packages. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Proposed update to auto.smb
Ian Kent <[EMAIL PROTECTED]> writes:
> On Mon, 2008-11-03 at 11:32 +0900, Ian Kent wrote:
>> Hi all,
>>
>> Stef Bon has reported some difficulty with the current auto.smb.
>>
>> I have made a patch which demonstrates the change he is recommending and
>> would like comments from others that use CIFS mounts.
>>
>> To quote Stef, from his previous mail:
>>
>> "Well, the script does (in my network) work with cifs shares, where the
>> original auto.smb doesn't. In my case I have to add the ipaddress or it
>> does not work. The manpage of mount.cifs says that this option has to be
>> used rarely. But it's my experience sometimes when mounting a Win2K or
>> WinXP machine, it does not work.
>> (CIFS expects the tcp name and not the netbiosname, smbfs did that)
>>
>> So I cannot say it's a really "must", but at least it cannot "hurt".
>> You're on the safe side when using the ipaddress."
>>
>> Can we have some comments on the patch below please (including you Stef,
>> since I've modified you change a bit).
>>
>> Ian
>
> Sorry, the patch was not quite right.
>
> autofs-5.0.3 - CIFS use ip address
>
> From: Stef Bon <[EMAIL PROTECTED]>
>
> It has been reported that, for a CIFS mount, in some cases the ip
> address of the server is needed otherwise the mount can fail.
> ---
>
> samples/auto.smb | 26 +-
> 1 files changed, 25 insertions(+), 1 deletions(-)
>
>
> diff --git a/samples/auto.smb b/samples/auto.smb
> index fb39053..7bec126 100755
> --- a/samples/auto.smb
> +++ b/samples/auto.smb
> @@ -3,7 +3,31 @@
> # This file must be executable to work! chmod 755!
>
> key="$1"
> -opts="-fstype=cifs"
> +
> +FILESYSTEM="cifs"
> +
So, umm, when is $FILESYSTEM not going to be cifs?
> +if [ "$FILESYSTEM" != "cifs" ]; then
> + opts="-fstype=$FILESYSTEM,guest"
> +else
> + for P in /bin /sbin /usr/bin /usr/sbin
> + do
> + if [ -x $P/nmblookup ]; then
> + NMBLOOKUP=$P/nmblookup
> + break
> + fi
> + done
> +
> + if [ ! -x "$NMBLOOKUP" ]; then
> + exit 1
> + fi
Is it possible to not have the nmblookup program? It seems to me it
would be safer to at least try the mount w/o the ip address if you can't
obtain one.
> +
> + ipaddress=$($NMBLOOKUP $key --debug-level=0 2>>/dev/null | grep '<00>'
> | awk '{ print $1 }')
> + if [ -z "$ipaddress" ]; then
> + exit 1
> + fi
> +
> + opts="-fstype=cifs,guest,ip=$ipaddress"
> +fi
>
> for P in /bin /sbin /usr/bin /usr/sbin
> do
Can we compress these two loops that do the same thing (determine the
path to the samba/cifs binaries)?
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Read-only map
"Steve Linn" <[EMAIL PROTECTED]> writes: > We had the same problem. The kernel we were running had a > "feature" where if the client mounts the same server and directory > it would bind them together. You would get RO or RW depending The RHEL 5.2 kernel does not have that issue. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Read-only map
Ondrej Valousek <[EMAIL PROTECTED]> writes: > Hi List, > > I have a problem: > My system (client, server) RHEL 5.2, latest updates. > 1. NFS server is exporting read/write share > 2. NIS automount map point to that share, but in read only like "key -ro > nfsserver:/share/key" > > Now, the "strange" thing is that on clients that share is mounted read > only, fine, but when I go to the nfsserver itself, the share is mounted > read write. I understand this is because mount --bind is used instead of > nfs for performance reasons, but this way we lose the -ro flag. > Is there any simple solution to this? Well, you could add -fstype=nfs. In olden days, you could specify -nosymlink. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] open_lookup:95: cannot open lookup module ldap
Nail El-Sourani <[EMAIL PROTECTED]> writes: > Hi Ian and list, > > i am on opensuse 10.3 and the packaged automounter version was 5.0.2 > which was not sufficient for me because of various bugs fixed in 5.0.3. > So i got the Source from the kernel.org archive with all 5.0.3 patches > and patch_order. applied and installed successfully, but receive the > following error messages in the syslog with autofs logging on "debug" > and no working automounts > > > automount[3347]: open_lookup:95: cannot open lookup module ldap > (/usr/lib/autofs/lookup_ldap.so: undefined symbol: > krb5_get_init_creds_keytab) > > > i could find SOME information about this being a problem with sasl and > krb packages not linked against ldap, but i have no idea what to do from > here? i think i even saw this a bug fixed in OLDER autofs version so im > a little confused now Do you have the krb5 libraries and development packages installed? It sounds like we need to update the configure script once we figure out what went wrong, here. Sorry for the inconvenience. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 2/2] autofs4 - fix string validation check order
Ian Kent <[EMAIL PROTECTED]> writes: > In function validate_dev_ioctl() we check that the string we've > been sent is a valid path. The function that does this check > assumes the string is NULL terminated but our NULL termination > check isn't done until after this call. This patch changes the > order of the check. > > Signed-off-by: Ian Kent <[EMAIL PROTECTED]> Acked-by: Jeff Moyer <[EMAIL PROTECTED]> ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 4/6] autofs4 - make autofs type usage explicit
Andrew Morton <[EMAIL PROTECTED]> writes: > On Thu, 23 Oct 2008 10:35:32 +0800 > Ian Kent <[EMAIL PROTECTED]> wrote: > >> This patch further improves autofs mount type usage and provides >> supplementry explanation of the changes made in the previous patch >> "autofs4 - cleanup autofs mount type usage". >> >> Changes introduced in "autofs4 - cleanup autofs mount type usage": >> >> - the type assigned at mount when no type is given is changed >> from 0 to AUTOFS_TYPE_INDIRECT. This was done because 0 and >> AUTOFS_TYPE_INDIRECT were being treated implicitly as the same >> type. >> >> - previously, an offset mount had it's type set to >> AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET but the mount control >> re-implementation needs to be able distinguish all three types. >> So this was changed to make the type setting explicit. >> >> - a type AUTOFS_TYPE_ANY was added for use by the re-implementation >> when checking if a given path is a mountpoint. It's not really a >> type as we use this to ask if a given path is a mountpoint in the >> autofs_dev_ioctl_ismountpoint() function. >> >> Changes introduced in this patch: >> >> - macros to set and test the autofs mount types have been added to >> improve readability and make the type usage explicit. > > ^^^ <<-- ?? Just for some background, I requested a change here. The reason is that I ran into problems in the user space daemon where there was this notion of a bitfield that wasn't always treated as a bitfield. So AUTOFS_TYPE_ANY should be all bits set, right? Nope. Some places in the code tested with binary operators, others with ==. It was confusing and error-prone. The accessor functions at least normalize the interface. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs & system libnss* libraries
Ondrej Valousek <[EMAIL PROTECTED]> writes: >> >> No! >> >> I considered that at the outset of version 5 development and decided >> against it after working on integrating the outdated code that was >> included in the nss_ldap distribution. Unless the situation changes >> significantly then I'm not likely to change my mind on this. >> > Does it mean that the nss_ldap is heavily outdated then? >> I would have to write the nss code for "all" the possible sources >> against a an API that is difficult to write for, partly because the >> interface documentation is lousy. Not to mention that I'd then be at the >> mercy of nss_ldap changes and bugs, and autofs would depend on a >> configuration file that it doesn't control. >> > My primary concern was why should we (linux distro maintainers) support > 2 things essentially doing the same? > I did not mean you specifically. Maintaining the libnss* libraries > should be (probably) job for someone else - you keep focused on the > autofs-specific tasks. > And if you think your nss_ldap is better, why should not it serve other > purposes (like gathering user info from LDAP repository), too? > > I mean, from the longer perspective, I believe we should merge these > things. It is neither elegant nor transparent for normal sysadmins. You have to understand that nss doesn't actually support the interfaces autofs needs. We would have to extend the API and get that approved by the libc folks (which they have actually agreed to do, should we choose that route). Now, the reason autofs doesn't use the SASL and TLS configuration options from the ldap.conf file is simply that autofs has no business parsing that file. Autofs *does* use the ldap library, so whatever you've configured in /etc/openldap/ldap.conf should work for autofs. I hope this helps. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] 'browse mode' issue
Guillaume Rousse <[EMAIL PROTECTED]> writes: > Hello list. I've several questions about browse mode option. > > First, I have opposite reports about the effects of 'browse mode' option > in automount configuration. Some times ago, a user reported than setting > it to 'no' was CPU-unfriendly, so we turned it to 'yes' by default in That's the first time I've ever heard that! What data did your user use to support that conclusion? > However, I now have another report than allowing browse was harmful on > large networks, causing lots of IP collisions. My knowledge in this area is dated, sadly. I'll let Ian address the specific implementation details. > So, I'm curious at what should be a good default value for this option. > > Second, having a look at the code, it seems 'yes' is the default in the > binary, but, but default configuration file set it to 'no', which is > quite disturbing. If there is a good default value for this option (and > even if there was not), I'd rather have consistent default values in > both places. Well, for RHEL at least, we wanted to make things continue to work as they did before. That means configuring autofs to default to nobrowse. I'm not sure why the daemon defaults to browsing. > Last issue, I can't find a correct description on what this option does > exactly anywhere :) http://docs.sun.com/app/docs/doc/816-0211/6m6nc66nc?a=view Scroll down to the section entitled, "Browsing." Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] latest autofs from centos 4
Joe Pruett <[EMAIL PROTECTED]> writes: >>> well, it's a production box and only seems to show the problem at boot >>> time. from looking at the logs, i think this is the underlying >>> culprit: >>> >>> Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). >>> Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. >>> Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server >>> jupiter.spiretech.com >>> Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). >>> Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. >>> Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server >>> jupiter.spiretech.com >> >>> that is from the client trying to talk to the server. >> >> That's strange. Errno 98 is EADDRINUSE. So, this means that you cycled >> through the entire port range and all of the ports were bound. Do you >> do a lot of mounts upon boot? Can you try tweaking sunrpc.min_resvport >> and sunrpc.max_resvport? Max can't be more than 1023. Try pushing min >> down to 500 or so. > > i have run into this kind of problem in the past (running out of > privileged ports). i found some code in glibc that seemed to be the > biggest problem and never got around to trying to fix it. i'll look > at what my current settings are and see about tweaking them. Details would be welcome. The biggest offender we found was that the portmapper interfaces would use reserved ports. That is simply not necessary, and those issues have been fixed in autofs and mount.nfs. In fact, we've got regression tests that make sure that this is the case. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] latest autofs from centos 4
Joe Pruett <[EMAIL PROTECTED]> writes: >> Yep, gather a debug log and include the other pertinent information >> from: >> http://people.redhat.com/~jmoyer/ > > well, it's a production box and only seems to show the problem at boot > time. from looking at the logs, i think this is the underlying > culprit: > > Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). > Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. > Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server > jupiter.spiretech.com > Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). > Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. > Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server > jupiter.spiretech.com > that is from the client trying to talk to the server. That's strange. Errno 98 is EADDRINUSE. So, this means that you cycled through the entire port range and all of the ports were bound. Do you do a lot of mounts upon boot? Can you try tweaking sunrpc.min_resvport and sunrpc.max_resvport? Max can't be more than 1023. Try pushing min down to 500 or so. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] latest autofs from centos 4
Ian Kent <[EMAIL PROTECTED]> writes: > On Wed, 2008-09-17 at 09:22 -0700, Joe Pruett wrote: >> i am still having some kind of issue where at boot time, it can't seem to >> find a server or talk to mountd or something like that and then won't try >> again. it looks like maybe this is the negative caching feature? is that >> new as well? > > Jeff is more familiar with the RHEL-4 v4 code than I am, I'll have to > leave this to him. In any case we'd need to see a debug log. Yep, gather a debug log and include the other pertinent information from: http://people.redhat.com/~jmoyer/ Thanks, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] latest autofs from centos 4
Joe Pruett <[EMAIL PROTECTED]> writes: > On Wed, 17 Sep 2008, Ian Kent wrote: > >> On Tue, 2008-09-16 at 17:22 -0700, Joe Pruett wrote: >>> it looks like some recent changes to both autofs v4 and v5 has caused the >>> siogcifconf buffer to be only 128 bytes. this means that on our servers, >>> it can't correctly match a local address since that is only enough room >>> for 3 addresses and we're in the middle of a renumbering so we have 5-10 >>> addresses per machine. this was working fine until i just updated to >>> centos 4.7. from looking at the code, it looks like someone created a >>> MAX_IF_BUF #define at 2048, but didn't use it for the ioctl call. is that >>> a mistake? >>> >>> i'll try a patched rpm locally and make sure this is the source of my >>> woes. >> >> Yeah, known issue. >> It's resolved in RHEL-5.3. > > it seems like it got worse with the latest 4.7 stuff. maybe i just didn't > notice machines talking to themselves over nfs previously. has it always > been 128 bytes? It may have regressed, if that was the update that pulled in the v5 version of the replicated server handling code. > i'm concerned about the patch for my web hosting machine. right now it > has over 1024 interfaces. the amount of time all that malloc/free is > going to take for every mount seems pretty expensive. would any kind of > caching make sense? There's no doubt that we could be smarter about this. It may be enough to make last_len in alloc_ifreq a static. Ian, what do you think about doing that? But honestly, malloc/free is pretty cheap. I doubt you'll see performance problems due to that. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Execute script on expire.
Alexander <[EMAIL PROTECTED]> writes: > 2008/9/12 Jeff Moyer <[EMAIL PROTECTED]>: >> Alexander <[EMAIL PROTECTED]> writes: >> >>> Hello mailing list, >>> >>> was looking everywhere and could find info on whether or not autofs 4 >>> or 5 has a feature of executing designated script on expire, just >>> before unmounting. >> >> The short answer is no. > Is it somewhere in the development plans or will never be implemented by > design? I believe there was one other requestor of this feature. The tricky part is defining the map syntax and not breaking compatibility. There is also the question of semantics with offset mounts. If someone is motivated enough to come up with a proposal for the syntax and semantics, I'm sure Ian and I can find some time to review it. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Execute script on expire.
Alexander <[EMAIL PROTECTED]> writes: > Hello mailing list, > > was looking everywhere and could find info on whether or not autofs 4 > or 5 has a feature of executing designated script on expire, just > before unmounting. The short answer is no. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Autofs doesn't look at second LDAP server
"Coe, Colin C. (Unix Engineer)" <[EMAIL PROTECTED]> writes: > Doh. Sorry, I was trying to sanitise the logs. Aether is ldap2. Aer > is ldap1. > > The full debug log is ~800MB in size, how would you like it? > > CC > >> -Original Message- >> From: Ian Kent [mailto:[EMAIL PROTECTED] >> Sent: Thursday, 17 July 2008 11:14 AM >> To: Coe, Colin C. (Unix Engineer) >> Cc: autofs@linux.kernel.org >> Subject: Re: [autofs] Autofs doesn't look at second LDAP server >> >> >> On Wed, 2008-07-16 at 09:20 +0800, Coe, Colin C. (Unix >> Engineer) wrote: >> > Jul 13 04:03:01 las006 automount[31280]: parse_ldap_config: >> > lookup(ldap): user: (null), secret: unspecified, client principal: >> > (null) credential cache: (null) >> > Jul 13 04:03:01 las006 automount[31280]: parse_ldap_config: >> > lookup(ldap): user: (null), secret: unspecified, client principal: >> > (null) credential cache: (null) >> > Jul 13 04:03:01 las006 automount[31280]: find_server: trying server >> > ldaps://aether.woodside.com.au:636 >> > Jul 13 04:03:01 las006 automount[31280]: find_server: trying server >> > ldaps://aether.woodside.com.au:636 >> >> I wonder if it's getting the server from the config at all? >> It should be. >> >> LDAP_URI="ldaps://ldap2.woodside.com.au:636 >> ldaps://ldap1.woodside.com.au:636" >> >> given that the name here is different from the one being used. >> Can you send the full debug log to me please. >> >> But that's probably another issue. >> >> Ian Was this ever resolved? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Unexpected autofs behaviour
Sorry for the late response. I don't think anyone responded yet, right? Michael Coffman <[EMAIL PROTECTED]> writes: > I have a question about the behaviour of autofs. It seems like it is > very easy to hit a situation where autofs will unmount a file system > and an active process will lose access to a file and fail to read it. > This seems to happen with both direct and indirect mapping. > > Specifics about what I am running: > > autofs-4.1.3-199.3 > kernel - 2.6.9-55.ELsmp > arch - x86_64 > OS - Red Hat Enterprise Linux WS release 4 (Nahant Update 5 > > autofs is configured to use the defaults and has host mapping > enabled. When I run the following simple test: > >date;while [[ -r /net/hostname/test ]]; do :; done; date > > command output: >Fri Jul 11 09:02:46 MDT 2008 >Fri Jul 11 09:03:59 MDT 2008 > command output run 2: >Fri Jul 11 09:11:42 MDT 2008 >Fri Jul 11 09:12:45 MDT 2008 > > As you can see, I lose read access typically shortly after the mount is > supposed to time out. Yeah, this looks like one of the race conditions that Ian's been closing up recently. I think you'll need to test with a newer kernel, where newer means your distribution hasn't even released it yet. Ian may be able to provide a test kernel, I'm not sure. Ian, did you get everything backported to a test tree? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs design doc ?
Thierry BULTEL <[EMAIL PROTECTED]> writes: > Hi all, > > I am currently looking at autofs, and I would be interested to know if > there exist such a documentation. Namely, I am performing a kind of > reverse-engineering on both the daemon and the kernel parts. This will give you the general overview: http://people.redhat.com/~jmoyer/autofs-linux_kongress-2005.pdf A slightly newer one is available in the OLS 2006 proceedings, here: http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf > What I would like to understand, above all, is the detailed interaction > scheme between automount and the kernel. See above, ask questions after you've read that. > I have understood that automount was receiving orders through a pipe, > and replying with ioctls, but I still do not have the complete vision > of the nature and timing of the messages. What are the respective > responsibilities of both parts ? Also, I am still asking myself why a > user daemon is used, and why not everything is not done in the kernel. The autofs file system traps lookup requests. It then passes the requests on to the userspace daemon to perform the actual lookup of the key in the automount map and to then perform the mount. This is done in a userspace daemon because it is too complex to be handled in the kernel. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Autofs 4->5 with LDAP problems
Rob Horton <[EMAIL PROTECTED]> writes: > Hi, > > I'm having problems getting autofs5 to work with LDAP. We have a setup > which works fine with autofs4 clients. Initially automount was > complaining that it could not find the auto.master information, but > after fiddling with the DEFAULT_MAP_OBJECT_CLASS etc entries it starts > without error but doesn't appear to actually do anything (and there is > no automount process). Despite turning on debugging and giving the -v > and -d options I can't get any useful logging to find out what the > problem is. Here's a sample of the LDAP objects: > > # auto.master, maths.qmul.ac.uk > dn: ou=auto.master,dc=maths,dc=qmul,dc=ac,dc=uk > ou: auto.master > objectClass: top > objectClass: automountMap > > # /misc, auto.master, maths.qmul.ac.uk > dn: cn=/misc,ou=auto.master,dc=maths,dc=qmul,dc=ac,dc=uk > objectClass: automount > automountInformation: ldap:ou=auto.misc,dc=maths,dc=qmul,dc=ac,dc=uk > -browse > cn: /misc > > # orac_raid0, auto.misc, maths.qmul.ac.uk > dn: cn=orac_raid0,ou=auto.misc,dc=maths,dc=qmul,dc=ac,dc=uk > objectClass: automount > cn: orac_raid0 > automountInformation: > -rw,hard,rsize=32768,wsize=32768,tcp,lock,intr,quota > orac:/orac/raid0 > > > /etc/sysconfig/autofs: > > DEFAULT_MAP_OBJECT_CLASS="automountMap" > DEFAULT_ENTRY_OBJECT_CLASS="automount" > DEFAULT_MAP_ATTRIBUTE="ou" > DEFAULT_ENTRY_ATTRIBUTE="automountInformation" > DEFAULT_VALUE_ATTRIBUTE="automountInformation" > OPTIONS="--debug" > > We're running autofs-5.0.1 from Scientific Linux (RHEL clone) 5.1. I'd > be grateful if anyone can spot a problem with the setup, or at least > suggest how to get some more verbose output. http://people.redhat.com/jmoyer contains instructions for gathering debug logs. Please provide them here when you have them. Please also give the *exact* version of autofs you are running. rpm -q autofs should do the trick. automount -V would also be useful, given we don't know how your distribution builds it. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] LDAP-based "auto.net" for /net
Jeff Blaine <[EMAIL PROTECTED]> writes: > Jeff Moyer wrote: >> [EMAIL PROTECTED] writes: >> >>> If anyone has been successful in getting /net/hostname >>> automounting working with LDAP-based autofs maps (not >>> a local /etc/auto.net file), I would love to see your >>> LDIF information showing how you configured it. >> >> First, program maps must be on a file system. Second, are you using >> autofs version 4 or 5? > > AutoFS 5. > >> If 5, then you can simply use the ldif equivalent of: >> /net -hosts > > That's what I am trying to do :) I was hoping someone could > show me theirs. It's not clear to me how to construct that > particular set of LDIF info. OK, what schema are you using? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] LDAP-based "auto.net" for /net
[EMAIL PROTECTED] writes: > If anyone has been successful in getting /net/hostname > automounting working with LDAP-based autofs maps (not > a local /etc/auto.net file), I would love to see your > LDIF information showing how you configured it. First, program maps must be on a file system. Second, are you using autofs version 4 or 5? If 5, then you can simply use the ldif equivalent of: /net -hosts > PS: wiki.autofs.net might as well be taken off the net. > It contains absolutely nothing of worth other than > a link to the mailing list stuff. It hasn't exactly been publicized because those working on it (Ian and myself) haven't had time to make it useful. Sorry. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Auto Unmount???
Thanh Tran <[EMAIL PROTECTED]> writes: > I did notice some timeout values in my sysconf/autofs. I thought > those flags set the amount of time autofs would try to mount something > before giving up. Which flag sets the timeout? Perhaps, you mean the > option flag? Thanks. The timeout specifies the length of inactivity before a mount is expired. Please see the man page for auto.master. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Is Autofs 5 Slower Than 4
Thanh Tran <[EMAIL PROTECTED]> writes: > I upgraded my entire OS from Fedora 5 to 8. By slow, I mean around 20 > seconds to detect and mount. There are too many variables. I was > hoping it would be a simple polling flag that could be switched in > autofs. I can live with the slower time. I did notice that it took a > long time only when I physically removed the drive and re-inserted the > drive. When I use the "umount" command and not remove the drive, I > can quickly change directory back to drive and it mounts in like 2 > seconds at most. Thanks for the help. I'm still a little unclear on your use case. Are you sure you're using autofs to mount your (usb?) drive? This is typically handled by hal in newer distributions. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Is Autofs 5 Slower Than 4
Thanh Tran <[EMAIL PROTECTED]> writes: > The Autofs automounting was never blazing fast. However, autofs 5 > seems much slower than the previous version. It takes a long time for > autofs to mount my detachable drives. It eventually happens; it just > takes a long time. Is there a way to improve this speed? Thanks. Could you quantify this? What exactly are you doing? Are you sure autofs is the cause of the sluggishness? Did you upgrade your entire operating system or just autofs from version 4 to 5? Can you provide a debug log? Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Auto Unmount???
Thanh Tran <[EMAIL PROTECTED]> writes: > Is auto unmounting supported in autofs version 5? If so, how do you set the > timeout? You can either set it per mount point or globally. Per mount point requires a --timeout=X on the line for the mount point in the master map. Globally, it can be set in /etc/sysconfig/autofs (on systems that use the sysconfig directory). Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter hangs...
Ondrej Valousek <[EMAIL PROTECTED]> writes: > Hi List, > > I have strange error (RHEL-4, autofs 4.1.3-234). Using automounter to > mount home directories for users. After a while, /home got unusable and > I see the following: > > root 17345 20453 0 10:33 ?00:00:00 [automount] > root 17348 20453 0 10:33 ?00:00:00 [automount] > root 20453 1 0 Aug05 ?00:00:15 /usr/sbin/automount > --timeout=60 --debug /home yp auto.home -rw > > > I can not kill any of the processes listed (tried even kill -9). > The last I can see in /var/log/messages is the following: > Aug 11 10:32:39 login01 automount[17100]: expired /home/login > Aug 11 10:33:01 login01 automount[20453]: attempting to mount entry > /home/login > Aug 11 10:33:01 login01 automount[17185]: mount(nfs): mounted > belfast:/vol/users/users/login on /home/login > Aug 11 10:33:09 login01 automount[17346]: expired /home/localmgr > Aug 11 10:33:09 login01 automount[17348]: expired /home/support > > Maybe, the processes 17346 and 17348 failed to unmount /home/support and > /home/localmgr. This perhaps caused even the parent process 20453 to hang. > > Has anyone seen anything similar? Is there any solution to this? > Thanks, It rings a bell, but I can't put my finger on it. Can you reproduce this? If so, could you send along a debug log? Instructions for collecting debug information can be found at: http://people.redhat.com/~jmoyer/ Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 7/7] autofs4 - remove unused ioctls
Ian Kent <[EMAIL PROTECTED]> writes: > The ioctls AUTOFS_IOC_TOGGLEREGHOST and AUTOFS_IOC_ASKREGHOST were > added several years ago but what they were intended for has never > been implemented (as far as I'm aware noone uses them) so remove them. Yeah, the only other consumer of the autofs interfaces (that I know) is autodir, and that doesn't use the reghost ioctls. > Signed-off-by: Ian Kent <[EMAIL PROTECTED]> Reviewed-by: Jeff Moyer <[EMAIL PROTECTED]> ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 5/7] autofs4 - fix direct mount pending expire race
Ian Kent <[EMAIL PROTECTED]> writes:
> For direct and offset type mounts that are covered by another mount
> we cannot check the AUTOFS_INF_EXPIRING flag during a path walk
> which leads to lookups walking into an expiring mount while it is
> being expired.
>
> For example, for the direct multi-mount map entry with a couple of
> offsets:
>
> /race/mm1 / :/
>/om1 :/
>/om2 :/
>
> an autofs trigger mount is mounted on /race/mm1 and when accessed
> it is over mounted and trigger mounts made for /race/mm1/om1 and
> /race/mm1/om2. So it isn't possible for path walks to see the
> expiring flag at all and they happily walk into the file system
> while it is expiring.
>
> When expiring these mounts follow_down() must stop at the autofs
> mount and all processes must block in the ->follow_link() method
> (except the daemon) until the expire is complete. This is done by
> decrementing the d_mounted field of the autofs trigger mount root
> dentry until the expire is completed. In ->follow_link() all
> processes wait on the expire and the mount following is completed
> for the daemon until the expire is complete.
>
> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
>
> ---
>
> fs/autofs4/autofs_i.h |3 ++
> fs/autofs4/expire.c | 16 +--
> fs/autofs4/root.c | 72
> +
> 3 files changed, 65 insertions(+), 26 deletions(-)
>
>
> diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
> index 5d90ed3..4b40cbc 100644
> --- a/fs/autofs4/autofs_i.h
> +++ b/fs/autofs4/autofs_i.h
> @@ -52,6 +52,8 @@ struct autofs_info {
>
> int flags;
>
> + struct completion expire_complete;
> +
> struct list_head active;
> struct list_head expiring;
>
> @@ -69,6 +71,7 @@ struct autofs_info {
> };
>
> #define AUTOFS_INF_EXPIRING (1<<0) /* dentry is in the process of expiring
> */
> +#define AUTOFS_INF_MOUNTPOINT(1<<1) /* mountpoint status for direct
> expire */
>
> struct autofs_wait_queue {
> wait_queue_head_t queue;
> diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> index 19f5bea..705b9f0 100644
> --- a/fs/autofs4/expire.c
> +++ b/fs/autofs4/expire.c
> @@ -259,13 +259,15 @@ static struct dentry *autofs4_expire_direct(struct
> super_block *sb,
> now = jiffies;
> timeout = sbi->exp_timeout;
>
> - /* Lock the tree as we must expire as a whole */
> spin_lock(&sbi->fs_lock);
> if (!autofs4_direct_busy(mnt, root, timeout, do_now)) {
> struct autofs_info *ino = autofs4_dentry_ino(root);
> -
> - /* Set this flag early to catch sys_chdir and the like */
> + if (d_mountpoint(root)) {
> + ino->flags |= AUTOFS_INF_MOUNTPOINT;
> + root->d_mounted--;
> + }
This makes me uneasy. This should take d_mounted to zero. Then, when
the daemon actually does the unmount, won't the d_mounted drop below
zero? Following calls to d_mountpoint will return a negative value, but
everyone treats it as a boolean, so it will evaluate to true for a brief
time. Or did I miss something?
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 4/7] autofs4 - fix indirect mount pending expire race
Ian Kent <[EMAIL PROTECTED]> writes:
> On Fri, 2008-07-18 at 14:52 -0400, Jeff Moyer wrote:
>> Ian Kent <[EMAIL PROTECTED]> writes:
>> >} else {
>> > + /* Path walk currently on this dentry? */
>> > + ino_count = atomic_read(&ino->count) + 1;
>> > + if (atomic_read(&dentry->d_count) > ino_count)
>> > + goto next;
>> > +
>> >expired = autofs4_check_leaves(mnt, dentry, timeout,
>> > do_now);
>> >if (expired) {
>> >dput(dentry);
>
> The expired dentry may be a different dentry!
>
>> > found:
>> >DPRINTK("returning %p %.*s",
>> >expired, (int)expired->d_name.len, expired->d_name.name);
>> > + ino = autofs4_dentry_ino(expired);
>>
>> If we get here, ino is already set to the autofs4_dentry_ino(expired),
>> so this statement is redundant.
>
> Almost but see above.
Ah, you're right, I missed that.
Cheers,
Jeff
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 4/7] autofs4 - fix indirect mount pending expire race
DPRINTK("returning %p %.*s",
> expired, (int)expired->d_name.len, expired->d_name.name);
> + ino = autofs4_dentry_ino(expired);
If we get here, ino is already set to the autofs4_dentry_ino(expired),
so this statement is redundant.
[...]
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index 2944b28..2ed2a51 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -133,7 +133,10 @@ static int try_to_fill_dentry(struct dentry *dentry, int
> flags)
> /* Block on any pending expiry here; invalidate the dentry
> when expiration is done to trigger mount request with a new
> dentry */
> - if (ino && (ino->flags & AUTOFS_INF_EXPIRING)) {
> + spin_lock(&sbi->fs_lock);
> + if (ino->flags & AUTOFS_INF_EXPIRING) {
> + spin_unlock(&sbi->fs_lock);
> +
> DPRINTK("waiting for expire %p name=%.*s",
>dentry, dentry->d_name.len, dentry->d_name.name);
This is okay, since we wait on the AUTOFS_INF_EXPIRING flag in
validate_request. That check is done outside the lock, but I doubt
there are issues with not seeing an update since you perform a schedule
there.
> @@ -149,8 +152,11 @@ static int try_to_fill_dentry(struct dentry *dentry, int
> flags)
> status = d_invalidate(dentry);
> if (status != -EBUSY)
> return -EAGAIN;
> - }
>
> + goto cont;
> + }
> + spin_unlock(&sbi->fs_lock);
> +cont:
> DPRINTK("dentry=%p %.*s ino=%p",
>dentry, dentry->d_name.len, dentry->d_name.name,
> dentry->d_inode);
>
> @@ -229,15 +235,21 @@ static void *autofs4_follow_link(struct dentry *dentry,
> struct nameidata *nd)
> goto done;
>
> /* If an expire request is pending wait for it. */
> - if (ino && (ino->flags & AUTOFS_INF_EXPIRING)) {
> + spin_lock(&sbi->fs_lock);
> + if (ino->flags & AUTOFS_INF_EXPIRING) {
> + spin_unlock(&sbi->fs_lock);
> +
> DPRINTK("waiting for active request %p name=%.*s",
> dentry, dentry->d_name.len, dentry->d_name.name);
>
> status = autofs4_wait(sbi, dentry, NFY_NONE);
>
> DPRINTK("request done status=%d", status);
> - }
>
> + goto cont;
> + }
> + spin_unlock(&sbi->fs_lock);
> +cont:
could've done an:
} else
spin_unlock(&sbi->fs_lock);
But, whatever...
Reviewed-by: Jeff Moyer <[EMAIL PROTECTED]>
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 3/7] autofs4 - fix pending checks
Ian Kent <[EMAIL PROTECTED]> writes:
> There are two cases for which a dentry that has a pending mount request
> does not wait for completion. One is via autofs4_revalidate() and the
> other via autofs4_follow_link().
>
> In revalidate, after the mount point directory is created, but before
> the mount is done, the check in try_to_fill_dentry() can can fail to
> send the dentry to the wait queue since the dentry is positive and the
> lookup flags may contain only LOOKUP_FOLLOW. Although we don't trigger
> a mount for the LOOKUP_FOLLOW flag, if ther's one pending we might as
> well wait and use the mounted dentry for the lookup.
>
> In autofs4_follow_link() the dentry is not checked to see if it is
> pending so it may fail to call try_to_fill_dentry() and not wait
> for mount completion.
>
> A dentry that is pending must always be sent to the wait queue.
>
> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Reviewed-by: Jeff Moyer <[EMAIL PROTECTED]>
>
> ---
>
> fs/autofs4/root.c |9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
>
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index e842b0a..2944b28 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -177,7 +177,8 @@ static int try_to_fill_dentry(struct dentry *dentry, int
> flags)
> return status;
> }
> /* Trigger mount for path component or follow link */
> - } else if (flags & (TRIGGER_FLAGS | TRIGGER_INTENTS) ||
> + } else if (dentry->d_flags & DCACHE_AUTOFS_PENDING ||
> + flags & (TRIGGER_FLAGS | TRIGGER_INTENTS) ||
> current->link_count) {
> DPRINTK("waiting for mount name=%.*s",
> dentry->d_name.len, dentry->d_name.name);
> @@ -223,7 +224,8 @@ static void *autofs4_follow_link(struct dentry *dentry,
> struct nameidata *nd)
>
> /* If it's our master or we shouldn't trigger a mount we're done */
> lookup_type = nd->flags & (TRIGGER_FLAGS | TRIGGER_INTENTS);
> - if (oz_mode || !lookup_type)
> + if (oz_mode ||
> + !(lookup_type || dentry->d_flags & DCACHE_AUTOFS_PENDING))
> goto done;
>
> /* If an expire request is pending wait for it. */
> @@ -242,7 +244,8 @@ static void *autofs4_follow_link(struct dentry *dentry,
> struct nameidata *nd)
>* don't try to mount it again.
>*/
> spin_lock(&dcache_lock);
> - if (!d_mountpoint(dentry) && __simple_empty(dentry)) {
> + if (dentry->d_flags & DCACHE_AUTOFS_PENDING ||
> + (!d_mountpoint(dentry) && __simple_empty(dentry))) {
> spin_unlock(&dcache_lock);
>
> status = try_to_fill_dentry(dentry, 0);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 2/7] autofs4 - cleanup redundant readir code
Ian Kent <[EMAIL PROTECTED]> writes:
> The mount triggering functionality of readdir and related functions
> is no longer used (and is quite broken as well). The unused portions
> have been removed.
I agree that this should be safe (and I also agree that the code was
broken!), but I'm not sure why you say that the code was no longer used.
It was still wired up until this patch, right?
Anyway:
Acked-by: Jeff Moyer <[EMAIL PROTECTED]>
>
> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
>
> ---
>
> fs/autofs4/root.c | 149
> ++---
> 1 files changed, 16 insertions(+), 133 deletions(-)
>
>
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index 2a1a631..e842b0a 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -25,8 +25,6 @@ static int autofs4_dir_rmdir(struct inode *,struct dentry
> *);
> static int autofs4_dir_mkdir(struct inode *,struct dentry *,int);
> static int autofs4_root_ioctl(struct inode *, struct file *,unsigned
> int,unsigned long);
> static int autofs4_dir_open(struct inode *inode, struct file *file);
> -static int autofs4_dir_close(struct inode *inode, struct file *file);
> -static int autofs4_dir_readdir(struct file * filp, void * dirent, filldir_t
> filldir);
> static int autofs4_root_readdir(struct file * filp, void * dirent, filldir_t
> filldir);
> static struct dentry *autofs4_lookup(struct inode *,struct dentry *, struct
> nameidata *);
> static void *autofs4_follow_link(struct dentry *, struct nameidata *);
> @@ -44,9 +42,9 @@ const struct file_operations autofs4_root_operations = {
>
> const struct file_operations autofs4_dir_operations = {
> .open = autofs4_dir_open,
> - .release= autofs4_dir_close,
> + .release= dcache_dir_close,
> .read = generic_read_dir,
> - .readdir= autofs4_dir_readdir,
> + .readdir= dcache_readdir,
> };
>
> const struct inode_operations autofs4_indirect_root_inode_operations = {
> @@ -98,17 +96,7 @@ static int autofs4_root_readdir(struct file *file, void
> *dirent,
> static int autofs4_dir_open(struct inode *inode, struct file *file)
> {
> struct dentry *dentry = file->f_path.dentry;
> - struct vfsmount *mnt = file->f_path.mnt;
> struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> - struct dentry *cursor;
> - int status;
> -
> - status = dcache_dir_open(inode, file);
> - if (status)
> - goto out;
> -
> - cursor = file->private_data;
> - cursor->d_fsdata = NULL;
>
> DPRINTK("file=%p dentry=%p %.*s",
> file, dentry, dentry->d_name.len, dentry->d_name.name);
> @@ -116,129 +104,24 @@ static int autofs4_dir_open(struct inode *inode,
> struct file *file)
> if (autofs4_oz_mode(sbi))
> goto out;
>
> - if (autofs4_ispending(dentry)) {
> - DPRINTK("dentry busy");
> - dcache_dir_close(inode, file);
> - status = -EBUSY;
> - goto out;
> - }
> -
> - status = -ENOENT;
> - if (!d_mountpoint(dentry) && dentry->d_op &&
> dentry->d_op->d_revalidate) {
> - struct nameidata nd;
> - int empty, ret;
> -
> - /* In case there are stale directory dentrys from a failed
> mount */
> - spin_lock(&dcache_lock);
> - empty = list_empty(&dentry->d_subdirs);
> + /*
> + * An empty directory in an autofs file system is always a
> + * mount point. The daemon must have failed to mount this
> + * during lookup so it doesn't exist. This can happen, for
> + * example, if user space returns an incorrect status for a
> + * mount request. Otherwise we're doing a readdir on the
> + * autofs file system so just let the libfs routines handle
> + * it.
> + */
> + spin_lock(&dcache_lock);
> + if (!d_mountpoint(dentry) && __simple_empty(dentry)) {
> spin_unlock(&dcache_lock);
> -
> - if (!empty)
> - d_invalidate(dentry);
> -
> - nd.flags = LOOKUP_DIRECTORY;
> - ret = (dentry->d_op->d_revalidate)(dentry, &nd);
> -
> - if (ret <= 0) {
> - if (ret < 0)
> - status = ret;
> - dcache_dir_close(inode, file);
> - goto out;
> - }
> + return -ENOENT;
> }
> + spin_unlock(&dcache_lock);
>
> - if
Re: [autofs] [PATCH 1/7] autofs4 - indirect dentry must almost always be positive
Ian Kent <[EMAIL PROTECTED]> writes:
> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Reviewed-by: Jeff Moyer <[EMAIL PROTECTED]>
Cheers,
Jeff
>
> ---
>
> fs/autofs4/waitq.c | 17 ++---
> 1 files changed, 14 insertions(+), 3 deletions(-)
>
>
> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> index bcb6c52..35216d1 100644
> --- a/fs/autofs4/waitq.c
> +++ b/fs/autofs4/waitq.c
> @@ -328,9 +328,20 @@ int autofs4_wait(struct autofs_sb_info *sbi, struct
> dentry *dentry,
> if (sbi->catatonic)
> return -ENOENT;
>
> - if (!dentry->d_inode &&
> - (sbi->type & (AUTOFS_TYPE_DIRECT | AUTOFS_TYPE_OFFSET)))
> - return -ENOENT;
> + if (!dentry->d_inode) {
> + /*
> + * A wait for a negative dentry is invalid for certain
> + * cases. A direct or offset mount "always" has its mount
> + * point directory created and so the request dentry must
> + * be positive or the map key doesn't exist. The situation
> + * is very similar for indirect mounts except only dentrys
> + * in the root of the autofs file system may be negative.
> + */
> + if (sbi->type & (AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET))
> + return -ENOENT;
> + else if (!IS_ROOT(dentry->d_parent))
> + return -ENOENT;
> + }
>
> name = kmalloc(NAME_MAX + 1, GFP_KERNEL);
> if (!name)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] How can I synchronize among different nfs clients?
"Kun Niu" <[EMAIL PROTECTED]> writes: > Dear all, > I'm using nfs among different computers which have ubuntu 8.04 installed. > I found it worked fine until much of memory used by cache almost used > my memory up. > After that, the directory I made on one computer didn't appear on other ones. > Are there any log I can track to solve the problem? > Thanks in advance for any advice. First, this post belongs on [EMAIL PROTECTED] Second, you'll want to provide the kernel version you are using and a better problem description. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH] autofs4 - detect invalid direct mount requests
Ian Kent <[EMAIL PROTECTED]> writes: > On Tue, 2008-07-01 at 14:17 -0700, Andrew Morton wrote: >> On Fri, 20 Jun 2008 13:13:03 +0800 >> Ian Kent <[EMAIL PROTECTED]> wrote: >> >> > autofs v5 dierct and offset mounts within an autofs filesystem are >> > triggered by existing autofs triger mounts so the mount point dentry >> > must be positive. If the mount point dentry is negative then the >> > trigger doesn't exist so we can return fail immediately. >> > >> > Signed-off-by: Ian Kent <[EMAIL PROTECTED]> >> > >> > --- >> > >> > fs/autofs4/waitq.c |4 >> > 1 files changed, 4 insertions(+), 0 deletions(-) >> > >> > >> > diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c >> > index cd21fd4..ae637d9 100644 >> > --- a/fs/autofs4/waitq.c >> > +++ b/fs/autofs4/waitq.c >> > @@ -307,6 +307,10 @@ int autofs4_wait(struct autofs_sb_info *sbi, struct >> > dentry *dentry, >> >if (sbi->catatonic) >> >return -ENOENT; >> > >> > + if (!dentry->d_inode && >> > + (sbi->type & (AUTOFS_TYPE_DIRECT | AUTOFS_TYPE_OFFSET))) >> > + return -ENOENT; >> > + >> >name = kmalloc(NAME_MAX + 1, GFP_KERNEL); >> >if (!name) >> >return -ENOMEM; >> >> A good changelog would allow little old me to determine whether this >> patch should be merged into 2.6.25 and/or 2.6.26 and/or 2.6.27. This >> wasn't a good changelog :( > > Sorry, I guess I shouldn't have included it along with the other more > serious bug fixes. It gets rid of an annoyance more than anything as the > daemon still has to check for it. > > It isn't important or urgent, just useful. And I'd still like to see a comment in there! ;) -jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] automount in status D
Ian Kent <[EMAIL PROTECTED]> writes: > On Fri, 2008-06-27 at 13:35 +0200, Carsten Aulbert wrote: >> >> Ian Kent wrote: >> >> >> Any idea how this happened? >> > >> > It's been a long time since I've seen this reported. >> > What distro and kernel? >> > >> >> Sorry, Debian Etch with self compiled kernel: >> h2:~# uname -a >> Linux h2 2.6.24.4-storage #1 SMP Sun Apr 20 09:33:42 CEST 2008 x86_64 >> x86_64 x86_64 GNU/Linux >> h2:~# apt-cache show autofs|grep Version >> Version: 4.1.4-13 >> >> >> Any idea how to get this resolved (possibly without a reboot)? >> > >> > There is nothing you can do if the process is stuck in an >> > uninterruptible state in the kernel. >> >> Well, as bad as I feared it to be :( >> >> Thanks already, reboot is already announced to the users. Anything I >> might help you with to corner that bug? > > Aggh .. it's been s long since I've heard of this happening I can't > remember. A sysrq-t would be a good starting point. -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Direct mount newbie question
"Stephen Biggs" <[EMAIL PROTECTED]> writes: >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jim Carter >> Sent: Wednesday, June 25, 2008 5:07 PM >> To: Stephen Biggs >> Cc: autofs@linux.kernel.org >> Subject: Re: [autofs] Direct mount newbie question ... > The only time this becomes a problem is when it tries to open > /home/.junk. This triggers the automounter to go across the net to find > the directory in the map. I may be wrong about any NFS chatter. In any > case, this access of the map across the network can take up to 300 ms to > query and then return a failure. > > It has nothing to do with which user is running. The problem is that "Q" > is stupidly written and does this futile search many, MANY times in the > running of a job, not taking no for an answer. Again, as I said before, > I have no control over this application and cannot fix its ridiculous > behavior. Ian, this should be fixed by the negative lookup caching, right? I take it that's not in 5.0.3. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH] autofs4 - add missing kfree
Ian Kent <[EMAIL PROTECTED]> writes: > It see that the patch tittled "autofs4 - fix pending mount race" is > missing a change that I had recently made. > > It's missing a kfree for the case mutex_lock_interruptible() fails > to aquire the wait queue mutex. Yeah, missed that in the translation to the embedded qstr. > Ian > > Signed-off-by: Ian Kent <[EMAIL PROTECTED]> Reviewed-by: Jeff Moyer <[EMAIL PROTECTED]> ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH] autofs4 - detect invalid direct mount requests
Ian Kent <[EMAIL PROTECTED]> writes: > autofs v5 dierct and offset mounts within an autofs filesystem are > triggered by existing autofs triger mounts so the mount point dentry > must be positive. If the mount point dentry is negative then the > trigger doesn't exist so we can return fail immediately. What are the conditions that lead us here in that case? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Suggestion for better manpage.
Ian Kent <[EMAIL PROTECTED]> writes: > On Tue, 2008-06-17 at 12:57 +0200, Stef Bon wrote: >> Hello, >> >> reading the manpage of automount, I would like to change the section in the >> manpage about how the daemon reacts on signals. > > Send a patch. Try this on for size. Cheers, Jeff diff --git a/man/automount.8 b/man/automount.8 index 59ad50e..4cb7384 100644 --- a/man/automount.8 +++ b/man/automount.8 @@ -92,36 +92,51 @@ and the mount maps they will use. The default is \fBauto.master\fP. .hy .RE +.SH SIGNALS +.TP +\fBSIGHUP\fP +This signal triggers a re-read of the automount configuration. +.TP +\fBSIGTERM\fP +This signal instructs the daemon to unmount all unused file systems +and exit. If any file system cannot be unmounted, then the daemon does not +exit unless the daemon was compiled with either the ENABLE_IGNORE_BUSY_MOUNTS +option or the ENABLE_FORCED_SHUTDOWN option set (see \fBNOTES\fP below). +If ENABLE_IGNORE_BUSY_MOUNTS is set, the daemon will unmount unused file +systems and exit, leaving busy file systems mounted. If the +ENABLE_FORCED_SHUTDOWN options is set, then the file systems will be +unmounted and the daemon will exit, but the busy mountpoints will not be +released by the kernel until they are no longer in use by the processes +that held them busy. +.TP +\fBSIGUSR1\fP +Sending this signal to the running automount daemon will cause a forced +expire. All automount-managed mount points that are not busy will be +unmounted. +.TP +\fBSIGUSR2\fP +This signal requires that the daemon is compiled with the +ENABLE_FORCED_SHUTDOWN flag set (see \fBNOTES\fP below). Sending this +signal to the running automount daemon will cause a summary execution; +all automount-managed mount points will be unmounted, whether they are busy +or not. Note that the forced unmount is an unlink operation (umount -l), +and the actual umount will not happen in the kernel until active file +handles are released. In current incarnations of autofs (all releases of +version 5, up to and including 5.0.3 and potentially newer releases, too), +this can cause unwanted behaviour in applications. Since the mount point +is unlinked from the file system tree, and attempt to get a current working +directory will fail. + .SH NOTES -If the \fBautomount\fP daemon catches a USR1 signal, it will umount all -currently unused autofs managed mounted file systems and continue running -(forced expire). If it catches the TERM signal it will umount -all unused autofs managed mounted file systems and exit if there are -no remaining busy file systems. If autofs has been compiled with the -option to ignore busy mounts on exit it will exit leaving any busy -mounts in place otherwise busy file systems will not be umounted -and autofs will not exit. -Alternatively, if autofs has been compiled with the option to enable -forced shutdown then a USR2 signal to the daemon will cause all -mounts to be umounted and any busy mounts to be forcibly umounted, -including autofs mount point directories (summary execution). Note -that the forced umount is an unlink operation and the actual umount -will not happen in the kernel until active file handles are released. -The daemon also responds to a HUP signal which triggers an update of -the maps for each mount point. -.P -If any autofs mount point directories are busy when the daemon is sent -an exit signal the daemon will not exit. The exception to this is -if autofs has been built with configure options to either ignore busy -mounts at exit or force umount at exit. If the ignore busy mounts at -exit option is used the filesystems will be left in a catatonic -(non-functional) state and can be manually umounted when they become -unused. If the force umount at exit option is used the filesystems -will be umounted but the mount will not be released by the kernel -until they are no longer in use by the processes that held them busy. -If automount managed filesystems are found mounted when autofs is -started they will be recoverd unless they are no longer present in -the map in which case they need to umounted manually. +To see which compile-time options were selected, run '/usr/sbin/automount -V'. +The names of the selected options will be present in the "Compile options:" +section. + +If automount-managed file systems are found already mounted when the automount +daemon starts, those file systems will be recovered unless they are no longer +present in the automounter configuration. In that case, the file systems will +need to be manually unmounted. + .SH "SEE ALSO" .BR autofs (5), .BR autofs (8), ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] the debug info of the autofs
"Binbin Wang" <[EMAIL PROTECTED]> writes: > Hi, > > I am using the autofs-4.1.3-155 (RHEL4.2). I have seen the man page. > > man automount > -v, --verbose > Enables printing of general status and progress messages. > > -d, --debug > Enables printing of general status and progress messages as > well as debug- > ing messages. > > I found that all these debug information have been writen to the system log > file (/var/log/message) > > I wang to know that whether I can define the output file of the debug > information. Thank you very much! Sure. See http://people.redhat.com/jmoyer/. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Is there a known problem with recent Fedora systems core dumping?
Piete Brooks <[EMAIL PROTECTED]> writes: > I've not managed to get a useful backtrace from the core dumps I get, but is > there a known problem with the recent (6 .. 9) Fedora RPMs? > We use recursive mounts, but I think I've seen it when they aren't being used. > Basically a core dump appears in / and some part of the automount space stops > working (but other bits still work). > > Under Fedora Core 6 (autofs-5.0.1-0.rc3.33) it happened to just one research > group (who do things differently from everyone else), but as of Fedora 9 > (autofs-5.0.3-15) it appears to happen to others (e.g. me!). > It's intermittent (e.g. about once per day) > > Has anyone come across such a problem? If you are using ldap for your maps, then yes, and upgrading openssl will fix your problems. If not, then I'll have to defer to Ian on this. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] automount ignores remote logins
"Max Harvest" <[EMAIL PROTECTED]> writes: > Hello everybody, > > since i'm using the automount 5, i'm confronted with a very strange > behaviour. I use it to mount user directories over nfs. The automounter Are you saying that you did not experience this problem with autofs v4? > maps are provided by NIS und users ususally have to login only into > client computers remotely using rsh or ssh. Now i encounter the following > missbehaviour: > > At the init, automounter seems to start propperly, but if someone logins > over the network into the client machine, the automounter ignores all > mount requests (i.e. there is no automounter activity at all). Even a This is probably because there is no lookup performed (meaning it never gets to autofs). What errors are displayed in the ssh session when a user logs in? Is there anything in /var/log/secure or /var/log/messages that may indicate a problem elsewhere? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] multi-level deep ldap automount possible?
Shane <[EMAIL PROTECTED]> writes: > Hello, > > Hoping someone can help me figure out if its possible to do > multi-level deep automounts via ldap. I've seen a few examples of this > using files but can't get it to work using LDAP. > > eg I want: > server1:/export/protemp - /nfs/tmp/production > server2:/export/tmp/weekly - /nfs/tmp/weekly > server2:/export/tmp/hourly - /nfs/tmp/hourly > > pseudo ldap implementation It's better to just include your ldif. Your pseudo code doesn't make any sense to me. My guess is that you want something like the following: dn: ou=auto.master,dc=,dc= objectClass: automountMap objectClass: organizationalUnit dn: cn=/nfs,ou=auto.master,dc=,dc= objectClass: automount automountInformation: auto.nfs dn: ou=auto.nfs,dc=,dc= objectClass: organizationalUnit objectClass: automountMap dn: automountKey=tmp,ou=auto.nfs,dc=,dc= automountKey: tmp automountInformation: -rw,hard,intr,tcp /production server1:/export/protemp /weekly server2:/export/tmp/weekly /hourly server2:/export/tmp/hourly I didn't test the above, so there may be problems with my ldif -- sorry! If you haven't decided on a schema to use yet, then I'd recommend rfc2307bis. The schema above uses cn, which is not case sensitive. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Building autofs 5.0.3 on Debian Etch
Lukas Kolbe <[EMAIL PROTECTED]> writes: > Hi again! > > I try to build the latest and greatest autofs5 (5.0.3, with all patches > from kernel.org applied) on a plain debian etch (4.0) system, but it > fails on LDAP: > > lookup_ldap.c:88: error: 'LDAP_CONTROL_PAGEDRESULTS' undeclared (first use in > this function) > lookup_ldap.c:88: error: (Each undeclared identifier is reported only once > lookup_ldap.c:88: error: for each function it appears in.) > lookup_ldap.c: In function 'ldap_parse_page_control': > lookup_ldap.c:103: error: 'LDAP_CONTROL_PAGEDRESULTS' undeclared (first use > in this function) > > Whereas autofs5 5.0.2 (with all patches from kernel.org applied) builds > and works just fine. > > LDAP_CONTROL_PAGEDRESULTS seems to have been introduced somewhere in > between openldap 2.1.30-13.3, which debian etch uses, and 2.4.7, which > Ubuntu Hardy uses. On Hardy, autofs5 5.0.3 compiles just fine. > > Is there any way to work around this? I did try to backport a newer > openldap as well, but that's a major PITA because it itself requires a > newer GnuTLS which itself requires newer libgcrypt and other stuff. Well, if it isn't defined, that code should have been compiled out. Does your include/config.h list HAVE_LDAP_CREATE_PAGE_CONTROL set? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] System hanging in /proc/mounts almost every night... help!
Paul Smith <[EMAIL PROTECTED]> writes: > Hi all. I'm running Ubuntu 8.04 (kernel 2.6.24-17-generic, autofs 4.1.4 > +debian-2.1ubuntu2) on an Intel Pentium D 3GHz system with > hyperthreading (SMP kernel) and 1G RAM. > > I'm using DHCP for networking and obtaining my automount maps via NIS. > > For the last week or so, almost every morning when I come into work my > system is hung up in a strange way. I can move my mouse but I never get > asked for my password to unlock my screen. I can C-A-F1 etc. to get > back to a console but after I type my username at the login prompt, I > never get asked for a password and then that console is locked up. If I > have a console session already logged in from the day before, then I can > use it for a while but eventually some command will lock hard; can't ^C, > can't ^Z, can't kill -9, nothing. > > If I try to C-A-D to reboot the system starts to come down but then > hangs, hard, trying to bring down automount. Reset just tries to reboot > again and hangs in the same place. I have to power off/on the system > completely. Bummer. > > I did some debugging on this problem. I logged in as root on every > console (F1-F6). The next morning when the system was hung, I found a > command that hung (just "ls") and then I ran it in another console under > strace. > > It turns out what's happening is it's opening /proc/mounts, which > succeeds, then trying to read(2) from it. The read system call never > returns and there's no way to kill that process, at all, once it's in > that state. Also I note the load on the system is very high: typically > over 7. However top shows no processes chewing CPU. I also note that > there are some "duplicate" automount processes running (that is, more > than one for the same map). After I reboot, of course, everything is > fine. > > Last night I started all the consoles and in one of them I wrote a > little shell script that ran `date`, then did cat /proc/mounts, then > slept for 15 seconds, then did it again. I sent the output to a file. > > I found that the hang happened last night at ~22:51 EDT. There was > nothing interesting in the messages log, but in syslog I find a lot of > messages right around that time trying to get to non-existent automount > files (this is caused by some bogosity in the Tracker utility in Gnome, > but it shouldn't cause the system to hang!): > > Jun 2 22:51:29 psmithub automount[29241]: >> mount.nfs: access denied by > server while mounting snap-dev01:/user/.Trash-10490 > Jun 2 22:51:29 psmithub automount[29241]: mount(nfs): nfs: mount failure > snap-dev01:/user/.Trash-10490 on /user/.Trash-10490 > Jun 2 22:51:29 psmithub automount[29241]: failed to mount /user/.Trash-10490 > Jun 2 22:51:29 psmithub automount[29342]: failed to mount /nfs/.Trash > Jun 2 22:51:29 psmithub automount[29343]: failed to mount /nfs/.Trash-10490 > Jun 2 22:51:29 psmithub automount[29344]: failed to mount /mnt/.Trash > Jun 2 22:51:29 psmithub automount[29345]: failed to mount /mnt/.Trash-10490 > Jun 2 22:51:29 psmithub automount[29346]: >> /sbin/showmount: can't get > address for .Trash > Jun 2 22:51:29 psmithub automount[29346]: lookup(program): lookup for .Trash > failed > Jun 2 22:51:29 psmithub automount[29346]: failed to mount /net/.Trash > Jun 2 22:51:29 psmithub automount[29353]: >> /sbin/showmount: can't get > address for .Trash-10490 > Jun 2 22:51:29 psmithub automount[29353]: lookup(program): lookup for > .Trash-10490 failed > Jun 2 22:51:29 psmithub automount[29353]: failed to mount /net/.Trash-10490 > Jun 2 22:51:34 psmithub automount[29212]: mount(nfs): nfs: mount failure > snap-dev01:/tools on /opt/net/tools > Jun 2 22:51:34 psmithub automount[29212]: failed to mount /opt/net/tools > This .Trash madness has to end. It keep autofs from expiring mounts in other situations. *grumble* My advice for further debugging is to enabled autofs debug logging (see http://people.redhat.com/jmoyer), and when hung, get the output from sysrq-t. So, when you come in in the morning, issue the sysrq-t and make sure you can capture the output somehow (serial console or netconsole would be best). More below... > That's the last message of interest in the syslog. Here's the end of > the shell script loop log: > > Mon Jun 2 22:51:30 EDT 2008 > rootfs / rootfs rw 0 0 > none /sys sysfs rw,nosuid,nodev,noexec 0 0 > none /proc proc rw,nosuid,nodev,noexec 0 0 > udev /dev tmpfs rw,relatime 0 0 > fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 > /dev/disk/by-uuid/c7ada654-6e09-4400-ae85-c93e7fcd99d7 / ext3 > rw,relatime,errors=remount-ro,data=ordered 0 0 > /dev/disk/by-uuid/c7ada654-6e09-4400-ae85-c93e7fcd99d7 /dev/.static/dev ext3 > rw,relatime,errors=remount-ro,data=ordered 0 0 > tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0 > tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0 > tmpfs /lib/modules/2.6.24-17-generic/volatile tmpfs rw,relatime 0 0 > tmpfs /dev/shm tmpfs rw,relatime 0 0 > devpts /dev/pts
Re: [autofs] How to change the FSINFO for nfsd?
"P.V.Anthony" <[EMAIL PROTECTED]> writes: > Hi, > > Currently a gentoo linux server is used as a nfs server for some Mac OS > X clients. These Mac OS X clients are doing video editing. > > Currently the video are captured directly to the NFS mounts. > > Here is the problem. The video files are broken into 2GB files. This > because the video editing software(Final Cut Pro) breaks the files into > 2GB sizes. It does not seem that the Mac OS X is not doing the breaking > up of files. It is the video editing software. > > Some commercial company found an interesting behaviour. All the Mac OS X > NFS server FSINFO response in which the max file size is set to ' > ' (all '1's). > > The link about the above information can be found at this link below. > Read towards the bottom of the link. > http://forums.creativecow.net/thread/8/975362 > > I really would like to know where to change in the NFS source code so > that the FSINFO response from the server in which the max file size is > set to ' ' (all '1's). You're really stabbing in the dark, here. I suggest you email the software manufacturer of Final Cut Pro (Apple?) with a support request. Thanks, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Map errors
"Young, Darren" <[EMAIL PROTECTED]> writes: > Ok, so I set /etc/sysconfig/autofs to what looks to be the format Sun > wants: > > > > DEFAULT_MAP_OBJECT_CLASS="automountMap" > DEFAULT_ENTRY_OBJECT_CLASS="automount" > DEFAULT_MAP_ATTRIBUTE="automountMapName" > DEFAULT_ENTRY_ATTRIBUTE="automountKey" > DEFAULT_VALUE_ATTRIBUTE="automountInformation" Good so far. > And I set the following there: > DEFAULT_MASTER_MAP_NAME="ldap:automountMapName=auto_home" You should only need: DEFAULT_MASTER_MAP_NAME="auto_master" > And all auto.master has is this: > /home ldap Not quite right. Given what I think you're trying to do, you don't want a file called /etc/auto.master at all. > As autofs starts up I receive the following in syslog: > > Apr 28 12:10:03 gsbtestfilervm automount[22969]: Starting automounter > version 5.0.1-0.rc2.55, master map ldap:automountMapName=auto_home > > Apr 28 12:10:03 gsbtestfilervm automount[22969]: using kernel protocol > version 5.00 > > Apr 28 12:10:55 gsbtestfilervm automount[22969]: master_notify: syntax > error in map near [ /mbahome/& ] I believe these are all syntax errors in your master map. Can you give us the contents of that? -Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] include a master file: where does the automounter look
Stef Bon <[EMAIL PROTECTED]> writes: > Ian Kent wrote: >> On Mon, 2008-04-28 at 10:32 +0200, Stef Bon wrote: >> >>> Hello, >>> >>> when I read the manpage for auto.master (and other docs) I see that I >>> can include another master file by doing: >>> >>> +auto.master >>> >>> The comment says that by doing so, the you can specify a master map >>> which is found using >>> nsswitch sources. >>> What happens then? Where does it look then? >>> >> >> If you have a line in /etc/nsswitch.conf like: >> >> automount: files nis >> >> it will look in /etc for auto.master (files) and try to connect to a nis >> server and ask for auto.master. >> > Ok, it will search for the files first and after that the nis thing. > But here: this line which instructed the automounter to look in the > nsswitch.conf file is in a auto.master file, and then you instruct it to > look for the same file again. > This does not make sense to me... The daemon has logic to check for recursion, so it won't include the same map over and over again. If it is processing auto.master, and it sees a +auto.master, it checks the next source in the list. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Add mountpoints to mastermap dynamically.
Stef Bon <[EMAIL PROTECTED]> writes: > Hello, > > again a question. > > The construction I'm working on does add a mountpoint dynamically to an > existing map. The subject says you're adding a new entry to the master map. This sentence sounds like you're adding an entry to an existing map. The second should be caught automatically by the daemon, so no need to reload. > After added (first some checking the mountpoint is not already included) > a reload is > done with the running automount (HUP signal). The same after removing a > mountpoint. > > It works very good, but I'm wondering, is this the way to do this?? > Isn't there a autofsctl program??? You could do, 'service autofs reload' instead. Or maybe you should investigate direct maps. I'm not sure, since I know very little of your setup. Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
