From autofs-bounces@linux.kernel.org Tue Jan 4 08:12:57 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j04GCpXV024785 for ; Tue, 4 Jan 2005 08:12:57 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j04G5o4e027866; Tue, 4 Jan 2005 08:06:24 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j04G4rlW027815 for ; Tue, 4 Jan 2005 08:05:46 -0800 Received: from donald.themaw.net (203-59-105-72.dyn.iinet.net.au [203.59.105.72]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j04G53lm022353 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Jan 2005 00:05:04 +0800 Date: Tue, 4 Jan 2005 23:58:11 +0800 (WST) From: raven@themaw.net To: autofs mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-98.1, required 8, NO_REAL_NAME, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_10,NO_REAL_NAME,RCVD_IN_ORBS,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: linux-fsdevel , Kernel Mailing List Subject: [autofs] [ANNOUNCE] autofs4 2.4 updated module build kit and kernel patches X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi all, I have updated the autofs4 kernel module patches to match the implementation in 2.6.10. The most significant change is the addition of code to handle compatible ioctls for architectures that need it. It is important for systems like Gentoo or Debian on Ultra sparc, for example. The files are located in: http://www.kernel.org/pub/linux/daemons/autofs/v4 and are the build kit: autofs4-2.4-module-20041227.tar.[bz2|gz] vanila kernel patches: autofs4-2.4.18-20041227.patch autofs4-2.4.19-20041227.patch autofs4-2.4.20-20041227.patch autofs4-2.4.21-20041227.patch autofs4-2.4.22-20041227.patch autofs4-2.4.27-20041227.patch RedHat 9: autofs4-2.4.20-redhat9-20041227.patch Fedora Core 1: autofs4-2.4.22-fc1-20041227.patch Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 4 08:15:05 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j04GF4rx024794 for ; Tue, 4 Jan 2005 08:15:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j04GANCa028928; Tue, 4 Jan 2005 08:10:25 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j04G4xdB027818 for ; Tue, 4 Jan 2005 08:05:46 -0800 Received: from donald.themaw.net (203-59-105-72.dyn.iinet.net.au [203.59.105.72]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j04G5Rlm022394 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Jan 2005 00:05:28 +0800 Date: Tue, 4 Jan 2005 23:58:35 +0800 (WST) From: raven@themaw.net To: autofs mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-98.1, required 8, NO_REAL_NAME, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_10,NO_REAL_NAME,RCVD_IN_ORBS,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: linux-fsdevel , Kernel Mailing List Subject: [autofs] [ANNOUNCE] autofs4 2.6 updated patches for kernels prior to 2.6.10 X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: I have updated the autofs4 patches for kernel 2.6 to match the implementation in 2.6.10. They are located at: http://www.kernel.org/pub/linux/daemons/autofs/v4 The files are vanila kernel patches: autofs4-2.6.0-20041227.patch autofs4-2.6.4-20041227.patch autofs4-2.6.7-20041227.patch autofs4-2.6.9-20041227.patch Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 5 04:27:23 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j05CRMHc028147 for ; Wed, 5 Jan 2005 04:27:22 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j05CGnrT017040; Wed, 5 Jan 2005 04:17:33 -0800 Received: from smtp.riu.es (smtp.riu.es [195.57.233.204]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j05CFoQO017011 for ; Wed, 5 Jan 2005 04:16:43 -0800 Received: from localhost ([192.168.2.96]) by smtp.riu.es (8.13.2/8.13.2/Debian-1) with ESMTP id j05CFYWR001134 for ; Wed, 5 Jan 2005 13:15:34 +0100 Date: Wed, 5 Jan 2005 13:16:18 +0100 From: abo To: autofs@linux.kernel.org Message-ID: <20050105131618.1ccfca62@localhost> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 22:21:52 2004 clamav-milter version 0.80j on localhost X-Virus-Status: Clean X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_10,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] smbfs credentias X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: hi! im trying to mount smbfs resources from an ldap if i put in nisMapEntry this -fstype=smbfs,credentials=/home/abo/smb.creds everything is working right. then i want to do it per user but variable substitution doesn't work, i tried: -fstype=smbfs,credentials=/home/$USER/smb.creds -fstype=smbfs,credentials=/home/${USER}/smb.creds -fstype=smbfs,credentials=~/smb.creds but no succes. how can i get per user credentiasl? im on the wrong direction? thx abo _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 5 10:44:06 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j05Ii566010033 for ; Wed, 5 Jan 2005 10:44:06 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j05IaCif023081; Wed, 5 Jan 2005 10:36:48 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j05IZH7K023053 for ; Wed, 5 Jan 2005 10:36:09 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j05IZ8eN032312; Wed, 5 Jan 2005 13:35:08 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j05IZ7r29400; Wed, 5 Jan 2005 13:35:07 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j05IZ5ne031626; Wed, 5 Jan 2005 13:35:05 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j05IYJbF007448; Wed, 5 Jan 2005 13:34:19 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j05IYI7D007445; Wed, 5 Jan 2005 13:34:18 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16860.13098.782113.189445@segfault.boston.redhat.com> Date: Wed, 5 Jan 2005 13:34:18 -0500 To: abo Subject: Re: [autofs] smbfs credentias In-Reply-To: <20050105131618.1ccfca62@localhost> References: <20050105131618.1ccfca62@localhost> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding [autofs] smbfs credentias; abo adds: abo> hi! im trying to mount smbfs resources from an ldap abo> if i put in nisMapEntry this abo> -fstype=smbfs,credentials=/home/abo/smb.creds abo> everything is working right. then i want to do it per user but abo> variable substitution doesn't work, i tried: abo> -fstype=smbfs,credentials=/home/$USER/smb.creds abo> -fstype=smbfs,credentials=/home/${USER}/smb.creds abo> -fstype=smbfs,credentials=~/smb.creds abo> but no succes. abo> how can i get per user credentiasl? im on the wrong direction? The automounter runs as user root. It has no way of knowing which user requested a given mount. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 5 22:01:12 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0661BWA011327 for ; Wed, 5 Jan 2005 22:01:12 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j065tbig031306; Wed, 5 Jan 2005 21:56:02 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j065seA7030402 for ; Wed, 5 Jan 2005 21:55:33 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j065sxlm006426 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Jan 2005 13:55:00 +0800 Date: Thu, 6 Jan 2005 13:54:59 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Chris Feist In-Reply-To: <41B9F4EB.2050202@redhat.com> Message-ID: References: <41B9F4EB.2050202@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org Subject: [autofs] Re: [patch] Fix for ldap_search when multiple cn's are in one LDAP entry. X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 10 Dec 2004, Chris Feist wrote: > This patch fixes a bug in the ldap search which will only use the first > mount point found in an LDAP entry. > > For example if an ldap entry looks like this: > > dn: cn=%T%I_apps, nisMapName=auto_home, ou=foo.bar > nismapname: auto_home > objectClass: top > objectClass: nisobject > nismapentry: foo.bar.ti.com:/vol/vol6/TI_apps > cn: %T%I_apps > cn: TI_apps > > Then the auto_home map will only be used in /%T%I_apps But the key is unique by definition. I'll add this patch but I'm not sure it's correct wrt autofs map definition. Comments? Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Sun Jan 9 23:36:54 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0A7asO0011917 for ; Sun, 9 Jan 2005 23:36:54 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0A7TSew005053; Sun, 9 Jan 2005 23:30:01 -0800 Received: from dre.vanderbilt.edu (dre.Vanderbilt.Edu [129.59.129.80]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0A7TOhs005046 for ; Sun, 9 Jan 2005 23:29:25 -0800 Received: from tango.dre.vanderbilt.edu (tango.dre.Vanderbilt.Edu [129.59.129.82]) by dre.vanderbilt.edu (Postfix) with ESMTP id 7107CC55 for ; Mon, 10 Jan 2005 01:29:24 -0600 (CST) Received: by tango.dre.vanderbilt.edu (Postfix, from userid 1000) id 05432100B27; Mon, 10 Jan 2005 01:29:23 -0600 (CST) From: Krishnakumar B To: autofs@linux.kernel.org Date: Mon, 10 Jan 2005 01:29:23 -0600 Message-ID: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS,USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] Help with automounting from a LDAP server X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi, Are there any standard practices to follow for automounting from a LDAP server without using local files, for both the NFS server and the clients? The NFS clients part seems straightforward. However it is not clear how autofs mounts directories residing on the local filesystem on the NFS server. For example if I have the following setup: 1. I export /export/home from the NFS server, nfs.example.com 2. The NFS server is also configured to use the LDAP server to get automount information, i.e, automount: ldap in /etc/nsswitch.conf 3. auto_home is setup on the LDAP server to spit out something equivalent to: * -rw,hard,intr,rsize=8192,wsize=8192,nosuid nfs.example.com:/export/home Will autofs on nfs.example.com recognize the local mount /export/home and use a loopback mount for /home? If so, do people recommend using the same approach (using a direct mount) for /var/spool/mail on nfs.example.com? If not, why not? Is there any way to disable specify exclude clauses in the mount options to autofs? For example, can I specify some option to autofs so that on a particular machine autofs will not use the automount entry from the directory server. Thanks, kitty. -- Krishnakumar B Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 10 00:50:50 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0A8oowe014697 for ; Mon, 10 Jan 2005 00:50:50 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0A8ldSt016841; Mon, 10 Jan 2005 00:47:47 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0A8lY9H016828 for ; Mon, 10 Jan 2005 00:47:35 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0A8lrlm005854 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jan 2005 16:47:53 +0800 Date: Mon, 10 Jan 2005 16:47:53 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Krishnakumar B Subject: Re: [autofs] Help with automounting from a LDAP server In-Reply-To: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> Message-ID: References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 10 Jan 2005, Krishnakumar B wrote: > Hi, > > Are there any standard practices to follow for automounting from a LDAP > server without using local files, for both the NFS server and the clients? > The NFS clients part seems straightforward. However it is not clear how > autofs mounts directories residing on the local filesystem on the NFS > server. autofs should perform a bind mount if the mount is on the local machine. > > For example if I have the following setup: > > 1. I export /export/home from the NFS server, nfs.example.com > 2. The NFS server is also configured to use the LDAP server to get > automount information, i.e, automount: ldap in /etc/nsswitch.conf > 3. auto_home is setup on the LDAP server to spit out something equivalent to: > > * -rw,hard,intr,rsize=8192,wsize=8192,nosuid nfs.example.com:/export/home > > Will autofs on nfs.example.com recognize the local mount /export/home and > use a loopback mount for /home? If so, do people recommend using the same > approach (using a direct mount) for /var/spool/mail on nfs.example.com? If > not, why not? Can't do that at present. Direct mounts are not fully implemented. > > Is there any way to disable specify exclude clauses in the mount options to > autofs? For example, can I specify some option to autofs so that on a > particular machine autofs will not use the automount entry from the > directory server. Not that I know of. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 10 01:34:12 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0A9YB9r014785 for ; Mon, 10 Jan 2005 01:34:11 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0A9UFRv018251; Mon, 10 Jan 2005 01:30:22 -0800 Received: from uranos.quantum.physik.uni-potsdam.de (uranos.quantum.physik.uni-potsdam.de [141.89.72.92]) by hera.kernel.org (8.12.11/8.12.8) with SMTP id j0A9UAv5018238 for ; Mon, 10 Jan 2005 01:30:12 -0800 Received: (qmail 32264 invoked by uid 110); 10 Jan 2005 09:30:04 -0000 Date: Mon, 10 Jan 2005 10:30:04 +0100 From: Timo Felbinger To: autofs@linux.kernel.org Subject: Re: [autofs] Help with automounting from a LDAP server Message-ID: <20050110093004.GB30790@uranos.quantum.physik.uni-potsdam.de> References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> User-Agent: Mutt/1.4.2i X-Spam-Status: No, hits=-9.8 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Timo Felbinger List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: On Mon, Jan 10, 2005 at 01:29:23AM -0600, Krishnakumar B wrote: > > For example if I have the following setup: > > 1. I export /export/home from the NFS server, nfs.example.com > 2. The NFS server is also configured to use the LDAP server to get > automount information, i.e, automount: ldap in /etc/nsswitch.conf > 3. auto_home is setup on the LDAP server to spit out something equivalent to: > > * -rw,hard,intr,rsize=8192,wsize=8192,nosuid nfs.example.com:/export/home > > Will autofs on nfs.example.com recognize the local mount /export/home and > use a loopback mount for /home? Yes. > If so, do people recommend using the same > approach (using a direct mount) for /var/spool/mail on nfs.example.com? If > not, why not? > > Is there any way to disable specify exclude clauses in the mount options to > autofs? For example, can I specify some option to autofs so that on a > particular machine autofs will not use the automount entry from the > directory server. I don't know a way to specify exclude clauses in the mount options, but you might be able to do something equivalent in the LDAP query itself: I've written a patch for autofs-4.1.3 to give more flexibility with LDAP requests; in particular, it allows to specify arbitrary search filter expressions, so you should be able to include something along the lines of !(hostname=$MYSELF) into the query, if that is what you need. The patched version of modules/lookup_ldap.c is available at http://www.timof.qipc.org/autofs-4.1.3-patch Regards, Timo Felbinger -- Timo Felbinger Quantum Physics Group http://www.quantum.physik.uni-potsdam.de Institut fuer Physik Tel: +49 331 977 1793 Fax: -1767 Universitaet Potsdam, Germany _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 10 18:34:22 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0B2YLxH017122 for ; Mon, 10 Jan 2005 18:34:22 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B2RV8Y026244; Mon, 10 Jan 2005 18:28:05 -0800 Received: from harlech.math.ucla.edu (harlech.math.ucla.edu [128.97.4.250]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B2ROAO026235 for ; Mon, 10 Jan 2005 18:27:28 -0800 Received: from xena.cft.ca.us (lsanca1-ar2-4-60-045-106.lsanca1.dsl-verizon.net [4.60.45.106]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "James F. Carter", Issuer "UCLA-Mathnet Root Certificate" (verified OK)) by harlech.math.ucla.edu (Postfix) with ESMTP id 6F0CF761A6; Mon, 10 Jan 2005 18:27:21 -0800 (PST) Received: by xena.cft.ca.us (Postfix, from userid 228) id 05D9B27249; Mon, 10 Jan 2005 18:27:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xena.cft.ca.us (Postfix) with ESMTP id A6225626D4; Mon, 10 Jan 2005 18:27:17 -0800 (PST) Date: Mon, 10 Jan 2005 18:27:16 -0800 (PST) From: Jim Carter To: Krishnakumar B Subject: Re: [autofs] Help with automounting from a LDAP server In-Reply-To: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> Message-ID: References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 10 Jan 2005, Krishnakumar B wrote: > ... However it is not clear how > autofs mounts directories residing on the local filesystem on the NFS > server. > > For example if I have the following setup: > > 1. I export /export/home from the NFS server, nfs.example.com > 2. The NFS server is also configured to use the LDAP server to get > automount information, i.e, automount: ldap in /etc/nsswitch.conf > 3. auto_home is setup on the LDAP server to spit out something equivalent to: > > * -rw,hard,intr,rsize=8192,wsize=8192,nosuid nfs.example.com:/export/home > > Will autofs on nfs.example.com recognize the local mount /export/home and > use a loopback mount for /home? It works for me. I use NIS, not LDAP, for the map, but it should work the same for any map type. The automount daemon specifically identifies attempted NFS mounts on the local machine and substitutes bind mounts (on Linux). > If so, do people recommend using the same > approach (using a direct mount) for /var/spool/mail on nfs.example.com? If > not, why not? There's no problem if the mail user agent and delivery agent are both on the machine that has the mailbox, reaching it either by its own name or via a bind/loopback mount. However, if either one is on another host, file locking is not completely effective; most likely there is a short window during which both programs can get the lock. The more common symptom is truncated incoming messages; trashed non-deleted messages are also possible. My most recent test of this was last year on Linux kernel 2.4.21 with kernel NFS; I also tested it a number of years ago on SunOS 3.x. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 13:38:52 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0BLcpZn019266 for ; Tue, 11 Jan 2005 13:38:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B9NGKh000724; Tue, 11 Jan 2005 01:23:23 -0800 Received: from smtp.riu.es (smtp.riu.es [195.57.233.204]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B9NCYY000717 for ; Tue, 11 Jan 2005 01:23:13 -0800 Received: from localhost ([192.168.2.96]) by smtp.riu.es (8.13.2/8.13.2/Debian-1) with ESMTP id j0B9N151008447 for ; Tue, 11 Jan 2005 10:23:01 +0100 Date: Tue, 11 Jan 2005 10:23:56 +0100 From: abo To: autofs@linux.kernel.org Subject: Re: [autofs] Help with automounting from a LDAP server Message-ID: <20050111102356.0709bcef@localhost> In-Reply-To: References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> <87pt0czb00.fsf@tango.dre.vanderbilt.edu> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 22:21:52 2004 clamav-milter version 0.80j on localhost X-Virus-Status: Clean X-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: sorry about this newbie question, but can you explain what exactly direct mounts/maps is? thx On Tue, 11 Jan 2005 16:39:40 +0800 (WST) Ian Kent wrote: > On Tue, 11 Jan 2005, Krishnakumar B wrote: > > > > Can't do that at present. Direct mounts are not fully implemented. > > > > My manpage for autofs(5) claims the following: > > > > UNSUPPORTED > > This version of the automounter supports direct maps for FILE, NIS > > and LDAP maps only and handles SunOS-style replicated filesystems > > only to the extent that mount(8) does. > > Perhaps I need to change this to be more accurate. > > > > > So is my manpage wrong, or does "direct maps" mean something other than > > "direct mounts"? Or are you referring to the following limitation (from > > README.direct v1.3). > > > > NOTE: Due to current design limitations, direct maps will take over an > > entire directory hierarchy. What this means is, if your direct map key is > > /usr/share/bilbo, then /usr will become an automount mount point, mounting > > over the existing /usr. > > I'm refering to the design limitation mentioned in this note. > > This will continue to be the case in 4.1.4 (in fact 4.1.x). > > I plan on creating a 4.2.0 development branch at some point fairly soon. > This will be the top priority for that development. > > Ian > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 13:38:52 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0BLcpZp019266 for ; Tue, 11 Jan 2005 13:38:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B8dCZ9031618; Tue, 11 Jan 2005 00:39:24 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B8d8A8031611 for ; Tue, 11 Jan 2005 00:39:10 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0B8delm007991 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Jan 2005 16:39:41 +0800 Date: Tue, 11 Jan 2005 16:39:40 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Krishnakumar B Subject: Re: [autofs] Help with automounting from a LDAP server In-Reply-To: <87pt0czb00.fsf@tango.dre.vanderbilt.edu> Message-ID: References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> <87pt0czb00.fsf@tango.dre.vanderbilt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 11 Jan 2005, Krishnakumar B wrote: > > Can't do that at present. Direct mounts are not fully implemented. > > My manpage for autofs(5) claims the following: > > UNSUPPORTED > This version of the automounter supports direct maps for FILE, NIS > and LDAP maps only and handles SunOS-style replicated filesystems > only to the extent that mount(8) does. Perhaps I need to change this to be more accurate. > > So is my manpage wrong, or does "direct maps" mean something other than > "direct mounts"? Or are you referring to the following limitation (from > README.direct v1.3). > > NOTE: Due to current design limitations, direct maps will take over an > entire directory hierarchy. What this means is, if your direct map key is > /usr/share/bilbo, then /usr will become an automount mount point, mounting > over the existing /usr. I'm refering to the design limitation mentioned in this note. This will continue to be the case in 4.1.4 (in fact 4.1.x). I plan on creating a 4.2.0 development branch at some point fairly soon. This will be the top priority for that development. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 13:38:53 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0BLcpZr019266 for ; Tue, 11 Jan 2005 13:38:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B7LuSc017915; Mon, 10 Jan 2005 23:22:20 -0800 Received: from dre.vanderbilt.edu (dre.Vanderbilt.Edu [129.59.129.80]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0B7LqT9017908 for ; Mon, 10 Jan 2005 23:21:53 -0800 Received: from tango.dre.vanderbilt.edu (tango.dre.Vanderbilt.Edu [129.59.129.82]) by dre.vanderbilt.edu (Postfix) with ESMTP id 2B713B76; Tue, 11 Jan 2005 01:21:52 -0600 (CST) Received: by tango.dre.vanderbilt.edu (Postfix, from userid 1000) id AEC421000A4; Tue, 11 Jan 2005 01:21:51 -0600 (CST) From: Krishnakumar B To: Ian Kent Subject: Re: [autofs] Help with automounting from a LDAP server References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> Date: Tue, 11 Jan 2005 01:21:51 -0600 In-Reply-To: (Ian Kent's message of "Mon, 10 Jan 2005 16:47:53 +0800 (WST)") Message-ID: <87pt0czb00.fsf@tango.dre.vanderbilt.edu> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi, Thanks for all the followups. On Tuesday, 11 January 2005, Ian Kent wrote: > On Mon, 10 Jan 2005, Krishnakumar B wrote: > [...] >> Will autofs on nfs.example.com recognize the local mount /export/home and >> use a loopback mount for /home? If so, do people recommend using the same >> approach (using a direct mount) for /var/spool/mail on nfs.example.com? If >> not, why not? > > Can't do that at present. Direct mounts are not fully implemented. My manpage for autofs(5) claims the following: UNSUPPORTED This version of the automounter supports direct maps for FILE, NIS and LDAP maps only and handles SunOS-style replicated filesystems only to the extent that mount(8) does. So is my manpage wrong, or does "direct maps" mean something other than "direct mounts"? Or are you referring to the following limitation (from README.direct v1.3). NOTE: Due to current design limitations, direct maps will take over an entire directory hierarchy. What this means is, if your direct map key is /usr/share/bilbo, then /usr will become an automount mount point, mounting over the existing /usr. I am using the following version of autofs with Linux-2.4.28. tango % dpkg -S /usr/share/man/man5/autofs.5.gz autofs: /usr/share/man/man5/autofs.5.gz tango % tango % dpkg -p autofs Package: autofs Priority: extra Section: utils Installed-Size: 428 Maintainer: Steinar H. Gunderson Architecture: i386 Version: 4.1.3-8 DDepends: libc6 (>= 2.3.2.ds1-4) Recommends: nfs-common ConCflicts: samba (<< 2.0.6-1) Filename: pool/main/a/autofs/autofs_4.1.3-8_i386.deb Size: 96350 MD5sum: 42aef00313ebe91c572bcdeb04708914 Description: A kernel-based automounter for Linux Autofs controls the operation of the automount daemons. The automount daemons automatically mount filesystems when they are used and unmount them after a period of inactivity. This is done based on a set of pre-configured maps. . The kernel automounter implements an almost complete SunOS style automounter under Linux. Automounter version 4 (autofs4) has to be enabled when compiling the kernel. Debian packaged kernels have it enabled. -kitty. -- Krishnakumar B Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 13:39:05 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0BLd5ej019298 for ; Tue, 11 Jan 2005 13:39:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0BLMwKc002264; Tue, 11 Jan 2005 13:23:30 -0800 Received: from nwd2mail1.analog.com (nwd2mail1.analog.com [137.71.25.50]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0BLMsow002255 for ; Tue, 11 Jan 2005 13:22:55 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j0BLMsoU027017 for ; Tue, 11 Jan 2005 16:22:54 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id QAA20483 for ; Tue, 11 Jan 2005 16:22:49 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0BLMmET002446; Tue, 11 Jan 2005 16:22:48 -0500 (EST) Message-Id: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: autofs@linux.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jan 2005 16:22:48 -0500 From: David Meleedy X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.50 Subject: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi Ian & Jeff, I am trying to track down an autofs issue that has been plaguing us. It seems to be caused by the interaction of autofs version 4 with a Network Appliance server, and cd'ing to /net directories on the Netapp server. A similar issue was seen in Analog Devices in Redhat 8, and apparently the problem was worked around by Dwight Marzolf working with Ian Kent's help. So following what Dwight did I have been trying to recreate the fix for Redhat Enterprise 3 update 3, and so far have not met with success. THE PROBLEM DESCRIPTION: Autofs hangs and refuses to mount any directories for a period of time after cd'ing to /net//vol/vol[0-3] and waiting a while. The only way to clear this is to reboot the client. Initially we started using the following software (Redhat Enterprise 3 update 3) autofs 4.1.3-12 kernel 2.4.21-20 nfs-utils 1.0.6-31EL WHAT HAS BEEN TRIED SO FAR: Mike Waychison, after seeing the messages from our log file said, "These messages are due to starvation for reserved ports (< 1024). Specifically, the kernel will only use ports < 800. Currently, the kernel uses one port per nfs filesystem. If you mount filesystems very fast, then you can also run out of reserved ports as the local (mountd iirc?) will close tcp sessions and each must wait 2 minutes before being released. One solution is to try out the patch I posted last week that allows nfs mounts to share tcp/udp connections: http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 " The problem is we are using a different version of the kernel 2.4, and his patch was for the 2.6 kernel. Also, although his patch might make the number of ports available increase, I think it does not really solve the problem, it just gives more breathing room. After talking with Jeff Moyer about the issue, I updated autofs to autofs-4.1.3-67. This was supposed to incorporate a patch that fixes the port leak problem. This did not solve the problem, but it did seem to improve things a bit. After looking at Dwight Marzolf's document on his workaround I found the following information (this is exactly the same sort of thing we are seeing too): " we quickly found that if you did a cd via /net to one of our Network Appliance filers (all our other netapp filers worked correctly when unmounting /net mounts), the port release issue still existed. In fact, the mountpoints actively took more ports. This meant that if you mounted this filer with /net, your workstation could be rendered useless in less than 24 hours. It also became evident that this active taking of ports by this filer was not limited to just autofs-4.1.3-28 but also earlier versions of autofs ... Further research revealed the ports were being taken at the point of automount timeout. When the automounter had declared these mountpoints to be timed out and ready to be unmounted and attempted to umount them, in fact, it ended up remounting them, using new ports for the remount ... " HOW TO REPRODUCE THE PROBLEM: Actually in our case we can render a machine useless in just about an hour or two, and this happens for all of our Netapp filers. The procedure to do this is reproducible. 1) You cd to a /net directory on the filer. 2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. and watch the "BUG" messages in the /var/log/messages file. 3) Log out. (so the automounter tries to unmount everything that was mounted). 4) Log in again, after 30 minutes and by then you won't be about to mount anything anymore You can replace steps 3 and 4 with "init 6". When the automounter process is stopped by init, you will see the port messages scroll up the console screen. EXAMPLE OF REPRODUCING THE PROBLEM: codered-51: cd /net/aflac/vol/vol2 ( I can't help but wonder if this BUG message that shows up once a minute is indicative of a problem ) codered-52: tail -f /var/log/messages Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already mounted ... (continues once a minute to print out this bug) ... codered-53: sudo init 6 (after reboot log in to see error messages) THE REALLY WEIRD PART: Now the interesting thing here is that the machine is rebooting, so there is no program requesting additional mounts, yet here in the log files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 and /vol/vol3 are attempted to be mounted, even though the only thing that should be happening is an unmount of the directory aflac:/vol/vol2 jetcar-189: cd /net/aflac/vol/vol3 jetcar-190: ls ad1983/ cad_archive/ emerald/ layout_old/ ta/ archive/ design/ is_013std/ lx3/ jetcar-191: cd ../vol2 jetcar-192: ls 9xcores/ danube/ nwd_layout/ ulc3/ DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ WWM/ gpdsp_marketing/ pc_backups/ bitpower/ india_mirror/ sh/ bluetooth/ nile/ spitfire/ jetcar-194: cd ../vol1 etcar-195: ls IssueManager/ diablo/ is_013std/ ras/ tigersharc/ admin/ ed/ jordan/ soft/ archive/ fsp/ nwd_fsp@ teton_lite/ cpd/ herc_eval/ pe_workspace/ thor/ codered-54: less /var/log/messages Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:17 codered autofs: automount -USR2 succeeded Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:20 codered autofs: automount -USR2 succeeded Jan 11 15:51:23 codered autofs: automount -USR2 succeeded Jan 11 15:51:26 codered autofs: automount -USR2 succeeded Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, bad superblock on aflac:/vol/vol2/spitfire, Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file sys tems Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure aflac:/ vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, bad superblock on aflac:/vol/vol2/ulc3, Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file systems Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure aflac:/vol/vol2/ulc3 on /net/aflac/vol/vol2/ulc3 ... This same pattern of error messages repeats for (in this order) aflac:/vol/vol2/win2k aflac:/vol/vol3/ad1983 aflac:/vol/vol3/archive aflac:/vol/vol3/cad_archive aflac:/vol/vol3/design aflac:/vol/vol3/emerald aflac:/vol/vol3 aflac:/vol/vol3/is_013std aflac:/vol/vol3/layout_old aflac:/vol/vol3/lx3 aflac:/vol/vol3/ta aflac:/vol/vol2/DSPS_Finance aflac:/vol/vol2 aflac:/vol/vol2/gpdsp_marketing aflac:/vol/vol2/gpdsp_PLD aflac:/vol/vol2/india_mirror aflac:/vol/vol2/nile aflac:/vol/vol2/nwd_layout aflac:/vol/vol2/nwd_testmgr aflac:/vol/vol2/pc_backups aflac:/vol/vol2/sh aflac:/vol/vol2/spitfire (repeats the whole thing again) eventually gets to vol1: ... aflac:/vol/vol3/ta aflac:/vol/vol1/pe_workspace aflac:/vol/vol1/ras aflac:/vol/vol1/soft aflac:/vol/vol1/teton_lite aflac:/vol/vol1/thor aflac:/vol/vol1/tigersharc aflac:/vol/vol2/9xcores aflac:/vol/vol2/bitpower aflac:/vol/vol2/bluetooth aflac:/vol/vol2/danube aflac:/vol/vol2/DSPS_Finance ... (repeats the whole thing again)... Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/ta Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/lx3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/layout_old Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/is_013std Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/win2k Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/ulc3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/spitfire Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/sh Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/pc_backups Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nwd_testmgr Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nwd_layout Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nile Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/india_mirror Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/gpdsp_marketing Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/gpdsp_PLD Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/tigersharc Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/thor Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/teton_lite Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/soft Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/ras Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/pe_workspace Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/jordan Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/is_013std Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/herc_eval Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/fsp Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/IssueManager Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol0 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15971]: expired /net/aflac Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15974]: expired /net/aflac Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15975]: expired /net/aflac Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15976]: expired /net/aflac Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15977]: expired /net/aflac Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac Jan 11 15:51:38 codered automount[15978]: expired /net/aflac Jan 11 15:51:38 codered autofs: automount -USR2 succeeded Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac Jan 11 15:51:38 codered automount[15986]: expired /net/aflac Jan 11 15:51:39 codered automount[6214]: can't shutdown: filesystem /net still busy .... (keeps repeating) .... Jan 11 15:51:45 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:47 codered autofs: automount shutdown failed HOW IT WAS FIXED IN REDHAT 8: Dwight had implemented his fix in 3 steps for Redhat 8: 1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix 2) He patched his kernel with the autofs4-2.4.20-20040508.patch (is some equivalent patch needed for Redhat 3 Enterprise 3 which uses kernel 2.4.21-20 ? 3) He changed the way he exported filesystems from the Netapp: "The last issue was the matter of how /vol/vol0 is exported from a Network Appliance filer. We found that the following exports broke autofs4: /vol/vol0 -root=node1:node2:node3:node4 /vol/vol0 -rw,root=node1:node2:node3 /vol/vol0 -anon=0 The export syntax that worked was: /vol/vol0 -rw=node1:node2,root=node1,node2 " WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: Now when I tried to do something similar, I found that if you weren't on node1 or node2, the filesystem was read-only, so I had to do this: /vol/vol1 -rw=node1:node2,root=node1,node2 /vol/vol1/foo1 -root=node1:node2 /vol/vol1/foo2 -root=node1:node2 This way if you cd /net/filer/vol/vol1 it was read-only for most machines but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, plus using autofs-4.1.3-67 has not yet solved the problem yet for our Redhat Enterprise 3 clients. CONCLUSION: I hope this is enough info to track down this problem. It appears as though the interaction of using /net with a Netapp is causing spurious mounts, and unmounting is not working. I will assist with any patch tests that you require, so let me know, and I will be able to verify any fixes. Thanks, -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 14:20:01 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0BMK0Us019794 for ; Tue, 11 Jan 2005 14:20:01 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0BLMwKc002264; Tue, 11 Jan 2005 13:23:30 -0800 Received: from nwd2mail1.analog.com (nwd2mail1.analog.com [137.71.25.50]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0BLMsow002255 for ; Tue, 11 Jan 2005 13:22:55 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j0BLMsoU027017 for ; Tue, 11 Jan 2005 16:22:54 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id QAA20483 for ; Tue, 11 Jan 2005 16:22:49 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0BLMmET002446; Tue, 11 Jan 2005 16:22:48 -0500 (EST) Message-Id: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: autofs@linux.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jan 2005 16:22:48 -0500 From: David Meleedy X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.50 Subject: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi Ian & Jeff, I am trying to track down an autofs issue that has been plaguing us. It seems to be caused by the interaction of autofs version 4 with a Network Appliance server, and cd'ing to /net directories on the Netapp server. A similar issue was seen in Analog Devices in Redhat 8, and apparently the problem was worked around by Dwight Marzolf working with Ian Kent's help. So following what Dwight did I have been trying to recreate the fix for Redhat Enterprise 3 update 3, and so far have not met with success. THE PROBLEM DESCRIPTION: Autofs hangs and refuses to mount any directories for a period of time after cd'ing to /net//vol/vol[0-3] and waiting a while. The only way to clear this is to reboot the client. Initially we started using the following software (Redhat Enterprise 3 update 3) autofs 4.1.3-12 kernel 2.4.21-20 nfs-utils 1.0.6-31EL WHAT HAS BEEN TRIED SO FAR: Mike Waychison, after seeing the messages from our log file said, "These messages are due to starvation for reserved ports (< 1024). Specifically, the kernel will only use ports < 800. Currently, the kernel uses one port per nfs filesystem. If you mount filesystems very fast, then you can also run out of reserved ports as the local (mountd iirc?) will close tcp sessions and each must wait 2 minutes before being released. One solution is to try out the patch I posted last week that allows nfs mounts to share tcp/udp connections: http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 " The problem is we are using a different version of the kernel 2.4, and his patch was for the 2.6 kernel. Also, although his patch might make the number of ports available increase, I think it does not really solve the problem, it just gives more breathing room. After talking with Jeff Moyer about the issue, I updated autofs to autofs-4.1.3-67. This was supposed to incorporate a patch that fixes the port leak problem. This did not solve the problem, but it did seem to improve things a bit. After looking at Dwight Marzolf's document on his workaround I found the following information (this is exactly the same sort of thing we are seeing too): " we quickly found that if you did a cd via /net to one of our Network Appliance filers (all our other netapp filers worked correctly when unmounting /net mounts), the port release issue still existed. In fact, the mountpoints actively took more ports. This meant that if you mounted this filer with /net, your workstation could be rendered useless in less than 24 hours. It also became evident that this active taking of ports by this filer was not limited to just autofs-4.1.3-28 but also earlier versions of autofs ... Further research revealed the ports were being taken at the point of automount timeout. When the automounter had declared these mountpoints to be timed out and ready to be unmounted and attempted to umount them, in fact, it ended up remounting them, using new ports for the remount ... " HOW TO REPRODUCE THE PROBLEM: Actually in our case we can render a machine useless in just about an hour or two, and this happens for all of our Netapp filers. The procedure to do this is reproducible. 1) You cd to a /net directory on the filer. 2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. and watch the "BUG" messages in the /var/log/messages file. 3) Log out. (so the automounter tries to unmount everything that was mounted). 4) Log in again, after 30 minutes and by then you won't be about to mount anything anymore You can replace steps 3 and 4 with "init 6". When the automounter process is stopped by init, you will see the port messages scroll up the console screen. EXAMPLE OF REPRODUCING THE PROBLEM: codered-51: cd /net/aflac/vol/vol2 ( I can't help but wonder if this BUG message that shows up once a minute is indicative of a problem ) codered-52: tail -f /var/log/messages Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already mounted Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already mounted ... (continues once a minute to print out this bug) ... codered-53: sudo init 6 (after reboot log in to see error messages) THE REALLY WEIRD PART: Now the interesting thing here is that the machine is rebooting, so there is no program requesting additional mounts, yet here in the log files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 and /vol/vol3 are attempted to be mounted, even though the only thing that should be happening is an unmount of the directory aflac:/vol/vol2 jetcar-189: cd /net/aflac/vol/vol3 jetcar-190: ls ad1983/ cad_archive/ emerald/ layout_old/ ta/ archive/ design/ is_013std/ lx3/ jetcar-191: cd ../vol2 jetcar-192: ls 9xcores/ danube/ nwd_layout/ ulc3/ DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ WWM/ gpdsp_marketing/ pc_backups/ bitpower/ india_mirror/ sh/ bluetooth/ nile/ spitfire/ jetcar-194: cd ../vol1 etcar-195: ls IssueManager/ diablo/ is_013std/ ras/ tigersharc/ admin/ ed/ jordan/ soft/ archive/ fsp/ nwd_fsp@ teton_lite/ cpd/ herc_eval/ pe_workspace/ thor/ codered-54: less /var/log/messages Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:17 codered autofs: automount -USR2 succeeded Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:20 codered autofs: automount -USR2 succeeded Jan 11 15:51:23 codered autofs: automount -USR2 succeeded Jan 11 15:51:26 codered autofs: automount -USR2 succeeded Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, bad superblock on aflac:/vol/vol2/spitfire, Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file sys tems Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure aflac:/ vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, bad superblock on aflac:/vol/vol2/ulc3, Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file systems Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure aflac:/vol/vol2/ulc3 on /net/aflac/vol/vol2/ulc3 ... This same pattern of error messages repeats for (in this order) aflac:/vol/vol2/win2k aflac:/vol/vol3/ad1983 aflac:/vol/vol3/archive aflac:/vol/vol3/cad_archive aflac:/vol/vol3/design aflac:/vol/vol3/emerald aflac:/vol/vol3 aflac:/vol/vol3/is_013std aflac:/vol/vol3/layout_old aflac:/vol/vol3/lx3 aflac:/vol/vol3/ta aflac:/vol/vol2/DSPS_Finance aflac:/vol/vol2 aflac:/vol/vol2/gpdsp_marketing aflac:/vol/vol2/gpdsp_PLD aflac:/vol/vol2/india_mirror aflac:/vol/vol2/nile aflac:/vol/vol2/nwd_layout aflac:/vol/vol2/nwd_testmgr aflac:/vol/vol2/pc_backups aflac:/vol/vol2/sh aflac:/vol/vol2/spitfire (repeats the whole thing again) eventually gets to vol1: ... aflac:/vol/vol3/ta aflac:/vol/vol1/pe_workspace aflac:/vol/vol1/ras aflac:/vol/vol1/soft aflac:/vol/vol1/teton_lite aflac:/vol/vol1/thor aflac:/vol/vol1/tigersharc aflac:/vol/vol2/9xcores aflac:/vol/vol2/bitpower aflac:/vol/vol2/bluetooth aflac:/vol/vol2/danube aflac:/vol/vol2/DSPS_Finance ... (repeats the whole thing again)... Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/ta Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/lx3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/layout_old Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/is_013std Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/win2k Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/ulc3 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/spitfire Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/sh Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/pc_backups Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nwd_testmgr Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nwd_layout Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/nile Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/india_mirror Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/gpdsp_marketing Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/gpdsp_PLD Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/tigersharc Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/thor Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/teton_lite Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/soft Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/ras Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/pe_workspace Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/jordan Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/is_013std Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/herc_eval Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/fsp Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/IssueManager Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol0 Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15971]: expired /net/aflac Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15974]: expired /net/aflac Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15975]: expired /net/aflac Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15976]: expired /net/aflac Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac Jan 11 15:51:37 codered automount[15977]: expired /net/aflac Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac Jan 11 15:51:38 codered automount[15978]: expired /net/aflac Jan 11 15:51:38 codered autofs: automount -USR2 succeeded Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol3 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol2 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol1 Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac Jan 11 15:51:38 codered automount[15986]: expired /net/aflac Jan 11 15:51:39 codered automount[6214]: can't shutdown: filesystem /net still busy .... (keeps repeating) .... Jan 11 15:51:45 codered automount[6214]: can't shutdown: filesystem /net still busy Jan 11 15:51:47 codered autofs: automount shutdown failed HOW IT WAS FIXED IN REDHAT 8: Dwight had implemented his fix in 3 steps for Redhat 8: 1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix 2) He patched his kernel with the autofs4-2.4.20-20040508.patch (is some equivalent patch needed for Redhat 3 Enterprise 3 which uses kernel 2.4.21-20 ? 3) He changed the way he exported filesystems from the Netapp: "The last issue was the matter of how /vol/vol0 is exported from a Network Appliance filer. We found that the following exports broke autofs4: /vol/vol0 -root=node1:node2:node3:node4 /vol/vol0 -rw,root=node1:node2:node3 /vol/vol0 -anon=0 The export syntax that worked was: /vol/vol0 -rw=node1:node2,root=node1,node2 " WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: Now when I tried to do something similar, I found that if you weren't on node1 or node2, the filesystem was read-only, so I had to do this: /vol/vol1 -rw=node1:node2,root=node1,node2 /vol/vol1/foo1 -root=node1:node2 /vol/vol1/foo2 -root=node1:node2 This way if you cd /net/filer/vol/vol1 it was read-only for most machines but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, plus using autofs-4.1.3-67 has not yet solved the problem yet for our Redhat Enterprise 3 clients. CONCLUSION: I hope this is enough info to track down this problem. It appears as though the interaction of using /net with a Netapp is causing spurious mounts, and unmounting is not working. I will assist with any patch tests that you require, so let me know, and I will be able to verify any fixes. Thanks, -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 11 21:43:32 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0C5hVEB004194 for ; Tue, 11 Jan 2005 21:43:32 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0C5cEm5009276; Tue, 11 Jan 2005 21:38:47 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0C5c50j009267 for ; Tue, 11 Jan 2005 21:38:06 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0C5cilm003190 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jan 2005 13:38:45 +0800 Date: Wed, 12 Jan 2005 13:38:44 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> Message-ID: References: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Just a quick note before we get deep into this. Can you check something for me. Get the source rpm for util-linux. Check if there is a patch applied to it to probe for services during mount (it was a patch in FC). If it is rebuild the rpm without it and test again. On Tue, 11 Jan 2005, David Meleedy wrote: > > Hi Ian & Jeff, > I am trying to track down an autofs issue that has been > plaguing us. It seems to be caused by the interaction of autofs version > 4 with a Network Appliance server, and cd'ing to /net directories > on the Netapp server. > > A similar issue was seen in Analog Devices in Redhat 8, and apparently > the problem was worked around by Dwight Marzolf working with Ian Kent's > help. So following what Dwight did I have been trying to recreate the fix > for Redhat Enterprise 3 update 3, and so far have not met with success. > > THE PROBLEM DESCRIPTION: > > Autofs hangs and refuses to mount any directories for a period of time > after cd'ing to /net//vol/vol[0-3] and waiting a while. > The only way to clear this is to reboot the client. > > Initially we started using the following software (Redhat Enterprise 3 update > 3) > autofs 4.1.3-12 > kernel 2.4.21-20 > nfs-utils 1.0.6-31EL > > WHAT HAS BEEN TRIED SO FAR: > > Mike Waychison, after seeing the messages from our log file said, > > "These messages are due to starvation for reserved ports (< 1024). > Specifically, the kernel will only use ports < 800. Currently, the > kernel uses one port per nfs filesystem. If you mount filesystems very > fast, then you can also run out of reserved ports as the local (mountd > iirc?) will close tcp sessions and each must wait 2 minutes before being > released. > > One solution is to try out the patch I posted last week that allows nfs > mounts to share tcp/udp connections: > > http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 > " > > The problem is we are using a different version of the kernel 2.4, > and his patch was for the 2.6 kernel. Also, although his patch > might make the number of ports available increase, I think it does > not really solve the problem, it just gives more breathing room. > > After talking with Jeff Moyer about the issue, I updated autofs to > autofs-4.1.3-67. This was supposed to incorporate a patch that fixes > the port leak problem. > > This did not solve the problem, but it did seem to improve things a bit. > > After looking at Dwight Marzolf's document on his workaround I found > the following information (this is exactly the same sort of thing we > are seeing too): > > " > we quickly found that if you did a cd via /net to one of our Network > Appliance filers (all our other netapp filers worked correctly when > unmounting /net mounts), the port release issue still existed. In > fact, the mountpoints actively took more ports. This meant that if you > mounted this filer with /net, your workstation could be rendered > useless in less than 24 hours. It also became evident that this active > taking of ports by this filer was not limited to just autofs-4.1.3-28 > but also earlier versions of autofs ... Further > research revealed the ports were being taken at the point of automount > timeout. When the automounter had declared these mountpoints to be > timed out and ready to be unmounted and attempted to umount them, in > fact, it ended up remounting them, using new ports for the remount ... > " > > HOW TO REPRODUCE THE PROBLEM: > > Actually in our case we can render a machine useless in just about an > hour or two, and this happens for all of our Netapp filers. The procedure > to do this is reproducible. > > 1) You cd to a /net directory on the filer. > 2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. > and watch the "BUG" messages in the /var/log/messages file. > > 3) Log out. (so the automounter tries to unmount everything that was mounted). > 4) Log in again, after 30 minutes and by then you won't be about to > mount anything anymore > > You can replace steps 3 and 4 with "init 6". When the automounter process > is stopped by init, you will see the port messages scroll up the console > screen. > > EXAMPLE OF REPRODUCING THE PROBLEM: > > codered-51: cd /net/aflac/vol/vol2 > ( I can't help but wonder if this BUG message that shows up once a minute > is indicative of a problem ) > > codered-52: tail -f /var/log/messages > Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac > Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already > mounted > ... (continues once a minute to print out this bug) ... > codered-53: sudo init 6 > (after reboot log in to see error messages) > > THE REALLY WEIRD PART: > Now the interesting thing here is that the machine is rebooting, so > there is no program requesting additional mounts, yet here in the log > files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 > and /vol/vol3 are attempted to be mounted, even though the only > thing that should be happening is an unmount of the directory aflac:/vol/vol2 > > jetcar-189: cd /net/aflac/vol/vol3 > jetcar-190: ls > ad1983/ cad_archive/ emerald/ layout_old/ ta/ > archive/ design/ is_013std/ lx3/ > jetcar-191: cd ../vol2 > jetcar-192: ls > 9xcores/ danube/ nwd_layout/ ulc3/ > DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ > WWM/ gpdsp_marketing/ pc_backups/ > bitpower/ india_mirror/ sh/ > bluetooth/ nile/ spitfire/ > jetcar-194: cd ../vol1 > etcar-195: ls > IssueManager/ diablo/ is_013std/ ras/ tigersharc/ > admin/ ed/ jordan/ soft/ > archive/ fsp/ nwd_fsp@ teton_lite/ > cpd/ herc_eval/ pe_workspace/ thor/ > > > codered-54: less /var/log/messages > Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:17 codered autofs: automount -USR2 succeeded > Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:20 codered autofs: automount -USR2 succeeded > Jan 11 15:51:23 codered autofs: automount -USR2 succeeded > Jan 11 15:51:26 codered autofs: automount -USR2 succeeded > Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, > bad superblock on aflac:/vol/vol2/spitfire, > Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file > sys > tems > Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure > aflac:/ > vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed > Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed > Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, > bad superblock on aflac:/vol/vol2/ulc3, > Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file > systems > Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure > aflac:/vol/vol2/ulc3 on /net/aflac/vol/vol2/ulc3 > ... > This same pattern of error messages repeats for (in this order) > aflac:/vol/vol2/win2k > aflac:/vol/vol3/ad1983 > aflac:/vol/vol3/archive > aflac:/vol/vol3/cad_archive > aflac:/vol/vol3/design > aflac:/vol/vol3/emerald > aflac:/vol/vol3 > aflac:/vol/vol3/is_013std > aflac:/vol/vol3/layout_old > aflac:/vol/vol3/lx3 > aflac:/vol/vol3/ta > aflac:/vol/vol2/DSPS_Finance > aflac:/vol/vol2 > aflac:/vol/vol2/gpdsp_marketing > aflac:/vol/vol2/gpdsp_PLD > aflac:/vol/vol2/india_mirror > aflac:/vol/vol2/nile > aflac:/vol/vol2/nwd_layout > aflac:/vol/vol2/nwd_testmgr > aflac:/vol/vol2/pc_backups > aflac:/vol/vol2/sh > > aflac:/vol/vol2/spitfire (repeats the whole thing again) > eventually gets to vol1: > ... > aflac:/vol/vol3/ta > aflac:/vol/vol1/pe_workspace > aflac:/vol/vol1/ras > aflac:/vol/vol1/soft > aflac:/vol/vol1/teton_lite > aflac:/vol/vol1/thor > aflac:/vol/vol1/tigersharc > aflac:/vol/vol2/9xcores > aflac:/vol/vol2/bitpower > aflac:/vol/vol2/bluetooth > aflac:/vol/vol2/danube > aflac:/vol/vol2/DSPS_Finance > ... (repeats the whole thing again)... > > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/ta > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/lx3 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol3/layout_old > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol3/is_013std > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/win2k > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/ulc3 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/spitfire > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/sh > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/pc_backups > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/nwd_testmgr > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/nwd_layout > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/nile > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/india_mirror > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/gpdsp_marketing > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol2/gpdsp_PLD > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/tigersharc > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/thor > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/teton_lite > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/soft > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/ras > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/pe_workspace > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/jordan > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/is_013std > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/herc_eval > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/fsp > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: > /net/aflac/vol/vol1/IssueManager > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol0 > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac > Jan 11 15:51:37 codered automount[15971]: expired /net/aflac > Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac > Jan 11 15:51:37 codered automount[15974]: expired /net/aflac > Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac > Jan 11 15:51:37 codered automount[15975]: expired /net/aflac > Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac > Jan 11 15:51:37 codered automount[15976]: expired /net/aflac > Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac > Jan 11 15:51:37 codered automount[15977]: expired /net/aflac > Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac > Jan 11 15:51:38 codered automount[15978]: expired /net/aflac > Jan 11 15:51:38 codered autofs: automount -USR2 succeeded > Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol3 > Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol2 > Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol1 > Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol > Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac > Jan 11 15:51:38 codered automount[15986]: expired /net/aflac > Jan 11 15:51:39 codered automount[6214]: can't shutdown: filesystem /net still > busy > .... (keeps repeating) .... > Jan 11 15:51:45 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:47 codered autofs: automount shutdown failed > > > > HOW IT WAS FIXED IN REDHAT 8: > > Dwight had implemented his fix in 3 steps for Redhat 8: > 1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix > 2) He patched his kernel with the autofs4-2.4.20-20040508.patch > (is some equivalent patch needed for Redhat 3 Enterprise 3 which uses > kernel 2.4.21-20 ? > 3) He changed the way he exported filesystems from the Netapp: > > "The last issue was the matter of how /vol/vol0 is exported from a > Network Appliance filer. We found that the following exports broke > autofs4: > > /vol/vol0 -root=node1:node2:node3:node4 > /vol/vol0 -rw,root=node1:node2:node3 > /vol/vol0 -anon=0 > > The export syntax that worked was: > > /vol/vol0 -rw=node1:node2,root=node1,node2 > " > > WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: > > Now when I tried to do something similar, I found that if you weren't > on node1 or node2, the filesystem was read-only, so I had to do this: > > /vol/vol1 -rw=node1:node2,root=node1,node2 > /vol/vol1/foo1 -root=node1:node2 > /vol/vol1/foo2 -root=node1:node2 > > This way if you cd /net/filer/vol/vol1 it was read-only for most machines > but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. > > So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, > plus using autofs-4.1.3-67 has not yet solved the problem yet for our > Redhat Enterprise 3 clients. > > CONCLUSION: > > I hope this is enough info to track down this problem. It appears > as though the interaction of using /net with a Netapp is causing > spurious mounts, and unmounting is not working. I will assist with > any patch tests that you require, so let me know, and I will be able > to verify any fixes. > > Thanks, > > -Dave > > ________________________________________________________________________ > David Meleedy Analog Devices, Inc. > David.Meleedy@analog.com Three Technology Way > Phone: 781 461 3494 Norwood, MA 02062-9106 USA > > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 13:08:57 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CL8uIB019129 for ; Wed, 12 Jan 2005 13:08:57 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKuApn006089; Wed, 12 Jan 2005 12:56:22 -0800 Received: from nwd2mail3.analog.com (nwd2mail3.analog.com [137.71.25.52]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKu7HH006081 for ; Wed, 12 Jan 2005 12:56:07 -0800 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail3.analog.com (8.12.10/8.12.10) with ESMTP id j0CKu2gF021029 for ; Wed, 12 Jan 2005 15:56:02 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id PAA17905 for ; Wed, 12 Jan 2005 15:56:00 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0CKtxrT011294; Wed, 12 Jan 2005 15:55:59 -0500 (EST) Message-Id: <200501122055.j0CKtxrT011294@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: Dwight Marzolf In-reply-to: Your message of "Wed, 12 Jan 2005 11:13:56 EST." <41E54CC4.3090600@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2005 15:55:59 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.52 Cc: autofs@linux.kernel.org Subject: [autofs] Re: BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > Dave, > > >Now when I tried to do something similar, I found that if you weren't > >on node1 or node2, the filesystem was read-only, so I had to do this: > > > >/vol/vol1 -rw=node1:node2,root=node1,node2 > >/vol/vol1/foo1 -root=node1:node2 > >/vol/vol1/foo2 -root=node1:node2 > > On this one here, the top line is correct but the other two lines should be: > > /vol/vol1/foo1 -rw,root=node1:node2 > /vol/vol1/foo2 -rw,root=node1:node2 > > This way, the vol/vol1 dir does not mount when you cd to > /net/machine/vol/vol1 but the other two directories do mount and are > accessible by all workstations that need to read and write to it. This > should work under both RedHat 8 and Enterprise 3. Now, I don't know why > autofs4 seems to require the exports to be this way on a netapp box when > Solaris didn't seem to care but this is what is working for us. > > Dwight Marzolf I tried changing the syntax, as you suggested, and I got the following error: aflac> exportfs -a export: No "=" in "rw" option exportfs: invalid option, /vol/vol1/IssueManager not exported export: No "=" in "rw" option exportfs: invalid option, /vol/vol1/admin not exported ... etc ... Here is the actual entry from the exports file on the filer: /vol/vol1/IssueManager -rw,root=sloth.spd.analog.com:zeus.spd.analog.com:chimc h im.spd.analog.com:chimchim-ge2.spd.analog.com:thrak.spd.analog.com:mr_coffee.sp d .analog.com:jetcar.spd.analog.com:topgun.spd.analog.com:cyclone.spd.analog.com But my understanding anyway is that by default the permission for an exported filesystem on the filer should be -rw anyway, so I'm not sure why you would have to specify it. -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:00:50 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CM0nm5019923 for ; Wed, 12 Jan 2005 14:00:50 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKhxm6003628; Wed, 12 Jan 2005 12:44:42 -0800 Received: from nwd2mail3.analog.com (nwd2mail3.analog.com [137.71.25.52]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKhuj4003608 for ; Wed, 12 Jan 2005 12:43:57 -0800 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail3.analog.com (8.12.10/8.12.10) with ESMTP id j0CKhugF019372; Wed, 12 Jan 2005 15:43:56 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id PAA15789; Wed, 12 Jan 2005 15:43:53 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0CKhqY2011152; Wed, 12 Jan 2005 15:43:52 -0500 (EST) Message-Id: <200501122043.j0CKhqY2011152@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: Your message of "Wed, 12 Jan 2005 11:55:36 EST." <41E55688.9070107@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2005 15:43:52 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.52 Cc: autofs@linux.kernel.org, Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > Out of curiosity, can we see the output of showmount -e against your filer? codered-51: showmount -e aflac Export list for aflac: /vol/vol2/9xcores (everyone) /vol/vol2/gpdsp_marketing (everyone) /vol/vol1/thor (everyone) /vol/vol1/admin (everyone) /vol/vol3/is_013std (everyone) /vol/vol1/pe_workspace (everyone) /vol/vol1 (everyone) /vol/vol2/spitfire (everyone) /vol/vol3/layout_old (everyone) /vol/vol1/jordan (everyone) /vol/vol2/DSPS_Finance (everyone) /vol/vol2/sh (everyone) /vol/vol2/gpdsp_PLD (everyone) /vol/vol1/tigersharc (everyone) /vol/vol1/ed (everyone) /vol/vol3/ta (everyone) /vol/vol2 (everyone) /vol/vol2/pc_backups (everyone) /vol/vol2/india_mirror (everyone) /vol/vol2/ulc3 (everyone) /vol/vol1/is_013std (everyone) /vol/vol3/lx3 (everyone) /vol/vol2/danube (everyone) /vol/vol3 (everyone) /vol/vol1/teton_lite (everyone) /vol/vol3/emerald (everyone) /vol/vol3/archive (everyone) /vol/vol1/diablo (everyone) /vol/vol2/nwd_testmgr (everyone) /vol/vol1/ras (everyone) /vol/vol1/soft (everyone) /vol/vol2/nile (everyone) /vol/vol2/bluetooth (everyone) /vol/vol3/ad1983 (everyone) /vol/vol1/IssueManager (everyone) /vol/vol3/cad_archive (everyone) /vol/vol2/win2k (everyone) /vol/vol2/nwd_layout (everyone) /vol/vol1/cpd (everyone) /vol/vol3/design (everyone) /vol/vol1/herc_eval (everyone) /vol/vol0 (everyone) /vol/vol2/bitpower (everyone) /vol/vol1/fsp (everyone) /vol/vol1/archive (everyone) codered-52: /etc/auto.net aflac -fstype=nfs,hard,intr,nodev,nosuid \ /vol/vol0 aflac:/vol/vol0 \ /vol/vol1/admin aflac:/vol/vol1/admin \ /vol/vol1/archive aflac:/vol/vol1/archive \ /vol/vol1/cpd aflac:/vol/vol1/cpd \ /vol/vol1/diablo aflac:/vol/vol1/diablo \ /vol/vol1/ed aflac:/vol/vol1/ed \ /vol/vol1 aflac:/vol/vol1 \ /vol/vol1/fsp aflac:/vol/vol1/fsp \ /vol/vol1/herc_eval aflac:/vol/vol1/herc_eval \ /vol/vol1/is_013std aflac:/vol/vol1/is_013std \ /vol/vol1/IssueManager aflac:/vol/vol1/IssueManager \ /vol/vol1/jordan aflac:/vol/vol1/jordan \ /vol/vol1/pe_workspace aflac:/vol/vol1/pe_workspace \ /vol/vol1/ras aflac:/vol/vol1/ras \ /vol/vol1/soft aflac:/vol/vol1/soft \ /vol/vol1/teton_lite aflac:/vol/vol1/teton_lite \ /vol/vol1/thor aflac:/vol/vol1/thor \ /vol/vol1/tigersharc aflac:/vol/vol1/tigersharc \ /vol/vol2/9xcores aflac:/vol/vol2/9xcores \ /vol/vol2/bitpower aflac:/vol/vol2/bitpower \ /vol/vol2/bluetooth aflac:/vol/vol2/bluetooth \ /vol/vol2/danube aflac:/vol/vol2/danube \ /vol/vol2/DSPS_Finance aflac:/vol/vol2/DSPS_Finance \ /vol/vol2 aflac:/vol/vol2 \ /vol/vol2/gpdsp_marketing aflac:/vol/vol2/gpdsp_marketing \ /vol/vol2/gpdsp_PLD aflac:/vol/vol2/gpdsp_PLD \ /vol/vol2/india_mirror aflac:/vol/vol2/india_mirror \ /vol/vol2/nile aflac:/vol/vol2/nile \ /vol/vol2/nwd_layout aflac:/vol/vol2/nwd_layout \ /vol/vol2/nwd_testmgr aflac:/vol/vol2/nwd_testmgr \ /vol/vol2/pc_backups aflac:/vol/vol2/pc_backups \ /vol/vol2/sh aflac:/vol/vol2/sh \ /vol/vol2/spitfire aflac:/vol/vol2/spitfire \ /vol/vol2/ulc3 aflac:/vol/vol2/ulc3 \ /vol/vol2/win2k aflac:/vol/vol2/win2k \ /vol/vol3/ad1983 aflac:/vol/vol3/ad1983 \ /vol/vol3/archive aflac:/vol/vol3/archive \ /vol/vol3/cad_archive aflac:/vol/vol3/cad_archive \ /vol/vol3/design aflac:/vol/vol3/design \ /vol/vol3/emerald aflac:/vol/vol3/emerald \ /vol/vol3 aflac:/vol/vol3 \ /vol/vol3/is_013std aflac:/vol/vol3/is_013std \ /vol/vol3/layout_old aflac:/vol/vol3/layout_old \ /vol/vol3/lx3 aflac:/vol/vol3/lx3 \ /vol/vol3/ta aflac:/vol/vol3/ta ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:01:01 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CM0xEs019929 for ; Wed, 12 Jan 2005 14:00:59 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CGGuKY021005; Wed, 12 Jan 2005 08:16:59 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CGGqER020987 for ; Wed, 12 Jan 2005 08:16:53 -0800 Received: from donald.themaw.net (203-59-50-123.dyn.iinet.net.au [203.59.50.123]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0CGHllm017009 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Jan 2005 00:17:47 +0800 Date: Thu, 13 Jan 2005 00:09:05 +0800 (WST) From: raven@themaw.net To: abo Subject: Re: [autofs] can write on smb resource In-Reply-To: <20050112165724.45d20f9a@localhost> Message-ID: References: <20050112165724.45d20f9a@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 12 Jan 2005, abo wrote: > hi! > > im using an ldap server to mount several smb resources. i can get it > mounted with no problems except i can't write on it even with rw option. > i think this is something regarding the fact that files are owned by > root. i know that autofs always mount things as root, so how can i avoid > this problem? This is a known problem without any resolution yet. You need to specify the credentials in you autofs maps. autofs doesn't know anything about who is doing the mount and so can't even look up credentials if they were stored somewhere. Maybe someone on the list has a suggestion for working around this. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:01:11 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CM0xEu019929 for ; Wed, 12 Jan 2005 14:01:10 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CFuwPQ017121; Wed, 12 Jan 2005 07:57:01 -0800 Received: from smtp.riu.es (smtp.riu.es [195.57.233.204]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CFuqkp017001 for ; Wed, 12 Jan 2005 07:56:54 -0800 Received: from localhost ([192.168.2.96]) by smtp.riu.es (8.13.2/8.13.2/Debian-1) with ESMTP id j0CFuRES027644 for ; Wed, 12 Jan 2005 16:56:28 +0100 Date: Wed, 12 Jan 2005 16:57:24 +0100 From: abo To: autofs@linux.kernel.org Message-ID: <20050112165724.45d20f9a@localhost> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/634/Sun Dec 19 22:21:52 2004 clamav-milter version 0.80j on localhost X-Virus-Status: Clean X-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_10,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] can write on smb resource X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: hi! im using an ldap server to mount several smb resources. i can get it mounted with no problems except i can't write on it even with rw option. i think this is something regarding the fact that files are owned by root. i know that autofs always mount things as root, so how can i avoid this problem? thx abo _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:01:11 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CM0xEw019929 for ; Wed, 12 Jan 2005 14:01:11 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CFgcpX012985; Wed, 12 Jan 2005 07:42:42 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CFgUfN012976 for ; Wed, 12 Jan 2005 07:42:31 -0800 Received: from donald.themaw.net (203-59-50-123.dyn.iinet.net.au [203.59.50.123]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0CFhElm015988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jan 2005 23:43:19 +0800 Date: Wed, 12 Jan 2005 23:34:33 +0800 (WST) From: raven@themaw.net To: abo Subject: Re: [autofs] Help with automounting from a LDAP server In-Reply-To: <20050111102356.0709bcef@localhost> Message-ID: References: <87llb1oi7g.fsf@tango.dre.vanderbilt.edu> <87pt0czb00.fsf@tango.dre.vanderbilt.edu> <20050111102356.0709bcef@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 11 Jan 2005, abo wrote: > sorry about this newbie question, but can you explain what exactly > direct mounts/maps is? That's a little difficult but ... An example of an indirect map might be: in the master map /home /etc/auto.indirect and auto.indirect might have user1 server1:/home/userdir1 user2 server1:/home/userdir2 .... An example of a direct map might be: /- /etc/auto.direct and in auto.direct might have /nfs/apps/geoapp1 server1:/apps/geoapplication /nfs/apps/geoapp2 server2:/apps/application2 /nfs/data/mydata data1:/data/north/mydata /global/data/theirdata other:/data/test ... Direct mount maps always have /- in the master map whereas indirect maps always have their base directory. Direct mount keys are always full paths wheras in an indirect mount the key is always a single directory component. You can't have nested mounts in a direct map either. Check out Managing NFS and NIS 2nd edition, O'Reilly, chapter 13. > > thx > > > On Tue, 11 Jan 2005 16:39:40 +0800 (WST) > Ian Kent wrote: > >> On Tue, 11 Jan 2005, Krishnakumar B wrote: >> >>>> Can't do that at present. Direct mounts are not fully > implemented. >>> >>> My manpage for autofs(5) claims the following: >>> >>> UNSUPPORTED >>> This version of the automounter supports direct maps for > FILE, NIS >>> and LDAP maps only and handles SunOS-style replicated > filesystems >>> only to the extent that mount(8) does. >> >> Perhaps I need to change this to be more accurate. >> >>> >>> So is my manpage wrong, or does "direct maps" mean something other > than >>> "direct mounts"? Or are you referring to the following limitation > (from >>> README.direct v1.3). >>> >>> NOTE: Due to current design limitations, direct maps will take over > an >>> entire directory hierarchy. What this means is, if your direct map > key is >>> /usr/share/bilbo, then /usr will become an automount mount point, > mounting >>> over the existing /usr. >> >> I'm refering to the design limitation mentioned in this note. >> >> This will continue to be the case in 4.1.4 (in fact 4.1.x). >> >> I plan on creating a 4.2.0 development branch at some point fairly > soon. >> This will be the top priority for that development. >> >> Ian >> >> _______________________________________________ >> autofs mailing list >> autofs@linux.kernel.org >> http://linux.kernel.org/mailman/listinfo/autofs > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:01:12 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CM0xF0019929 for ; Wed, 12 Jan 2005 14:01:11 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CEwwNW005041; Wed, 12 Jan 2005 06:59:35 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CEwp46004905 for ; Wed, 12 Jan 2005 06:58:52 -0800 Received: from donald.themaw.net (203-59-50-123.dyn.iinet.net.au [203.59.50.123]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0CEx3lm014987 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jan 2005 22:59:05 +0800 Date: Wed, 12 Jan 2005 22:50:22 +0800 (WST) From: raven@themaw.net To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> Message-ID: References: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 11 Jan 2005, David Meleedy wrote: > > Hi Ian & Jeff, > I am trying to track down an autofs issue that has been > plaguing us. It seems to be caused by the interaction of autofs version > 4 with a Network Appliance server, and cd'ing to /net directories > on the Netapp server. > > A similar issue was seen in Analog Devices in Redhat 8, and apparently > the problem was worked around by Dwight Marzolf working with Ian Kent's > help. So following what Dwight did I have been trying to recreate the fix > for Redhat Enterprise 3 update 3, and so far have not met with success. > > THE PROBLEM DESCRIPTION: > > Autofs hangs and refuses to mount any directories for a period of time > after cd'ing to /net//vol/vol[0-3] and waiting a while. > The only way to clear this is to reboot the client. OK. This is interesting to me as your description below indicates that autofs is poorly behaved in this hostile evironment (aka. it's not dealing with this unusual situation at all well). Also I'd like to add I've been seeing these symptoms in testing my new version on FC with a good number of entries in a master map (ie. >50). It was clear from a "netstat --inet" that mount was causing several connections for each mount attempt. autofs, in this case, doesn't do any probing or opening of connections, it just calls mount. This, and Mikes' comments regarding RPC transport multiplexing, has caused me to dig out a patch that I worked on some time ago. It was originally written by the NFS maintainer but never completed or tested. Unfortuneately, I gave up on it when I tried to merge it into a RedHat kernel. The patches that had been appled to the RH kernel made it very difficult to apply, largely because my understanding of the RPC subsystem is just not good enough. The patch that I worked on is very different to the one Mike proposed but achieves the same thing. There are other obstacles to having an RPC multiplexing patch accepted as well, but, maybe later. So there are some options here. > > Initially we started using the following software (Redhat Enterprise 3 update > 3) > autofs 4.1.3-12 > kernel 2.4.21-20 > nfs-utils 1.0.6-31EL I don't have access to these kernel sources. That will be a problem as I don't know what autofs4 patches have been applied. Jeff? You really should add util-linux to the list of packages to consider in the investigation. It may contain a patch which probes NFS servers and opens a number of connections for each mount. > > WHAT HAS BEEN TRIED SO FAR: > > Mike Waychison, after seeing the messages from our log file said, > > "These messages are due to starvation for reserved ports (< 1024). > Specifically, the kernel will only use ports < 800. Currently, the > kernel uses one port per nfs filesystem. If you mount filesystems very > fast, then you can also run out of reserved ports as the local (mountd > iirc?) will close tcp sessions and each must wait 2 minutes before being > released. > > One solution is to try out the patch I posted last week that allows nfs > mounts to share tcp/udp connections: > > http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 > " > > The problem is we are using a different version of the kernel 2.4, > and his patch was for the 2.6 kernel. Also, although his patch > might make the number of ports available increase, I think it does > not really solve the problem, it just gives more breathing room. I'm not sure about that. The multiplexing of the RPC transport would probably provide a solid solution to your problem by the sound of things. The patches I mentioned above were done against 2.4.22 and 2.6.0. Problem here is that to get a working patch will probably take a while, so we probably need a workaround in the mean time. > > After talking with Jeff Moyer about the issue, I updated autofs to > autofs-4.1.3-67. This was supposed to incorporate a patch that fixes > the port leak problem. Certainly a bug, but not the heart of your problem I'm afraid. > > This did not solve the problem, but it did seem to improve things a bit. > > After looking at Dwight Marzolf's document on his workaround I found > the following information (this is exactly the same sort of thing we > are seeing too): > > " > we quickly found that if you did a cd via /net to one of our Network > Appliance filers (all our other netapp filers worked correctly when > unmounting /net mounts), the port release issue still existed. In > fact, the mountpoints actively took more ports. This meant that if you > mounted this filer with /net, your workstation could be rendered > useless in less than 24 hours. It also became evident that this active > taking of ports by this filer was not limited to just autofs-4.1.3-28 > but also earlier versions of autofs ... Further > research revealed the ports were being taken at the point of automount > timeout. When the automounter had declared these mountpoints to be > timed out and ready to be unmounted and attempted to umount them, in > fact, it ended up remounting them, using new ports for the remount ... > " Do you have any messages on in the log on the server side like: Jan 10 22:01:36 budgie-wl rpc.mountd: refused unmount request from raven-wl.themaw.net for /usr/local/sbin (/usr/local/sbin): illegal port 36233 This indicates that the client has been patched to use non-priveledged ports to increase the number of available ports but the NFS server has not. Just wondering? > > HOW TO REPRODUCE THE PROBLEM: > > Actually in our case we can render a machine useless in just about an > hour or two, and this happens for all of our Netapp filers. The procedure > to do this is reproducible. > > 1) You cd to a /net directory on the filer. > 2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. > and watch the "BUG" messages in the /var/log/messages file. > > 3) Log out. (so the automounter tries to unmount everything that was mounted). > 4) Log in again, after 30 minutes and by then you won't be about to > mount anything anymore > > You can replace steps 3 and 4 with "init 6". When the automounter process > is stopped by init, you will see the port messages scroll up the console > screen. > > EXAMPLE OF REPRODUCING THE PROBLEM: > > codered-51: cd /net/aflac/vol/vol2 > ( I can't help but wonder if this BUG message that shows up once a minute > is indicative of a problem ) > > codered-52: tail -f /var/log/messages > Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac > Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already > mounted > Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already > mounted Seen that lately. Definutely want to get to the bottom of this. I don't yet understand why autofs is getting requests to mount an already mounted file system. Even in a hostile situation autofs needs to deal with this properly. In the past I observed that this might have been somehow related to corruption in /etc/mtab. > ... (continues once a minute to print out this bug) ... > codered-53: sudo init 6 > (after reboot log in to see error messages) > > THE REALLY WEIRD PART: > Now the interesting thing here is that the machine is rebooting, so > there is no program requesting additional mounts, yet here in the log > files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 > and /vol/vol3 are attempted to be mounted, even though the only > thing that should be happening is an unmount of the directory aflac:/vol/vol2 > > jetcar-189: cd /net/aflac/vol/vol3 > jetcar-190: ls > ad1983/ cad_archive/ emerald/ layout_old/ ta/ > archive/ design/ is_013std/ lx3/ > jetcar-191: cd ../vol2 > jetcar-192: ls > 9xcores/ danube/ nwd_layout/ ulc3/ > DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ > WWM/ gpdsp_marketing/ pc_backups/ > bitpower/ india_mirror/ sh/ > bluetooth/ nile/ spitfire/ > jetcar-194: cd ../vol1 > etcar-195: ls > IssueManager/ diablo/ is_013std/ ras/ tigersharc/ > admin/ ed/ jordan/ soft/ > archive/ fsp/ nwd_fsp@ teton_lite/ > cpd/ herc_eval/ pe_workspace/ thor/ > > > codered-54: less /var/log/messages > Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:17 codered autofs: automount -USR2 succeeded > Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:20 codered autofs: automount -USR2 succeeded > Jan 11 15:51:23 codered autofs: automount -USR2 succeeded > Jan 11 15:51:26 codered autofs: automount -USR2 succeeded > Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still > busy > Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, > bad superblock on aflac:/vol/vol2/spitfire, > Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file > sys > tems > Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure > aflac:/ > vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed > Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed Looks like you've run out of priviledged port space here, at least the ones that RPC is trying to use. snip ... > > HOW IT WAS FIXED IN REDHAT 8: > > Dwight had implemented his fix in 3 steps for Redhat 8: > 1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix > 2) He patched his kernel with the autofs4-2.4.20-20040508.patch > (is some equivalent patch needed for Redhat 3 Enterprise 3 which uses > kernel 2.4.21-20 ? > 3) He changed the way he exported filesystems from the Netapp: > > "The last issue was the matter of how /vol/vol0 is exported from a > Network Appliance filer. We found that the following exports broke > autofs4: > > /vol/vol0 -root=node1:node2:node3:node4 > /vol/vol0 -rw,root=node1:node2:node3 > /vol/vol0 -anon=0 > > The export syntax that worked was: > > /vol/vol0 -rw=node1:node2,root=node1,node2 > " This is a bug in the option parsing. I'll need to fix that. > > WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: > > Now when I tried to do something similar, I found that if you weren't > on node1 or node2, the filesystem was read-only, so I had to do this: > > /vol/vol1 -rw=node1:node2,root=node1,node2 > /vol/vol1/foo1 -root=node1:node2 > /vol/vol1/foo2 -root=node1:node2 > > This way if you cd /net/filer/vol/vol1 it was read-only for most machines > but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. > > So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, > plus using autofs-4.1.3-67 has not yet solved the problem yet for our > Redhat Enterprise 3 clients. > > CONCLUSION: > > I hope this is enough info to track down this problem. It appears > as though the interaction of using /net with a Netapp is causing > spurious mounts, and unmounting is not working. I will assist with > any patch tests that you require, so let me know, and I will be able > to verify any fixes. Might be a bit of a long road here but we'll have to see how we go. btw, on average, how many exports do you have on a filer? Regards Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:25:09 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CMP4Ct020082 for ; Wed, 12 Jan 2005 14:25:09 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKuApn006089; Wed, 12 Jan 2005 12:56:22 -0800 Received: from nwd2mail3.analog.com (nwd2mail3.analog.com [137.71.25.52]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CKu7HH006081 for ; Wed, 12 Jan 2005 12:56:07 -0800 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail3.analog.com (8.12.10/8.12.10) with ESMTP id j0CKu2gF021029 for ; Wed, 12 Jan 2005 15:56:02 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id PAA17905 for ; Wed, 12 Jan 2005 15:56:00 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0CKtxrT011294; Wed, 12 Jan 2005 15:55:59 -0500 (EST) Message-Id: <200501122055.j0CKtxrT011294@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: Dwight Marzolf In-reply-to: Your message of "Wed, 12 Jan 2005 11:13:56 EST." <41E54CC4.3090600@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2005 15:55:59 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.52 Cc: autofs@linux.kernel.org Subject: [autofs] Re: BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > Dave, > > >Now when I tried to do something similar, I found that if you weren't > >on node1 or node2, the filesystem was read-only, so I had to do this: > > > >/vol/vol1 -rw=node1:node2,root=node1,node2 > >/vol/vol1/foo1 -root=node1:node2 > >/vol/vol1/foo2 -root=node1:node2 > > On this one here, the top line is correct but the other two lines should be: > > /vol/vol1/foo1 -rw,root=node1:node2 > /vol/vol1/foo2 -rw,root=node1:node2 > > This way, the vol/vol1 dir does not mount when you cd to > /net/machine/vol/vol1 but the other two directories do mount and are > accessible by all workstations that need to read and write to it. This > should work under both RedHat 8 and Enterprise 3. Now, I don't know why > autofs4 seems to require the exports to be this way on a netapp box when > Solaris didn't seem to care but this is what is working for us. > > Dwight Marzolf I tried changing the syntax, as you suggested, and I got the following error: aflac> exportfs -a export: No "=" in "rw" option exportfs: invalid option, /vol/vol1/IssueManager not exported export: No "=" in "rw" option exportfs: invalid option, /vol/vol1/admin not exported ... etc ... Here is the actual entry from the exports file on the filer: /vol/vol1/IssueManager -rw,root=sloth.spd.analog.com:zeus.spd.analog.com:chimc h im.spd.analog.com:chimchim-ge2.spd.analog.com:thrak.spd.analog.com:mr_coffee.sp d .analog.com:jetcar.spd.analog.com:topgun.spd.analog.com:cyclone.spd.analog.com But my understanding anyway is that by default the permission for an exported filesystem on the filer should be -rw anyway, so I'm not sure why you would have to specify it. -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 14:29:20 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CMTKDQ020137 for ; Wed, 12 Jan 2005 14:29:20 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CMMmEb029740; Wed, 12 Jan 2005 14:23:03 -0800 Received: from nwd2mail2.analog.com (nwd2mail2.analog.com [137.71.25.51]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CMMiBW029733 for ; Wed, 12 Jan 2005 14:22:44 -0800 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id j0CMMim5018177; Wed, 12 Jan 2005 17:22:44 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id RAA04316; Wed, 12 Jan 2005 17:22:41 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0CMMeMl011886; Wed, 12 Jan 2005 17:22:40 -0500 (EST) Message-Id: <200501122222.j0CMMeMl011886@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: raven@themaw.net Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: Your message of "Wed, 12 Jan 2005 22:50:22 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2005 17:22:40 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.51 Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Answers to questions below: > > Initially we started using the following software (Redhat Enterprise 3 update > > 3) > > autofs 4.1.3-12 > > kernel 2.4.21-20 > > nfs-utils 1.0.6-31EL > > I don't have access to these kernel sources. > That will be a problem as I don't know what autofs4 patches have been > applied. Jeff? Well, I have also tried autofs 4.1.3-67 : Here is a complete list of the patches installed on that version of autofs: Patch1: autofs-4.1.0-hesiod-bind.patch Patch2: autofs-4.1.0-loop.patch Patch3: autofs-4.1.0-auto-master.patch Patch4: autofs-4.1.2-init-redhat-only.patch Patch5: autofs-4.1.3-non-strict-loop-fix.patch Patch12: autofs-4.1.2-option-parsing.patch Patch14: autofs-4.1.3-underlinei18n.patch Patch15: autofs-4.1.3-rpc-ping.patch Patch16: autofs-4.1.3-bad_chdir.patch Patch17: autofs-4.1.3-mtab_lock.patch #Patch18: autofs-4.1.3-ian-map-expiry-1.patch Patch19: autofs-4.1.3-disable-direct.patch Patch20: autofs-4.1.3-umount-loopback.patch Patch21: autofs-4.1.3-localopts-multi.patch Patch22: autofs-4.1.2-init-duplicate-map.patch Patch23: autofs-4.1.3-filemap-etc-append.patch Patch24: autofs-4.1.3-ldap-search-limit.patch Patch25: autofs-4.1.3-replicated_server_select.patch Patch26: autofs-4.1.3-browse.patch Patch27: autofs-4.1.3-sock-leak-fix.patch Patch28: autofs-4.1.3-no-reserved-ports.patch Patch29: autofs-4.1.3-ldap-multiple-map.patch Patch30: autofs-4.1.3-large-program-map.patch > You really should add util-linux to the list of packages to consider in > the investigation. It may contain a patch which probes NFS servers and > opens a number of connections for each mount. So far, haven't found that, but maybe after the list of patches I sent is examined, we'll know for sure. > > > > WHAT HAS BEEN TRIED SO FAR: > > > > Mike Waychison, after seeing the messages from our log file said, > > > > "These messages are due to starvation for reserved ports (< 1024). > > Specifically, the kernel will only use ports < 800. Currently, the > > kernel uses one port per nfs filesystem. If you mount filesystems very > > fast, then you can also run out of reserved ports as the local (mountd > > iirc?) will close tcp sessions and each must wait 2 minutes before being > > released. > > > > One solution is to try out the patch I posted last week that allows nfs > > mounts to share tcp/udp connections: > > > > http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 > > " > > > > The problem is we are using a different version of the kernel 2.4, > > and his patch was for the 2.6 kernel. Also, although his patch > > might make the number of ports available increase, I think it does > > not really solve the problem, it just gives more breathing room. > > I'm not sure about that. > > The multiplexing of the RPC transport would probably provide a solid > solution to your problem by the sound of things. The patches I mentioned > above were done against 2.4.22 and 2.6.0. > > Problem here is that to get a working patch will probably take a while, so > we probably need a workaround in the mean time. Mike sent me a patch for 2.4.21-20.EL that I will test in the near future. However, I know that Redhat also has an "up2date" patch available for the kernel already, so ultimately we need to get the patch applied, if it works. > > After talking with Jeff Moyer about the issue, I updated autofs to > > autofs-4.1.3-67. This was supposed to incorporate a patch that fixes > > the port leak problem. > > Certainly a bug, but not the heart of your problem I'm afraid. agreed. > > > > This did not solve the problem, but it did seem to improve things a bit. > > > > After looking at Dwight Marzolf's document on his workaround I found > > the following information (this is exactly the same sort of thing we > > are seeing too): > > > > " > > we quickly found that if you did a cd via /net to one of our Network > > Appliance filers (all our other netapp filers worked correctly when > > unmounting /net mounts), the port release issue still existed. In > > fact, the mountpoints actively took more ports. This meant that if you > > mounted this filer with /net, your workstation could be rendered > > useless in less than 24 hours. It also became evident that this active > > taking of ports by this filer was not limited to just autofs-4.1.3-28 > > but also earlier versions of autofs ... Further > > research revealed the ports were being taken at the point of automount > > timeout. When the automounter had declared these mountpoints to be > > timed out and ready to be unmounted and attempted to umount them, in > > fact, it ended up remounting them, using new ports for the remount ... > > " > > Do you have any messages on in the log on the server side like: > > Jan 10 22:01:36 budgie-wl rpc.mountd: refused unmount request from > raven-wl.themaw.net for /usr/local/sbin (/usr/local/sbin): illegal port > 36233 > > This indicates that the client has been patched to use non-priveledged > ports to increase the number of available ports but the NFS server has > not. > > Just wondering? Unfortunately not. Our Netapp fileserver is not a unix system, so it does not run rpc.mountd. > > > > HOW TO REPRODUCE THE PROBLEM: > > > > Actually in our case we can render a machine useless in just about an > > hour or two, and this happens for all of our Netapp filers. The procedure > > to do this is reproducible. > > > > 1) You cd to a /net directory on the filer. > > 2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. > > and watch the "BUG" messages in the /var/log/messages file. > > > > 3) Log out. (so the automounter tries to unmount everything that was mounted). > > 4) Log in again, after 30 minutes and by then you won't be about to > > mount anything anymore > > > > You can replace steps 3 and 4 with "init 6". When the automounter process > > is stopped by init, you will see the port messages scroll up the console > > screen. > > > > EXAMPLE OF REPRODUCING THE PROBLEM: > > > > codered-51: cd /net/aflac/vol/vol2 > > ( I can't help but wonder if this BUG message that shows up once a minute > > is indicative of a problem ) > > > > codered-52: tail -f /var/log/messages > > Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac > > Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already > > mounted > > Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already > > mounted > > Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already > > mounted > > Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already > > mounted > > Seen that lately. Definutely want to get to the bottom of this. > > I don't yet understand why autofs is getting requests to mount an already > mounted file system. Even in a hostile situation autofs needs to deal > with this properly. Well, one thing I am noticing is that it can never unmount or expire /net/aflac once it is mounted. So maybe during each 1 minute timeout, it tries to expire the mount, and then when it fails, it tries to assert again that it is already mounted by trying to remount it? i.e. what really happens in the code if a mount expiration is thought to be successfull but failed, or is thought to fail. > In the past I observed that this might have been somehow related to > corruption in /etc/mtab. Then this would have to be a consistent corruption across many machines. This happens on over 8 Redhat Enterprise 3 clients (I have a large testbed here). > > ... (continues once a minute to print out this bug) ... > > codered-53: sudo init 6 > > (after reboot log in to see error messages) > > > > THE REALLY WEIRD PART: > > Now the interesting thing here is that the machine is rebooting, so > > there is no program requesting additional mounts, yet here in the log > > files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 > > and /vol/vol3 are attempted to be mounted, even though the only > > thing that should be happening is an unmount of the directory aflac:/vol/vol2 > > > > jetcar-189: cd /net/aflac/vol/vol3 > > jetcar-190: ls > > ad1983/ cad_archive/ emerald/ layout_old/ ta/ > > archive/ design/ is_013std/ lx3/ > > jetcar-191: cd ../vol2 > > jetcar-192: ls > > 9xcores/ danube/ nwd_layout/ ulc3/ > > DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ > > WWM/ gpdsp_marketing/ pc_backups/ > > bitpower/ india_mirror/ sh/ > > bluetooth/ nile/ spitfire/ > > jetcar-194: cd ../vol1 > > etcar-195: ls > > IssueManager/ diablo/ is_013std/ ras/ tigersharc/ > > admin/ ed/ jordan/ soft/ > > archive/ fsp/ nwd_fsp@ teton_lite/ > > cpd/ herc_eval/ pe_workspace/ thor/ > > > > > > codered-54: less /var/log/messages > > Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still > > busy > > Jan 11 15:51:17 codered autofs: automount -USR2 succeeded > > Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still > > busy > > Jan 11 15:51:20 codered autofs: automount -USR2 succeeded > > Jan 11 15:51:23 codered autofs: automount -USR2 succeeded > > Jan 11 15:51:26 codered autofs: automount -USR2 succeeded > > Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still > > busy > > Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, > > bad superblock on aflac:/vol/vol2/spitfire, > > Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file > > sys > > tems > > Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure > > aflac:/ > > vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire > > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed > > Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel > > Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). > > Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 > > Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed > > Looks like you've run out of priviledged port space here, at least the > ones that RPC is trying to use. > > snip ... yup. > > > > HOW IT WAS FIXED IN REDHAT 8: > > > > Dwight had implemented his fix in 3 steps for Redhat 8: > > 1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix > > 2) He patched his kernel with the autofs4-2.4.20-20040508.patch > > (is some equivalent patch needed for Redhat 3 Enterprise 3 which uses > > kernel 2.4.21-20 ? > > 3) He changed the way he exported filesystems from the Netapp: > > > > "The last issue was the matter of how /vol/vol0 is exported from a > > Network Appliance filer. We found that the following exports broke > > autofs4: > > > > /vol/vol0 -root=node1:node2:node3:node4 > > /vol/vol0 -rw,root=node1:node2:node3 > > /vol/vol0 -anon=0 > > > > The export syntax that worked was: > > > > /vol/vol0 -rw=node1:node2,root=node1,node2 > > " > > This is a bug in the option parsing. I'll need to fix that. Well, keep in mind that these are options in our exports file on our Netapp filer, not a linux machine, so perhaps not an issue for you. > > > > WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: > > > > Now when I tried to do something similar, I found that if you weren't > > on node1 or node2, the filesystem was read-only, so I had to do this: > > > > /vol/vol1 -rw=node1:node2,root=node1,node2 > > /vol/vol1/foo1 -root=node1:node2 > > /vol/vol1/foo2 -root=node1:node2 > > > > This way if you cd /net/filer/vol/vol1 it was read-only for most machines > > but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. > > > > So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, > > plus using autofs-4.1.3-67 has not yet solved the problem yet for our > > Redhat Enterprise 3 clients. > > > > CONCLUSION: > > > > I hope this is enough info to track down this problem. It appears > > as though the interaction of using /net with a Netapp is causing > > spurious mounts, and unmounting is not working. I will assist with > > any patch tests that you require, so let me know, and I will be able > > to verify any fixes. > > Might be a bit of a long road here but we'll have to see how we go. > > btw, on average, how many exports do you have on a filer? > > Regards > Ian > ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 15:05:35 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0CN5YMc020280 for ; Wed, 12 Jan 2005 15:05:35 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CN2XSH009150; Wed, 12 Jan 2005 15:02:51 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CN2Uew009141 for ; Wed, 12 Jan 2005 15:02:31 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0CN2QiA015529; Wed, 12 Jan 2005 18:02:26 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0CN2Qr02411; Wed, 12 Jan 2005 18:02:26 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0CN2OmB004460; Wed, 12 Jan 2005 18:02:24 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0CN1lSN013815; Wed, 12 Jan 2005 18:01:47 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0CN1lMb013812; Wed, 12 Jan 2005 18:01:47 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16869.44123.559108.373989@segfault.boston.redhat.com> Date: Wed, 12 Jan 2005 18:01:47 -0500 To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501122222.j0CMMeMl011886@jetcar.spd.analog.com> References: <200501122222.j0CMMeMl011886@jetcar.spd.analog.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org, raven@themaw.net X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; David Meleedy adds: david.meleedy> Answers to questions below: >> > Initially we started using the following software (Redhat Enterprise 3 >> update >> > 3) >> > autofs 4.1.3-12 > kernel 2.4.21-20 > nfs-utils 1.0.6-31EL >> >> I don't have access to these kernel sources. That will be a problem as >> I don't know what autofs4 patches have been applied. Jeff? These sources should be up to date with all of your patches except the autofs4_lookup fixes that you made for the map update functionality. david.meleedy> Well, I have also tried autofs 4.1.3-67 : Here is a complete david.meleedy> list of the patches installed on that version of autofs: david.meleedy> Patch30: autofs-4.1.3-large-program-map.patch I am concerned about the autofs-4.1.3-large-program-map.patch. There was a bug in that, and I want to ensure you have the most recent version, especially since you're using /net. (the -67 rpm you have has the buggy version). I've attached the correct version of the patch. -Jeff --- autofs-4.1.3/modules/lookup_program.c.orig 2004-12-20 10:05:12.272654616 -0500 +++ autofs-4.1.3/modules/lookup_program.c 2004-12-20 10:04:21.336398104 -0500 @@ -84,7 +84,7 @@ int lookup_ghost(const char *root, int g int lookup_mount(const char *root, const char *name, int name_len, void *context) { struct lookup_context *ctxt = (struct lookup_context *) context; - char mapent[MAPENT_MAX_LEN + 1], *mapp; + char *mapent, *mapp, *tmp; char errbuf[1024], *errp; char ch; int pipefd[2], epipefd[2]; @@ -94,11 +94,19 @@ int lookup_mount(const char *root, const fd_set readfds, ourfds; enum state { st_space, st_map, st_done } state; int quoted = 0; - int ret; + int ret = 1; int max_fd; + int distance; + int alloci = 1; debug(MODPREFIX "looking up %s", name); + mapent = (char *)malloc(MAPENT_MAX_LEN + 1); + if (!mapent) { + error(MODPREFIX "malloc: %s\n", strerror(errno)); + return 1; + } + /* * We don't use popen because we don't want to run /bin/sh plus we * want to send stderr to the syslog, and we don't use spawnl() @@ -107,12 +115,12 @@ int lookup_mount(const char *root, const if (pipe(pipefd)) { error(MODPREFIX "pipe: %m"); - return 1; + goto out_free; } if (pipe(epipefd)) { close(pipefd[0]); close(pipefd[1]); - return 1; + goto out_free; } f = fork(); @@ -122,7 +130,7 @@ int lookup_mount(const char *root, const close(epipefd[0]); close(epipefd[1]); error(MODPREFIX "fork: %m"); - return 1; + goto out_free; } else if (f == 0) { reset_signals(); close(pipefd[0]); @@ -177,21 +185,44 @@ int lookup_mount(const char *root, const if (!quoted && ch == '\n') { *mapp = '\0'; state = st_done; - } else if (mapp - mapent < MAPENT_MAX_LEN - 1) { - /* - * Eat \ quoting \n, otherwise pass it - * through for the parser + break; + } + + /* We overwrite up to 3 characters, so we + * need to make sure we have enough room + * in the buffer for this. */ + /* else */ + if (mapp - mapent > + ((MAPENT_MAX_LEN+1) * alloci) - 3) { + /* + * Alloc another page for map entries. */ - if (quoted) { - if (ch == '\n') - *mapp++ = ' '; - else { - *mapp++ = '\\'; - *mapp++ = ch; - } - } else - *mapp++ = ch; + distance = mapp - mapent; + tmp = realloc(mapent, + ((MAPENT_MAX_LEN + 1) * + ++alloci)); + if (!tmp) { + alloci--; + error(MODPREFIX "realloc: %s\n", + strerror(errno)); + break; + } + mapent = tmp; + mapp = tmp + distance; } + /* + * Eat \ quoting \n, otherwise pass it + * through for the parser + */ + if (quoted) { + if (ch == '\n') + *mapp++ = ' '; + else { + *mapp++ = '\\'; + *mapp++ = ch; + } + } else + *mapp++ = ch; break; case st_done: /* Eat characters till there's no more output */ @@ -233,18 +264,20 @@ int lookup_mount(const char *root, const if (waitpid(f, &status, 0) != f) { error(MODPREFIX "waitpid: %m"); - return 1; + goto out_free; } if (mapp == mapent || !WIFEXITED(status) || WEXITSTATUS(status) != 0) { error(MODPREFIX "lookup for %s failed", name); - return 1; + goto out_free; } debug(MODPREFIX "%s -> %s", name, mapent); ret = ctxt->parse->parse_mount(root, name, name_len, mapent, ctxt->parse->context); +out_free: + free(mapent); return ret; } _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 16:41:23 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D0fM1h021196 for ; Wed, 12 Jan 2005 16:41:23 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D0bUB1023727; Wed, 12 Jan 2005 16:37:54 -0800 Received: from nwd2mail1.analog.com (nwd2mail1.analog.com [137.71.25.50]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D0bQUW023719 for ; Wed, 12 Jan 2005 16:37:27 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j0D0bVoU025676; Wed, 12 Jan 2005 19:37:31 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id TAA12251; Wed, 12 Jan 2005 19:37:24 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0D0bNDj012842; Wed, 12 Jan 2005 19:37:23 -0500 (EST) Message-Id: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: Your message of "Wed, 12 Jan 2005 11:55:36 EST." <41E55688.9070107@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2005 19:37:23 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.50 Cc: autofs@linux.kernel.org, Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Mike, I just recompiled my kernel with your xprt-sharing.patch. Although this did fix the port error problems, it did not fix the automounter problem. So I think your patch should be incorporated into Redhat Enterprise 3 (2.4 kernel) because it appears to work. I think the problem is that the automounter just cannot unmount the /net/aflac directory, and ends up trying to remount it instead, here are the log files after the port patch that Mike gave me: (this is during the reboot after cd'ing to /net/aflac/vol/vol2) Jan 12 19:23:36 codered automount[5396]: can't shutdown: filesystem /net still busy Jan 12 19:23:38 codered autofs: automount -USR2 succeeded Jan 12 19:23:41 codered automount[5396]: can't shutdown: filesystem /net still busy ... those lines keep repeating until .... Jan 12 19:24:08 codered automount[16092]: >> mount table full Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure aflac:/vol/vol3/cad_archive on /net/aflac/vol/vol3/cad_archive Jan 12 19:24:08 codered automount[16092]: >> mount table full Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure aflac:/vol/vol3/design on /net/aflac/vol/vol3/design ... those lines repeart for each subdirectory of the volumes ... Jan 12 19:24:09 codered autofs: automount shutdown failed As you can see, it keeps trying to unmount /net, and eventually fills up the mount table because it instead remounts it. Before, when the port issue was a problem, it wouldn't get far enough to fill the mount table, but now it can (thanks Mike!) -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 17:09:12 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D19B61021255 for ; Wed, 12 Jan 2005 17:09:12 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D16EsY032433; Wed, 12 Jan 2005 17:06:30 -0800 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D16AwQ032415 for ; Wed, 12 Jan 2005 17:06:11 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0D16Adv005025 for ; Wed, 12 Jan 2005 18:06:10 -0700 (MST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IA800501DNOJS@mpk-mail1.sfbay.sun.com> (original mail from Michael.Waychison@Sun.COM) for autofs@linux.kernel.org; Wed, 12 Jan 2005 17:06:10 -0800 (PST) Received: from [129.150.26.102] (vpn-129-150-26-102.SFBay.Sun.COM [129.150.26.102]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IA800DPODQ90W@mpk-mail1.sfbay.sun.com>; Wed, 12 Jan 2005 17:06:10 -0800 (PST) Date: Wed, 12 Jan 2005 20:05:42 -0500 From: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> To: David Meleedy Message-id: <41E5C966.8050108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org, Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Meleedy wrote: > Mike, > I just recompiled my kernel with your xprt-sharing.patch. > Although this did fix the port error problems, it did not fix > the automounter problem. So I think your patch should be incorporated > into Redhat Enterprise 3 (2.4 kernel) because it appears to work. There is a bit of hold-back from the NFS guys for getting this included mainstream (what Red Hat does is their own business of course). The reason does make sense.. there is a static number of request slots available per transport session in the current rpc code. Translated: Only 16 io's are capable of being in flight for a given tcp stream with this patch. There is concern that this may impact performance numbers for NFS, though I haven't yet seen hard numbers. The good news is that there has been extensive work done as well to allow for dynamic scaling of the available request slots as part of the rpc transport switch code happening at UMich. I haven't had the chance to play with it though and don't know if it is ready for prime time. The likelyhood of it ever making its way into RHEL3 is pretty low, but I can't speak for others. > > I think the problem is that the automounter just cannot unmount > the /net/aflac directory, and ends up trying to remount it instead, > here are the log files after the port patch that Mike gave me: > (this is during the reboot after cd'ing to /net/aflac/vol/vol2) > > Jan 12 19:23:36 codered automount[5396]: can't shutdown: filesystem /net still > busy > Jan 12 19:23:38 codered autofs: automount -USR2 succeeded > Jan 12 19:23:41 codered automount[5396]: can't shutdown: filesystem /net still > busy > ... those lines keep repeating until .... > > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/cad_archive on /net/aflac/vol/vol3/cad_archive > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/design on /net/aflac/vol/vol3/design > ... those lines repeart for each subdirectory of the volumes ... > > Jan 12 19:24:09 codered autofs: automount shutdown failed > > As you can see, it keeps trying to unmount /net, and eventually > fills up the mount table because it instead remounts it. Before, > when the port issue was a problem, it wouldn't get far enough to > fill the mount table, but now it can (thanks Mike!) > > -Dave > > ________________________________________________________________________ > David Meleedy Analog Devices, Inc. > David.Meleedy@analog.com Three Technology Way > Phone: 781 461 3494 Norwood, MA 02062-9106 USA > > - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5clmdQs4kOxk3/MRAo8LAJ9ud4FiaaXKEM9wdQQqyBxegiz8AQCeNvFF +ZRiL2/tnbqd5BT78pFrAf4= =aNy9 -----END PGP SIGNATURE----- _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 17:10:13 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D1AC2u021262 for ; Wed, 12 Jan 2005 17:10:13 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D17hqx032494; Wed, 12 Jan 2005 17:07:57 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D16ksc032456 for ; Wed, 12 Jan 2005 17:06:47 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0D17alm029287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Jan 2005 09:07:36 +0800 Date: Thu, 13 Jan 2005 09:07:36 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> Message-ID: References: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org, Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 12 Jan 2005, David Meleedy wrote: > > Mike, > I just recompiled my kernel with your xprt-sharing.patch. > Although this did fix the port error problems, it did not fix > the automounter problem. So I think your patch should be incorporated > into Redhat Enterprise 3 (2.4 kernel) because it appears to work. > > I think the problem is that the automounter just cannot unmount > the /net/aflac directory, and ends up trying to remount it instead, > here are the log files after the port patch that Mike gave me: > (this is during the reboot after cd'ing to /net/aflac/vol/vol2) > > Jan 12 19:23:36 codered automount[5396]: can't shutdown: filesystem /net still > busy > Jan 12 19:23:38 codered autofs: automount -USR2 succeeded > Jan 12 19:23:41 codered automount[5396]: can't shutdown: filesystem /net still > busy > ... those lines keep repeating until .... > > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/cad_archive on /net/aflac/vol/vol3/cad_archive > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/design on /net/aflac/vol/vol3/design > ... those lines repeart for each subdirectory of the volumes ... Could I have the full log of this please. >From automount start to destruction. > > Jan 12 19:24:09 codered autofs: automount shutdown failed Does RHEL3 have the more unnamed patch applied? > > As you can see, it keeps trying to unmount /net, and eventually > fills up the mount table because it instead remounts it. Before, > when the port issue was a problem, it wouldn't get far enough to > fill the mount table, but now it can (thanks Mike!) Yes, I know that bit of code. I've always been suspicious of trying to cover up a failure by trying to go back the way you came but I left it like that as I didn't have a better idea for how to handle the situation. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 18:43:54 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D2hrwu021449 for ; Wed, 12 Jan 2005 18:43:54 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D2fZ4p026600; Wed, 12 Jan 2005 18:41:51 -0800 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j098rsbR014964 for ; Sun, 9 Jan 2005 00:53:55 -0800 Received: from [217.10.38.130] (port=54536 helo=mipter.zuzino.mipt.ru) by mx1.mail.ru with esmtp id 1CnYpd-000Ixr-00; Sun, 09 Jan 2005 11:53:53 +0300 From: Alexey Dobriyan To: "H. Peter Anvin" Date: Sun, 9 Jan 2005 11:34:08 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501091134.08899.adobriyan@mail.ru> X-Spam: Not detected X-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_01,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 12 Jan 2005 18:41:34 -0800 Cc: autofs@linux.kernel.org Subject: [autofs] [PATCH] autofs: s/0/NULL/ in pointer context X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Signed-off-by: Alexey Dobriyan Index: linux-2.6.10-bk11-warnings/fs/autofs/waitq.c =================================================================== --- linux-2.6.10-bk11-warnings/fs/autofs/waitq.c (revision 8) +++ linux-2.6.10-bk11-warnings/fs/autofs/waitq.c (revision 9) @@ -183,7 +183,7 @@ { struct autofs_wait_queue *wq, **wql; - for ( wql = &sbi->queues ; (wq = *wql) != 0 ; wql = &wq->next ) { + for ( wql = &sbi->queues ; (wq = *wql) != NULL ; wql = &wq->next ) { if ( wq->wait_queue_token == wait_queue_token ) break; } _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 18:45:13 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D2jCHR021459 for ; Wed, 12 Jan 2005 18:45:12 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D2hK30026716; Wed, 12 Jan 2005 18:43:34 -0800 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CGuAwP027050 for ; Wed, 12 Jan 2005 08:56:15 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0CGu6dv015970 for ; Wed, 12 Jan 2005 09:56:07 -0700 (MST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IA700601QRZWZ@mpk-mail1.sfbay.sun.com> (original mail from Michael.Waychison@Sun.COM) for autofs@linux.kernel.org; Wed, 12 Jan 2005 08:56:06 -0800 (PST) Received: from [129.150.25.210] (vpn-129-150-25-210.SFBay.Sun.COM [129.150.25.210]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IA70014IR1FCO@mpk-mail1.sfbay.sun.com>; Wed, 12 Jan 2005 08:56:06 -0800 (PST) Date: Wed, 12 Jan 2005 11:55:36 -0500 From: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: To: David Meleedy Message-id: <41E55688.9070107@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_WmzMgoWsroTYBCGr/U9JFg)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> X-Spam-Status: No, hits=-8.6 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO, PATCH_UNIFIED_DIFF,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 12 Jan 2005 18:41:34 -0800 Cc: autofs@linux.kernel.org, Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is a multi-part message in MIME format. --Boundary_(ID_WmzMgoWsroTYBCGr/U9JFg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Kent wrote: > Just a quick note before we get deep into this. > > Can you check something for me. > Get the source rpm for util-linux. > Check if there is a patch applied to it to probe for services during > mount (it was a patch in FC). If it is rebuild the rpm without it and test > again. > > On Tue, 11 Jan 2005, David Meleedy wrote: > > >>Hi Ian & Jeff, >> I am trying to track down an autofs issue that has been >>plaguing us. It seems to be caused by the interaction of autofs version >>4 with a Network Appliance server, and cd'ing to /net directories >>on the Netapp server. >> >>A similar issue was seen in Analog Devices in Redhat 8, and apparently >>the problem was worked around by Dwight Marzolf working with Ian Kent's >>help. So following what Dwight did I have been trying to recreate the fix >>for Redhat Enterprise 3 update 3, and so far have not met with success. >> >>THE PROBLEM DESCRIPTION: >> >>Autofs hangs and refuses to mount any directories for a period of time >>after cd'ing to /net//vol/vol[0-3] and waiting a while. >>The only way to clear this is to reboot the client. >> >>Initially we started using the following software (Redhat Enterprise 3 update >>3) >>autofs 4.1.3-12 >>kernel 2.4.21-20 >>nfs-utils 1.0.6-31EL >> >>WHAT HAS BEEN TRIED SO FAR: >> >>Mike Waychison, after seeing the messages from our log file said, >> >>"These messages are due to starvation for reserved ports (< 1024). >>Specifically, the kernel will only use ports < 800. Currently, the >>kernel uses one port per nfs filesystem. If you mount filesystems very >>fast, then you can also run out of reserved ports as the local (mountd >>iirc?) will close tcp sessions and each must wait 2 minutes before being >>released. >> >>One solution is to try out the patch I posted last week that allows nfs >>mounts to share tcp/udp connections: >> >>http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 >>" >> >>The problem is we are using a different version of the kernel 2.4, >>and his patch was for the 2.6 kernel. Also, although his patch >>might make the number of ports available increase, I think it does >>not really solve the problem, it just gives more breathing room. Well, it will pretty much guarantee only one port is used for any given filer for talking to the nfs program. Other ports are still used temporarily to talk to mountd and the portmapper. I've attached patch that applies cleanly to 2.4.21-20.EL, though I haven't had the chance to test it other than by compiling it. >> >>After talking with Jeff Moyer about the issue, I updated autofs to >>autofs-4.1.3-67. This was supposed to incorporate a patch that fixes >>the port leak problem. >> >>This did not solve the problem, but it did seem to improve things a bit. >> >>After looking at Dwight Marzolf's document on his workaround I found >>the following information (this is exactly the same sort of thing we >>are seeing too): >> >>" >>we quickly found that if you did a cd via /net to one of our Network >>Appliance filers (all our other netapp filers worked correctly when >>unmounting /net mounts), the port release issue still existed. In >>fact, the mountpoints actively took more ports. This meant that if you >>mounted this filer with /net, your workstation could be rendered >>useless in less than 24 hours. It also became evident that this active >>taking of ports by this filer was not limited to just autofs-4.1.3-28 >>but also earlier versions of autofs ... Further >>research revealed the ports were being taken at the point of automount >>timeout. When the automounter had declared these mountpoints to be >>timed out and ready to be unmounted and attempted to umount them, in >>fact, it ended up remounting them, using new ports for the remount ... >>" >> Out of curiosity, can we see the output of showmount -e against your filer? - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5VaHdQs4kOxk3/MRAvvhAJ4uOaMXMTE4rjZ6ivLrbyeowcZkuACfdshX yBzl0PSwvsMaQZgKelhmrd4= =vjuL -----END PGP SIGNATURE----- --Boundary_(ID_WmzMgoWsroTYBCGr/U9JFg) Content-type: text/x-patch; name=xprt_sharing-2.4.21-20.EL.patch Content-transfer-encoding: 7BIT Content-disposition: inline; filename=xprt_sharing-2.4.21-20.EL.patch This patch allows for sharing of xprts. This is done by keeping a list of current xprts and passing them back to the caller of xprt_create_proto if they match the specifications required (IP X port X protocol X timeout). We do this multiplexing at the xprt layer as it handles transport creation and destruction. This patch has been tested in a test-only environment but has been able to handle a couple hundreds distinct nfs mounts from the same server over a single tcp stream. This effectively gets rid of the 800 nfs mounts max problem, as long as you aren't mounting from many (800) nfs servers. Signed-off-by: Mike Waychison Index: linux-2.4.20/include/linux/sunrpc/xprt.h =================================================================== --- linux-2.4.20.orig/include/linux/sunrpc/xprt.h 2004-06-24 22:00:25.000000000 -0700 +++ linux-2.4.20/include/linux/sunrpc/xprt.h 2005-01-12 08:23:33.000000000 -0800 @@ -15,6 +15,8 @@ #include #include +#include + /* * The transport code maintains an estimate on the maximum number of out- * standing RPC requests, using a smoothed version of the congestion @@ -161,6 +163,9 @@ struct rpc_xprt { void (*old_write_space)(struct sock *); wait_queue_head_t cong_wait; + + atomic_t count; /* shared xprt refcount */ + struct list_head shared; /* link to shared list */ }; #ifdef __KERNEL__ Index: linux-2.4.20/net/sunrpc/xprt.c =================================================================== --- linux-2.4.20.orig/net/sunrpc/xprt.c 2004-06-21 16:19:58.000000000 -0700 +++ linux-2.4.20/net/sunrpc/xprt.c 2005-01-12 08:20:29.000000000 -0800 @@ -79,6 +79,12 @@ #define XPRT_MAX_BACKOFF (8) /* + * List of shared xprt + */ +static DECLARE_MUTEX(shared_xprt_sem); +static LIST_HEAD(shared_xprt_list); + +/* * Local functions */ static void xprt_request_init(struct rpc_task *, struct rpc_xprt *); @@ -1292,6 +1298,33 @@ xprt_release(struct rpc_task *task) } /* + * Compare two rpc_timeout to see if they are the same. + */ +static int +xprt_is_same_timeout(struct rpc_timeout *left, struct rpc_timeout *right) +{ + /* to_increment isn't used if to_exponential is true */ + return left->to_initval == right->to_initval + && left->to_maxval == right->to_maxval + && left->to_retries == right->to_retries + && left->to_exponential == right->to_exponential + && (left->to_exponential + || (left->to_increment == right->to_increment)); +} + +/* + * Check to see if the timeout is the default timeout. + */ +static int +xprt_is_default_timeout(struct rpc_timeout *to, int proto) +{ + struct rpc_timeout defaultto; + + xprt_default_timeout(&defaultto, proto); + return xprt_is_same_timeout(&defaultto, to); +} + +/* * Set default timeout parameters */ void @@ -1349,6 +1382,8 @@ xprt_setup(struct socket *sock, int prot init_waitqueue_head(&xprt->cong_wait); INIT_LIST_HEAD(&xprt->recv); + INIT_LIST_HEAD(&xprt->shared); + atomic_set(&xprt->count, 1); /* Set timeout parameters */ if (to) { @@ -1490,8 +1525,8 @@ failed: /* * Create an RPC client transport given the protocol and peer address. */ -struct rpc_xprt * -xprt_create_proto(int proto, struct sockaddr_in *sap, struct rpc_timeout *to) +static struct rpc_xprt * +__xprt_create_proto(int proto, struct sockaddr_in *sap, struct rpc_timeout *to) { struct socket *sock; struct rpc_xprt *xprt; @@ -1508,6 +1543,43 @@ xprt_create_proto(int proto, struct sock } /* + * Create an RPC client transport that is shared given the protocol and peer + * address. + */ +struct rpc_xprt * +xprt_create_proto(int proto, struct sockaddr_in *sap, struct rpc_timeout *to) +{ + struct rpc_xprt *xprt; + + down(&shared_xprt_sem); + /* walk the list and find an existing mathing xprt */ + list_for_each_entry(xprt, &shared_xprt_list, shared) { + /* Filter out mismatches */ + if (sap->sin_addr.s_addr != xprt->addr.sin_addr.s_addr) + continue; + if (sap->sin_port != xprt->addr.sin_port) + continue; + if (xprt->prot != proto) + continue; + if (to == NULL && !xprt_is_default_timeout(&xprt->timeout, proto)) + continue; + if (to && !xprt_is_same_timeout(&xprt->timeout, to)) + continue; + + atomic_inc(&xprt->count); + goto out; + } + + /* make a new one */ + xprt = __xprt_create_proto(proto, sap, to); + if (!IS_ERR(xprt)) + list_add(&xprt->shared, &shared_xprt_list); +out: + up(&shared_xprt_sem); + return xprt; +} + +/* * Prepare for transport shutdown. */ void @@ -1536,8 +1608,8 @@ xprt_clear_backlog(struct rpc_xprt *xprt /* * Destroy an RPC transport, killing off all requests. */ -int -xprt_destroy(struct rpc_xprt *xprt) +static int +__xprt_destroy(struct rpc_xprt *xprt) { dprintk("RPC: destroying transport %p\n", xprt); xprt_shutdown(xprt); @@ -1546,3 +1618,20 @@ xprt_destroy(struct rpc_xprt *xprt) return 0; } + +/* + * Destroy a shared RPC transport. + * (XXX: what about the remaining live requests?) + */ +int +xprt_destroy(struct rpc_xprt *xprt) +{ + int ret = 0; + down(&shared_xprt_sem); + if (atomic_dec_and_test(&xprt->count)) { + list_del_init(&xprt->shared); + ret = __xprt_destroy(xprt); + } + up(&shared_xprt_sem); + return ret; +} --Boundary_(ID_WmzMgoWsroTYBCGr/U9JFg) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --Boundary_(ID_WmzMgoWsroTYBCGr/U9JFg)-- From autofs-bounces@linux.kernel.org Wed Jan 12 18:50:43 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D2ogio021472 for ; Wed, 12 Jan 2005 18:50:43 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D2gk7f026660; Wed, 12 Jan 2005 18:42:59 -0800 Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j098rtIO014966 for ; Sun, 9 Jan 2005 00:53:55 -0800 Received: from [217.10.38.130] (port=54536 helo=mipter.zuzino.mipt.ru) by mx1.mail.ru with esmtp id 1CnYpe-000Ixr-00; Sun, 09 Jan 2005 11:53:54 +0300 From: Alexey Dobriyan To: Ian Kent Date: Sun, 9 Jan 2005 11:35:38 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501091135.38855.adobriyan@mail.ru> X-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_01,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 12 Jan 2005 18:41:34 -0800 Cc: autofs@linux.kernel.org Subject: [autofs] [PATCH] autofs4: s/0/NULL/ in pointer context X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Signed-off-by: Alexey Dobriyan Index: linux-2.6.10-bk11-warnings/fs/autofs4/waitq.c =================================================================== --- linux-2.6.10-bk11-warnings/fs/autofs4/waitq.c (revision 9) +++ linux-2.6.10-bk11-warnings/fs/autofs4/waitq.c (revision 10) @@ -275,7 +275,7 @@ struct autofs_wait_queue *wq, **wql; down(&sbi->wq_sem); - for ( wql = &sbi->queues ; (wq = *wql) != 0 ; wql = &wq->next ) { + for ( wql = &sbi->queues ; (wq = *wql) != NULL ; wql = &wq->next ) { if ( wq->wait_queue_token == wait_queue_token ) break; } _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 12 18:51:32 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D2pVP4021478 for ; Wed, 12 Jan 2005 18:51:32 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D2h0eE026692; Wed, 12 Jan 2005 18:43:17 -0800 Received: from nwd2mail2.analog.com (nwd2mail2.analog.com [137.71.25.51]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0CGE4TT020860 for ; Wed, 12 Jan 2005 08:14:04 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id j0CGDwm5022542 for ; Wed, 12 Jan 2005 11:13:58 -0500 Received: from titania.adsdesign.analog.com (titania.adsdesign.analog.com [10.66.62.63]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id LAA12534 for ; Wed, 12 Jan 2005 11:13:56 -0500 (EST) Received: from [10.66.22.21] (clapon [10.66.22.21]) by titania.adsdesign.analog.com (8.10.2+Sun/8.10.2) with ESMTP id j0CGDuq17855; Wed, 12 Jan 2005 11:13:56 -0500 (EST) Message-ID: <41E54CC4.3090600@analog.com> Date: Wed, 12 Jan 2005 11:13:56 -0500 From: Dwight Marzolf User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meleedy References: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> In-Reply-To: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.51 X-Mailman-Approved-At: Wed, 12 Jan 2005 18:41:34 -0800 Cc: autofs@linux.kernel.org Subject: [autofs] Re: BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Dave, >Now when I tried to do something similar, I found that if you weren't >on node1 or node2, the filesystem was read-only, so I had to do this: > >/vol/vol1 -rw=node1:node2,root=node1,node2 >/vol/vol1/foo1 -root=node1:node2 >/vol/vol1/foo2 -root=node1:node2 On this one here, the top line is correct but the other two lines should be: /vol/vol1/foo1 -rw,root=node1:node2 /vol/vol1/foo2 -rw,root=node1:node2 This way, the vol/vol1 dir does not mount when you cd to /net/machine/vol/vol1 but the other two directories do mount and are accessible by all workstations that need to read and write to it. This should work under both RedHat 8 and Enterprise 3. Now, I don't know why autofs4 seems to require the exports to be this way on a netapp box when Solaris didn't seem to care but this is what is working for us. Dwight Marzolf David Meleedy wrote: >Hi Ian & Jeff, > I am trying to track down an autofs issue that has been >plaguing us. It seems to be caused by the interaction of autofs version >4 with a Network Appliance server, and cd'ing to /net directories >on the Netapp server. > >A similar issue was seen in Analog Devices in Redhat 8, and apparently >the problem was worked around by Dwight Marzolf working with Ian Kent's >help. So following what Dwight did I have been trying to recreate the fix >for Redhat Enterprise 3 update 3, and so far have not met with success. > >THE PROBLEM DESCRIPTION: > >Autofs hangs and refuses to mount any directories for a period of time >after cd'ing to /net//vol/vol[0-3] and waiting a while. >The only way to clear this is to reboot the client. > >Initially we started using the following software (Redhat Enterprise 3 update >3) >autofs 4.1.3-12 >kernel 2.4.21-20 >nfs-utils 1.0.6-31EL > >WHAT HAS BEEN TRIED SO FAR: > >Mike Waychison, after seeing the messages from our log file said, > >"These messages are due to starvation for reserved ports (< 1024). >Specifically, the kernel will only use ports < 800. Currently, the >kernel uses one port per nfs filesystem. If you mount filesystems very >fast, then you can also run out of reserved ports as the local (mountd >iirc?) will close tcp sessions and each must wait 2 minutes before being >released. > >One solution is to try out the patch I posted last week that allows nfs >mounts to share tcp/udp connections: > >http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 >" > >The problem is we are using a different version of the kernel 2.4, >and his patch was for the 2.6 kernel. Also, although his patch >might make the number of ports available increase, I think it does >not really solve the problem, it just gives more breathing room. > >After talking with Jeff Moyer about the issue, I updated autofs to >autofs-4.1.3-67. This was supposed to incorporate a patch that fixes >the port leak problem. > >This did not solve the problem, but it did seem to improve things a bit. > >After looking at Dwight Marzolf's document on his workaround I found >the following information (this is exactly the same sort of thing we >are seeing too): > >" >we quickly found that if you did a cd via /net to one of our Network >Appliance filers (all our other netapp filers worked correctly when >unmounting /net mounts), the port release issue still existed. In >fact, the mountpoints actively took more ports. This meant that if you >mounted this filer with /net, your workstation could be rendered >useless in less than 24 hours. It also became evident that this active >taking of ports by this filer was not limited to just autofs-4.1.3-28 >but also earlier versions of autofs ... Further >research revealed the ports were being taken at the point of automount >timeout. When the automounter had declared these mountpoints to be >timed out and ready to be unmounted and attempted to umount them, in >fact, it ended up remounting them, using new ports for the remount ... >" > >HOW TO REPRODUCE THE PROBLEM: > >Actually in our case we can render a machine useless in just about an >hour or two, and this happens for all of our Netapp filers. The procedure >to do this is reproducible. > >1) You cd to a /net directory on the filer. >2) Leave the shell in that /net directory for about 15 minutes-> 1/2 an hour. >and watch the "BUG" messages in the /var/log/messages file. > >3) Log out. (so the automounter tries to unmount everything that was mounted). >4) Log in again, after 30 minutes and by then you won't be about to >mount anything anymore > >You can replace steps 3 and 4 with "init 6". When the automounter process >is stopped by init, you will see the port messages scroll up the console >screen. > >EXAMPLE OF REPRODUCING THE PROBLEM: > >codered-51: cd /net/aflac/vol/vol2 >( I can't help but wonder if this BUG message that shows up once a minute >is indicative of a problem ) > >codered-52: tail -f /var/log/messages >Jan 11 15:32:37 codered automount[6214]: attempting to mount entry /net/aflac >Jan 11 15:33:41 codered automount[7915]: BUG: /net/aflac/vol/vol2 already >mounted >Jan 11 15:34:42 codered automount[8049]: BUG: /net/aflac/vol/vol2 already >mounted >Jan 11 15:36:42 codered automount[8311]: BUG: /net/aflac/vol/vol2 already >mounted >Jan 11 15:37:43 codered automount[8441]: BUG: /net/aflac/vol/vol2 already >mounted > ... (continues once a minute to print out this bug) ... >codered-53: sudo init 6 >(after reboot log in to see error messages) > >THE REALLY WEIRD PART: >Now the interesting thing here is that the machine is rebooting, so >there is no program requesting additional mounts, yet here in the log >files you can see that almost every subdirectory of /vol/vol2, /vol/vol3 >and /vol/vol3 are attempted to be mounted, even though the only >thing that should be happening is an unmount of the directory aflac:/vol/vol2 > >jetcar-189: cd /net/aflac/vol/vol3 >jetcar-190: ls >ad1983/ cad_archive/ emerald/ layout_old/ ta/ >archive/ design/ is_013std/ lx3/ >jetcar-191: cd ../vol2 >jetcar-192: ls >9xcores/ danube/ nwd_layout/ ulc3/ >DSPS_Finance/ gpdsp_PLD/ nwd_testmgr/ win2k/ >WWM/ gpdsp_marketing/ pc_backups/ >bitpower/ india_mirror/ sh/ >bluetooth/ nile/ spitfire/ >jetcar-194: cd ../vol1 >etcar-195: ls >IssueManager/ diablo/ is_013std/ ras/ tigersharc/ >admin/ ed/ jordan/ soft/ >archive/ fsp/ nwd_fsp@ teton_lite/ >cpd/ herc_eval/ pe_workspace/ thor/ > > >codered-54: less /var/log/messages >Jan 11 15:51:14 codered automount[6214]: can't shutdown: filesystem /net still >busy >Jan 11 15:51:17 codered autofs: automount -USR2 succeeded >Jan 11 15:51:19 codered automount[6214]: can't shutdown: filesystem /net still >busy >Jan 11 15:51:20 codered autofs: automount -USR2 succeeded >Jan 11 15:51:23 codered autofs: automount -USR2 succeeded >Jan 11 15:51:26 codered autofs: automount -USR2 succeeded >Jan 11 15:51:26 codered automount[6214]: can't shutdown: filesystem /net still >busy >Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, >bad superblock on aflac:/vol/vol2/spitfire, >Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file >sys >tems >Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure >aflac:/ >vol/vol2/spitfire on /net/aflac/vol/vol2/spitfire >Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). >Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 >Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). >Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 >Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed >Jan 11 15:51:28 codered kernel: nfs warning: mount version older than kernel >Jan 11 15:51:28 codered kernel: RPC: Can't bind to reserved port (98). >Jan 11 15:51:28 codered kernel: nfs_get_root: getattr error = 5 >Jan 11 15:51:28 codered kernel: nfs_read_super: get root inode failed >Jan 11 15:51:28 codered automount[14708]: >> mount: wrong fs type, bad option, >bad superblock on aflac:/vol/vol2/ulc3, >Jan 11 15:51:28 codered automount[14708]: >> or too many mounted file >systems >Jan 11 15:51:28 codered automount[14708]: mount(nfs): nfs: mount failure >aflac:/vol/vol2/ulc3 on /net/aflac/vol/vol2/ulc3 >... >This same pattern of error messages repeats for (in this order) >aflac:/vol/vol2/win2k >aflac:/vol/vol3/ad1983 >aflac:/vol/vol3/archive >aflac:/vol/vol3/cad_archive >aflac:/vol/vol3/design >aflac:/vol/vol3/emerald >aflac:/vol/vol3 >aflac:/vol/vol3/is_013std >aflac:/vol/vol3/layout_old >aflac:/vol/vol3/lx3 >aflac:/vol/vol3/ta >aflac:/vol/vol2/DSPS_Finance >aflac:/vol/vol2 >aflac:/vol/vol2/gpdsp_marketing >aflac:/vol/vol2/gpdsp_PLD >aflac:/vol/vol2/india_mirror >aflac:/vol/vol2/nile >aflac:/vol/vol2/nwd_layout >aflac:/vol/vol2/nwd_testmgr >aflac:/vol/vol2/pc_backups >aflac:/vol/vol2/sh > >aflac:/vol/vol2/spitfire (repeats the whole thing again) >eventually gets to vol1: >... >aflac:/vol/vol3/ta >aflac:/vol/vol1/pe_workspace >aflac:/vol/vol1/ras >aflac:/vol/vol1/soft >aflac:/vol/vol1/teton_lite >aflac:/vol/vol1/thor >aflac:/vol/vol1/tigersharc >aflac:/vol/vol2/9xcores >aflac:/vol/vol2/bitpower >aflac:/vol/vol2/bluetooth >aflac:/vol/vol2/danube >aflac:/vol/vol2/DSPS_Finance >... (repeats the whole thing again)... > >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/ta >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3/lx3 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol3/layout_old >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol3/is_013std >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/win2k >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/ulc3 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/spitfire >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2/sh >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/pc_backups >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/nwd_testmgr >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/nwd_layout >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/nile >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/india_mirror >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/gpdsp_marketing >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol2/gpdsp_PLD >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/tigersharc >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/thor >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/teton_lite >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/soft >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/ras >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/pe_workspace >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/jordan >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/is_013std >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/herc_eval >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1/fsp >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: >/net/aflac/vol/vol1/IssueManager >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol/vol0 >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:37 codered automount[15971]: rm_unwanted: /net/aflac >Jan 11 15:51:37 codered automount[15971]: expired /net/aflac >Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:37 codered automount[15974]: rm_unwanted: /net/aflac >Jan 11 15:51:37 codered automount[15974]: expired /net/aflac >Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:37 codered automount[15975]: rm_unwanted: /net/aflac >Jan 11 15:51:37 codered automount[15975]: expired /net/aflac >Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:37 codered automount[15976]: rm_unwanted: /net/aflac >Jan 11 15:51:37 codered automount[15976]: expired /net/aflac >Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:37 codered automount[15977]: rm_unwanted: /net/aflac >Jan 11 15:51:37 codered automount[15977]: expired /net/aflac >Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:38 codered automount[15978]: rm_unwanted: /net/aflac >Jan 11 15:51:38 codered automount[15978]: expired /net/aflac >Jan 11 15:51:38 codered autofs: automount -USR2 succeeded >Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol3 >Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol2 >Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol/vol1 >Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac/vol >Jan 11 15:51:38 codered automount[15986]: rm_unwanted: /net/aflac >Jan 11 15:51:38 codered automount[15986]: expired /net/aflac >Jan 11 15:51:39 codered automount[6214]: can't shutdown: filesystem /net still >busy >.... (keeps repeating) .... >Jan 11 15:51:45 codered automount[6214]: can't shutdown: filesystem /net still >busy >Jan 11 15:51:47 codered autofs: automount shutdown failed > > > >HOW IT WAS FIXED IN REDHAT 8: > >Dwight had implemented his fix in 3 steps for Redhat 8: >1) He updated his autofs to autofs-4.1.3-28 which had the port leak fix >2) He patched his kernel with the autofs4-2.4.20-20040508.patch >(is some equivalent patch needed for Redhat 3 Enterprise 3 which uses >kernel 2.4.21-20 ? >3) He changed the way he exported filesystems from the Netapp: > >"The last issue was the matter of how /vol/vol0 is exported from a >Network Appliance filer. We found that the following exports broke >autofs4: > >/vol/vol0 -root=node1:node2:node3:node4 >/vol/vol0 -rw,root=node1:node2:node3 >/vol/vol0 -anon=0 > >The export syntax that worked was: > >/vol/vol0 -rw=node1:node2,root=node1,node2 >" > >WHAT HAPPENED WHEN I TRIED THE REDHAT 8 WORKAROUND: > >Now when I tried to do something similar, I found that if you weren't >on node1 or node2, the filesystem was read-only, so I had to do this: > >/vol/vol1 -rw=node1:node2,root=node1,node2 >/vol/vol1/foo1 -root=node1:node2 >/vol/vol1/foo2 -root=node1:node2 > >This way if you cd /net/filer/vol/vol1 it was read-only for most machines >but if you cd'd to /net/filer/vol/vol1/foo1 it was read-write. > >So using that Netapp export workaround that fixed the Redhat 8 autofs4 problem, >plus using autofs-4.1.3-67 has not yet solved the problem yet for our >Redhat Enterprise 3 clients. > >CONCLUSION: > >I hope this is enough info to track down this problem. It appears >as though the interaction of using /net with a Netapp is causing >spurious mounts, and unmounting is not working. I will assist with >any patch tests that you require, so let me know, and I will be able >to verify any fixes. > >Thanks, > >-Dave > >________________________________________________________________________ >David Meleedy Analog Devices, Inc. >David.Meleedy@analog.com Three Technology Way >Phone: 781 461 3494 Norwood, MA 02062-9106 USA > > > > > > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 13 00:18:39 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0D8IYWR020380 for ; Thu, 13 Jan 2005 00:18:38 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D8DSPj031440; Thu, 13 Jan 2005 00:14:08 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0D8DAlS031431 for ; Thu, 13 Jan 2005 00:13:12 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0D8DRlm006166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Jan 2005 16:13:28 +0800 Date: Thu, 13 Jan 2005 16:13:27 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <41E55688.9070107@sun.com> Message-ID: References: <200501112122.j0BLMmET002446@jetcar.spd.analog.com> <41E55688.9070107@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org, David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 12 Jan 2005, Mike Waychison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ian Kent wrote: > > Just a quick note before we get deep into this. > > > > Can you check something for me. > > Get the source rpm for util-linux. > > Check if there is a patch applied to it to probe for services during > > mount (it was a patch in FC). If it is rebuild the rpm without it and test > > again. > > > > On Tue, 11 Jan 2005, David Meleedy wrote: > > > > > >>Hi Ian & Jeff, > >> I am trying to track down an autofs issue that has been > >>plaguing us. It seems to be caused by the interaction of autofs version > >>4 with a Network Appliance server, and cd'ing to /net directories > >>on the Netapp server. > >> > >>A similar issue was seen in Analog Devices in Redhat 8, and apparently > >>the problem was worked around by Dwight Marzolf working with Ian Kent's > >>help. So following what Dwight did I have been trying to recreate the fix > >>for Redhat Enterprise 3 update 3, and so far have not met with success. > >> > >>THE PROBLEM DESCRIPTION: > >> > >>Autofs hangs and refuses to mount any directories for a period of time > >>after cd'ing to /net//vol/vol[0-3] and waiting a while. > >>The only way to clear this is to reboot the client. > >> > >>Initially we started using the following software (Redhat Enterprise 3 update > >>3) > >>autofs 4.1.3-12 > >>kernel 2.4.21-20 > >>nfs-utils 1.0.6-31EL > >> > >>WHAT HAS BEEN TRIED SO FAR: > >> > >>Mike Waychison, after seeing the messages from our log file said, > >> > >>"These messages are due to starvation for reserved ports (< 1024). > >>Specifically, the kernel will only use ports < 800. Currently, the > >>kernel uses one port per nfs filesystem. If you mount filesystems very > >>fast, then you can also run out of reserved ports as the local (mountd > >>iirc?) will close tcp sessions and each must wait 2 minutes before being > >>released. > >> > >>One solution is to try out the patch I posted last week that allows nfs > >>mounts to share tcp/udp connections: > >> > >>http://marc.theaimsgroup.com/?l=linux-nfs&m=110261671705396&w=2 > >>" > >> > >>The problem is we are using a different version of the kernel 2.4, > >>and his patch was for the 2.6 kernel. Also, although his patch > >>might make the number of ports available increase, I think it does > >>not really solve the problem, it just gives more breathing room. > > Well, it will pretty much guarantee only one port is used for any given > filer for talking to the nfs program. Other ports are still used > temporarily to talk to mountd and the portmapper. Both of these are a significant problem as well from what I've seen in the netstat output. > > I've attached patch that applies cleanly to 2.4.21-20.EL, though I > haven't had the chance to test it other than by compiling it. > > >> > >>After talking with Jeff Moyer about the issue, I updated autofs to > >>autofs-4.1.3-67. This was supposed to incorporate a patch that fixes > >>the port leak problem. > >> > >>This did not solve the problem, but it did seem to improve things a bit. > >> > >>After looking at Dwight Marzolf's document on his workaround I found > >>the following information (this is exactly the same sort of thing we > >>are seeing too): > >> > >>" > >>we quickly found that if you did a cd via /net to one of our Network > >>Appliance filers (all our other netapp filers worked correctly when > >>unmounting /net mounts), the port release issue still existed. In > >>fact, the mountpoints actively took more ports. This meant that if you > >>mounted this filer with /net, your workstation could be rendered > >>useless in less than 24 hours. It also became evident that this active > >>taking of ports by this filer was not limited to just autofs-4.1.3-28 > >>but also earlier versions of autofs ... Further > >>research revealed the ports were being taken at the point of automount > >>timeout. When the automounter had declared these mountpoints to be > >>timed out and ready to be unmounted and attempted to umount them, in > >>fact, it ended up remounting them, using new ports for the remount ... > >>" > >> > > Out of curiosity, can we see the output of showmount -e against your filer? > > - -- > Mike Waychison > Sun Microsystems, Inc. > 1 (650) 352-5299 voice > 1 (416) 202-8336 voice > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: The opinions expressed in this email are held by me, > and may not represent the views of Sun Microsystems, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB5VaHdQs4kOxk3/MRAvvhAJ4uOaMXMTE4rjZ6ivLrbyeowcZkuACfdshX > yBzl0PSwvsMaQZgKelhmrd4= > =vjuL > -----END PGP SIGNATURE----- > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 14 13:33:10 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0ELX9l1003223 for ; Fri, 14 Jan 2005 13:33:09 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0ELNngj032493; Fri, 14 Jan 2005 13:24:45 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0ELNj7j032486 for ; Fri, 14 Jan 2005 13:23:46 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0ELNdnU018902 for ; Fri, 14 Jan 2005 16:23:44 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0ELNdr18024 for ; Fri, 14 Jan 2005 16:23:39 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0ELNbiS001593 for ; Fri, 14 Jan 2005 16:23:37 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0ELN3Ww027560 for ; Fri, 14 Jan 2005 16:23:03 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0ELN2oA027557; Fri, 14 Jan 2005 16:23:02 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16872.14390.835831.995533@segfault.boston.redhat.com> Date: Fri, 14 Jan 2005 16:23:02 -0500 To: autofs@linux.kernel.org X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] [rft] New autofs rpm available for testing X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This RPM catches up on most of the changes that have been going in of late. Attached is the most recent part of the changelog. You can find the RPMs by following the Fedora Core 4 link on the following page: http://people.redhat.com/jmoyer/ The version is 4.1.3-76, and requires a kernel patch for 2.4 based systems. The current FC3 and FC4 kernels already have the patch applied. This version does contain Ian's map update patch. Happy testing. -Jeff (the changelog is cobbled together from multiple branches, so may be a bit out of order) * Tue Jan 11 2005 Jeff Moyer - 1:4.1.3-76 - Fix the large program map patch. * Tue Jan 11 2005 Jeff Moyer - 1:4.1.3-75 - Fix some merging breakages that caused the package not to build. * Thu Jan 6 2005 - 1:4.1.3-74 - Add in the map expiry patch - Bring in other patches that have been committed to other branches. This version should now contain all fixes we have to date - Merge conflicts due to map expiry changes * Tue Dec 7 2004 Chris Feist - 1:4.1.3-67 - Fixed an error which would cause autofs to attempt to use an uninitialized pointer and segfault. (bz #137220) - Fixed segfault when LDAP_SIZELIMIT_EXCEEDED is called and --ghost is used, addresses bz #137220. * Tue Dec 7 2004 Jeff Moyer - 1:4.1.3-65 - Fix truncation of large program maps. bz #138994 * Mon Dec 7 2004 Chris Feist - 1:4.1.3-64 - Fixed problem with autofs not finding all mount points in an ldap map. bz #139548 * Fri Nov 19 2004 Jeff Moyer - 1:4.1.3-58 - Pass a socket into clntudp_bufcreate so that we don't use up additional reserved ports. This patch, along with the socket leak fix, addresses bz #128966. * Fri Nov 19 2004 Jeff Moyer - 1:4.1.3-57 - Pass a socket into clntudp_bufcreate so that we don't use up additional reserved ports. This patch, along with the socket leak fix, addresses bz #128966. * Wed Nov 17 2004 - 1:4.1.3-56 - Somehow the -browse patch either didn't get committed or got reverted. Fixed. * Tue Nov 16 2004 Jeff Moyer - 1:4.1.3-55 - Fix program maps so that they can have gt 4k characters. (Neil Horman) Addresses bz #138994. - Add a space after the colon here "Starting automounter:" in init script. Fixes bz #138513. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 14 15:01:54 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0EN1rMB003413 for ; Fri, 14 Jan 2005 15:01:54 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0EMcmlk023059; Fri, 14 Jan 2005 14:39:04 -0800 Received: from nwd2mail1.analog.com (nwd2mail1.analog.com [137.71.25.50]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0EMciu3023050 for ; Fri, 14 Jan 2005 14:38:44 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j0EMchoU010510; Fri, 14 Jan 2005 17:38:43 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id RAA23957; Fri, 14 Jan 2005 17:38:37 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0EMcbOT002214; Fri, 14 Jan 2005 17:38:37 -0500 (EST) Message-Id: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: raven@themaw.net Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: Your message of "Fri, 14 Jan 2005 22:35:08 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2005 17:38:37 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.50 Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Ian, I have installed the multi-over patch into our version of the automounter 4.1.3-67 (with updated large-program-map patch) and so far everything looks great! I am going to test our machines for a longer period of time and make sure everything looks stable, but so far, so good! It seems to have eliminated the "BUG" message in the messages file, and it seems as though the automounter can unmount /net/aflac which it was not able to do in the past during a reboot. I suspect that this means it will use a lot less ports, and I might not even need the kernel patch (given the small amount of mounts we actually use) -- I am testing this as well. Thanks! -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 14 19:05:32 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0F35O0Z004282 for ; Fri, 14 Jan 2005 19:05:32 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0F2xhTC003076; Fri, 14 Jan 2005 19:00:29 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0F2xdEF003066 for ; Fri, 14 Jan 2005 18:59:40 -0800 Received: from donald.themaw.net (203-59-212-138.dyn.iinet.net.au [203.59.212.138]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0F30Dlm002384 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 15 Jan 2005 11:00:15 +0800 Date: Sat, 15 Jan 2005 10:50:59 +0800 (WST) From: raven@themaw.net To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 14 Jan 2005, David Meleedy wrote: > > Ian, > I have installed the multi-over patch into our version > of the automounter 4.1.3-67 (with updated large-program-map patch) > and so far everything looks great! I am going to test our machines > for a longer period of time and make sure everything looks stable, > but so far, so good! That sounds very encouraging. Great! > > It seems to have eliminated the "BUG" message in the messages file, > and it seems as though the automounter can unmount /net/aflac > which it was not able to do in the past during a reboot. I suspect > that this means it will use a lot less ports, and I might not > even need the kernel patch (given the small amount of mounts we actually > use) -- I am testing this as well. The BUG messages were placed there to identify this happening as this problem has come up in various forms several times. In this case it appears to be caused by the order in which the mounts are done (ie. received from auto.net). Given that current autofs implementation of multi-mounts must handle them as a single unit, nested filesystem mounts, made in the wrong order, cause overmounting which caused the umount problem. Perhaps. Depends on whether the mount program has the patch which probes the NFS server. The port usage problem still remains and I expect it will continue to cause problems for us one way or another. Hopefully it will be addressed in the near future. Regards Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 17 06:25:37 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0HEPag0002724 for ; Mon, 17 Jan 2005 06:25:37 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HEAh42021375; Mon, 17 Jan 2005 06:11:17 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HEATWc021358 for ; Mon, 17 Jan 2005 06:10:30 -0800 Received: from donald.themaw.net (203-59-212-138.dyn.iinet.net.au [203.59.212.138]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0HEBIlm017013 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 Jan 2005 22:11:19 +0800 Date: Mon, 17 Jan 2005 22:01:31 +0800 (WST) From: raven@themaw.net To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: Message-ID: References: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, PATCH_UNIFIED_DIFF, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, PATCH_UNIFIED_DIFF,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 14 Jan 2005 raven@themaw.net wrote: > > I have attached a patch I'd like you to try please. > Hi David, I've found a small problem with the patch. Please update your rpms with the extra patch below or get the version I have uploaded to the autofs v4 directory on kernel.org. If you look at the code around the second hunk it should be fairly clear how important this could be. Jeff I've called the patch autofs-4.1.3-multi-over.patch if you would like to have a look and perhaps add it to your rpms. Regards Ian --- autofs-4.1.3/modules/parse_sun.c.multi-over-2 2005-01-17 21:50:18.000000000 +0800 +++ autofs-4.1.3/modules/parse_sun.c 2005-01-17 21:51:06.000000000 +0800 @@ -750,7 +750,6 @@ do { char *myoptions = strdup(options); char *path, *loc; - int pathlen, loclen; if (myoptions == NULL) { error(MODPREFIX "multi strdup: %m"); @@ -813,7 +812,7 @@ free(path); free(options); free(myoptions); - multi_free_list(head); + multi_free_list(list); return 1; } } while (*p == '/'); _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 17 06:27:04 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0HER33C002828 for ; Mon, 17 Jan 2005 06:27:03 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HEIjkU022628; Mon, 17 Jan 2005 06:18:48 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0EEhtuj024004 for ; Fri, 14 Jan 2005 06:44:00 -0800 Received: from donald.themaw.net (203-59-212-138.dyn.iinet.net.au [203.59.212.138]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0EEiFlm017949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 14 Jan 2005 22:44:17 +0800 Date: Fri, 14 Jan 2005 22:35:08 +0800 (WST) From: raven@themaw.net To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> Message-ID: References: <200501130037.j0D0bNDj012842@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1629620785-933557400-1105713308=:2519" X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.1, required 8, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Mon, 17 Jan 2005 06:12:57 -0800 Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1629620785-933557400-1105713308=:2519 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Mike, I have attached a patch I'd like you to try please. I think I`ve been able to duplicate the problem here between my Gentoo 2.4 kernel and my Debian 2.4 kernel systems. I've had trouble with NFS export permissions between my FC2 2.6 and the Debian 2.4 systems so I can't be sure about it. I've used the patch, as an additional patch after all the others, to build rpms with Jefs' autofs-4.1.3-16 and autofs-4.1.3-55.1 source rpms so I hope it will apply OK to the rpm you are using. On Wed, 12 Jan 2005, David Meleedy wrote: > > Mike, > I just recompiled my kernel with your xprt-sharing.patch. > Although this did fix the port error problems, it did not fix > the automounter problem. So I think your patch should be incorporated > into Redhat Enterprise 3 (2.4 kernel) because it appears to work. > > I think the problem is that the automounter just cannot unmount > the /net/aflac directory, and ends up trying to remount it instead, > here are the log files after the port patch that Mike gave me: > (this is during the reboot after cd'ing to /net/aflac/vol/vol2) > > Jan 12 19:23:36 codered automount[5396]: can't shutdown: filesystem /net still > busy > Jan 12 19:23:38 codered autofs: automount -USR2 succeeded > Jan 12 19:23:41 codered automount[5396]: can't shutdown: filesystem /net still > busy > ... those lines keep repeating until .... > > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/cad_archive on /net/aflac/vol/vol3/cad_archive > Jan 12 19:24:08 codered automount[16092]: >> mount table full > Jan 12 19:24:08 codered automount[16092]: mount(nfs): nfs: mount failure > aflac:/vol/vol3/design on /net/aflac/vol/vol3/design > ... those lines repeart for each subdirectory of the volumes ... > > Jan 12 19:24:09 codered autofs: automount shutdown failed > > As you can see, it keeps trying to unmount /net, and eventually > fills up the mount table because it instead remounts it. Before, > when the port issue was a problem, it wouldn't get far enough to > fill the mount table, but now it can (thanks Mike!) > > -Dave > > ________________________________________________________________________ > David Meleedy Analog Devices, Inc. > David.Meleedy@analog.com Three Technology Way > Phone: 781 461 3494 Norwood, MA 02062-9106 USA > > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs > --1629620785-933557400-1105713308=:2519 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="autofs-4.1.3-multi-over.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="autofs-4.1.3-multi-over.patch" LS0tIGF1dG9mcy00LjEuMy9tb2R1bGVzL3BhcnNlX3N1bi5jLm11bHRpLW92 ZXIJMjAwNS0wMS0xNCAxOTo0NDozOS4wMDAwMDAwMDAgKzA4MDANCisrKyBh dXRvZnMtNC4xLjMvbW9kdWxlcy9wYXJzZV9zdW4uYwkyMDA1LTAxLTE0IDIw OjM2OjE3LjAwMDAwMDAwMCArMDgwMA0KQEAgLTU1LDYgKzU1LDEzIEBADQog CWludCBzbGFzaGlmeV9jb2xvbnM7CS8qIENoYW5nZSBjb2xvbnMgdG8gc2xh c2hlcz8gKi8NCiB9Ow0KIA0KK3N0cnVjdCBtdWx0aV9tbnQgew0KKwljaGFy ICpwYXRoOw0KKwljaGFyICpvcHRpb25zOw0KKwljaGFyICpsb2NhdGlvbjsN CisJc3RydWN0IG11bHRpX21udCAqbmV4dDsNCit9Ow0KKw0KIHN0cnVjdCB1 dHNuYW1lIHVuOw0KIGNoYXIgcHJvY2Vzc29yWzY1XTsJCS8qIE5vdCBkZWZp bmVkIG9uIExpbnV4LCBzbyB3ZSBtYWtlIG91ciBvd24gKi8NCiANCkBAIC02 MDksNiArNjE2LDY5IEBADQogfQ0KIA0KIC8qDQorICogQnVpbGQgbGlzdCBv ZiBtb3VudHMgaW4gc2hvcnRlc3QgLT4gbG9uZ2VzdCBvcmRlci4NCisgKiBQ YXNzIGluIGxpc3QgaGVhZCBhbmQgcmV0dXJuIGxpc3QgaGVhZC4NCisgKi8N CitzdHJ1Y3QgbXVsdGlfbW50ICptdWx0aV9hZGRfbGlzdChzdHJ1Y3QgbXVs dGlfbW50ICpsaXN0LA0KKwkJCQkgY2hhciAqcGF0aCwgY2hhciAqb3B0aW9u cywgY2hhciAqbG9jYXRpb24pDQorew0KKwlzdHJ1Y3QgbXVsdGlfbW50ICpt bXB0ciwgKm5ldywgKm9sZCA9IE5VTEw7DQorCWludCBwbGVuOw0KKw0KKwlp ZiAoIXBhdGggfHwgIW9wdGlvbnMgfHwgIWxvY2F0aW9uKQ0KKwkJcmV0dXJu IE5VTEw7DQorDQorCW5ldyA9IG1hbGxvYyhzaXplb2Yoc3RydWN0IG11bHRp X21udCkpOw0KKwlpZiAoIW5ldykNCisJCXJldHVybiBOVUxMOw0KKw0KKwlu ZXctPnBhdGggPSBwYXRoOw0KKwluZXctPm9wdGlvbnMgPSBvcHRpb25zOw0K KwluZXctPmxvY2F0aW9uID0gbG9jYXRpb247DQorDQorCXBsZW4gPSBzdHJs ZW4ocGF0aCk7DQorCW1tcHRyID0gbGlzdDsNCisJd2hpbGUgKG1tcHRyKSB7 DQorCQlpZiAocGxlbiA8PSBzdHJsZW4obW1wdHItPnBhdGgpKQ0KKwkJCWJy ZWFrOw0KKwkJb2xkID0gbW1wdHI7DQorCQltbXB0ciA9IG1tcHRyLT5uZXh0 Ow0KKwl9DQorDQorCWlmIChvbGQpDQorCQlvbGQtPm5leHQgPSBuZXc7DQor CW5ldy0+bmV4dCA9IG1tcHRyOw0KKw0KKwlyZXR1cm4gb2xkID8gbGlzdCA6 IG5ldzsNCit9DQorDQordm9pZCBtdWx0aV9mcmVlX2xpc3Qoc3RydWN0IG11 bHRpX21udCAqbGlzdCkNCit7DQorCXN0cnVjdCBtdWx0aV9tbnQgKm5leHQ7 DQorDQorCWlmICghbGlzdCkNCisJCXJldHVybjsNCisNCisJbmV4dCA9IGxp c3Q7DQorCXdoaWxlIChuZXh0KSB7DQorCQlzdHJ1Y3QgbXVsdGlfbW50ICp0 aGlzID0gbmV4dDsNCisNCisJCW5leHQgPSB0aGlzLT5uZXh0Ow0KKw0KKwkJ aWYgKHRoaXMtPnBhdGgpDQorCQkJZnJlZSh0aGlzLT5wYXRoKTsNCisNCisJ CWlmICh0aGlzLT5vcHRpb25zKQ0KKwkJCWZyZWUodGhpcy0+b3B0aW9ucyk7 DQorDQorCQlpZiAodGhpcy0+bG9jYXRpb24pDQorCQkJZnJlZSh0aGlzLT5s b2NhdGlvbik7DQorDQorCQlmcmVlKHRoaXMpOw0KKwl9DQorfQ0KKw0KKy8q DQogICogc3ludGF4IGlzOg0KICAqCVstb3B0aW9uc10gbG9jYXRpb24gW2xv Y2F0aW9uXSAuLi4NCiAgKglbLW9wdGlvbnNdIFttb3VudHBvaW50IFstb3B0 aW9uc10gbG9jYXRpb24gW2xvY2F0aW9uXSAuLi4gXS4uLg0KQEAgLTY2MSw2 ICs3MzEsNyBAQA0KIAlkZWJ1ZyhNT0RQUkVGSVggImdhdGhlcmVkIG9wdGlv bnM6ICVzIiwgb3B0aW9ucyk7DQogDQogCWlmICgqcCA9PSAnLycpIHsNCisJ CXN0cnVjdCBtdWx0aV9tbnQgKmxpc3QsICpoZWFkID0gTlVMTCwgKm5leHQ7 DQogCQlpbnQgbDsNCiAJCWNoYXIgKm11bHRpX3Jvb3Q7DQogDQpAQCAtNjg0 LDExICs3NTUsMTEgQEANCiAJCQlpZiAobXlvcHRpb25zID09IE5VTEwpIHsN CiAJCQkJZXJyb3IoTU9EUFJFRklYICJtdWx0aSBzdHJkdXA6ICVtIik7DQog CQkJCWZyZWUob3B0aW9ucyk7DQorCQkJCW11bHRpX2ZyZWVfbGlzdChoZWFk KTsNCiAJCQkJcmV0dXJuIDE7DQogCQkJfQ0KIA0KIAkJCXBhdGggPSBkZXF1 b3RlKHAsIGwgPSBjaHVua2xlbihwLCAwKSk7DQotCQkJcGF0aGxlbiA9IHN0 cmxlbihwYXRoKTsNCiANCiAJCQlwICs9IGw7DQogCQkJcCA9IHNraXBzcGFj ZShwKTsNCkBAIC03MDYsNiArNzc3LDcgQEANCiAJCQkJCQkgICAgIm11bHRp IGNvbmNhdF9vcHRpb25zOiAlbSIpOw0KIAkJCQkJCWZyZWUob3B0aW9ucyk7 DQogCQkJCQkJZnJlZShwYXRoKTsNCisJCQkJCQltdWx0aV9mcmVlX2xpc3Qo aGVhZCk7DQogCQkJCQkJcmV0dXJuIDE7DQogCQkJCQl9DQogCQkJCQlwID0g c2tpcHNwYWNlKHApOw0KQEAgLTcyMSwyOCArNzkzLDQyIEBADQogCQkJbCA9 IHEgLSBwOw0KIA0KIAkJCWxvYyA9IGRlcXVvdGUocCwgbCk7DQotCQkJbG9j bGVuID0gc3RybGVuKGxvYyk7DQotDQogCQkJaWYgKGxvYyA9PSBOVUxMIHx8 IHBhdGggPT0gTlVMTCkgew0KIAkJCQllcnJvcihNT0RQUkVGSVggIm91dCBv ZiBtZW1vcnkiKTsNCiAJCQkJZnJlZShsb2MpOw0KIAkJCQlmcmVlKHBhdGgp Ow0KIAkJCQlmcmVlKG9wdGlvbnMpOw0KKwkJCQlmcmVlKG15b3B0aW9ucyk7 DQorCQkJCW11bHRpX2ZyZWVfbGlzdChoZWFkKTsNCiAJCQkJcmV0dXJuIDE7 DQogCQkJfQ0KIA0KIAkJCXAgKz0gbDsNCiAJCQlwID0gc2tpcHNwYWNlKHAp Ow0KIA0KKwkJCWxpc3QgPSBoZWFkOw0KKwkJCWhlYWQgPSBtdWx0aV9hZGRf bGlzdChsaXN0LCBwYXRoLCBteW9wdGlvbnMsIGxvYyk7DQorCQkJaWYgKCFo ZWFkKSB7DQorCQkJCWZyZWUobG9jKTsNCisJCQkJZnJlZShwYXRoKTsNCisJ CQkJZnJlZShvcHRpb25zKTsNCisJCQkJZnJlZShteW9wdGlvbnMpOw0KKwkJ CQltdWx0aV9mcmVlX2xpc3QoaGVhZCk7DQorCQkJCXJldHVybiAxOw0KKwkJ CX0NCisJCX0gd2hpbGUgKCpwID09ICcvJyk7DQorDQorCQluZXh0ID0gaGVh ZDsNCisJCXdoaWxlIChuZXh0KSB7DQogCQkJZGVidWcoTU9EUFJFRklYDQog CQkJICAgICAgIm11bHRpbW91bnQ6ICUuKnMgb24gJS4qcyB3aXRoIG9wdGlv bnMgJXMiLA0KLQkJCSAgICAgIGxvY2xlbiwgbG9jLCBwYXRobGVuLCBwYXRo LCBteW9wdGlvbnMpOw0KKwkJCSAgICAgIHN0cmxlbihuZXh0LT5sb2NhdGlv biksIG5leHQtPmxvY2F0aW9uLA0KKwkJCSAgICAgIHN0cmxlbihuZXh0LT5w YXRoKSwgbmV4dC0+cGF0aCwgbmV4dC0+b3B0aW9ucyk7DQogDQotCQkJcnYg PSBzdW5fbW91bnQobXVsdGlfcm9vdCwgcGF0aCwgcGF0aGxlbiwgbG9jLCBs b2NsZW4sDQotCQkJCSAgICAgICBteW9wdGlvbnMpOw0KLQkJCWZyZWUocGF0 aCk7DQotCQkJZnJlZShsb2MpOw0KLQkJCWZyZWUobXlvcHRpb25zKTsNCisJ CQlydiA9IHN1bl9tb3VudChtdWx0aV9yb290LA0KKwkJCQkgICAgICAgbmV4 dC0+cGF0aCwgc3RybGVuKG5leHQtPnBhdGgpLA0KKwkJCQkgICAgICAgbmV4 dC0+bG9jYXRpb24sIHN0cmxlbihuZXh0LT5sb2NhdGlvbiksDQorCQkJCSAg ICAgICBuZXh0LT5vcHRpb25zKTsNCiANCiAJCQkvKiBDb252ZXJ0IG5vbi1z dHJpY3QgZmFpbHVyZSBpbnRvIHN1Y2Nlc3MgKi8NCiAJCQlpZiAocnYgPCAw KSB7DQpAQCAtNzUxLDcgKzgzNywxMCBAQA0KIAkJCX0gZWxzZSBpZiAocnYg PiAwKQ0KIAkJCQlicmVhazsNCiANCi0JCX0gd2hpbGUgKCpwID09ICcvJyk7 DQorCQkJbmV4dCA9IG5leHQtPm5leHQ7DQorCQl9DQorDQorCQltdWx0aV9m cmVlX2xpc3QoaGVhZCk7DQogDQogCQlmcmVlKG9wdGlvbnMpOw0KIAkJcmV0 dXJuIHJ2Ow0K --1629620785-933557400-1105713308=:2519 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --1629620785-933557400-1105713308=:2519-- From autofs-bounces@linux.kernel.org Mon Jan 17 07:04:49 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0HF4mBD003329 for ; Mon, 17 Jan 2005 07:04:49 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HEr9P5027399; Mon, 17 Jan 2005 06:53:12 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HEqxOe027270 for ; Mon, 17 Jan 2005 06:53:00 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0HEqqDl021034; Mon, 17 Jan 2005 09:52:52 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0HEqpO31437; Mon, 17 Jan 2005 09:52:51 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0HEqps1001298; Mon, 17 Jan 2005 09:52:51 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0HEqIT1016182; Mon, 17 Jan 2005 09:52:18 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0HEqIDY016179; Mon, 17 Jan 2005 09:52:18 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16875.53538.836665.652032@segfault.boston.redhat.com> Date: Mon, 17 Jan 2005 09:52:18 -0500 To: raven@themaw.net Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; raven@themaw.net adds: raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> Ian, I have installed the multi-over patch into our version of the >> automounter 4.1.3-67 (with updated large-program-map patch) and so far >> everything looks great! I am going to test our machines for a longer >> period of time and make sure everything looks stable, but so far, so >> good! raven> That sounds very encouraging. Great! Very encouraging indeed. Good catch, Ian! >> It seems to have eliminated the "BUG" message in the messages file, and >> it seems as though the automounter can unmount /net/aflac which it was >> not able to do in the past during a reboot. I suspect that this means >> it will use a lot less ports, and I might not even need the kernel patch >> (given the small amount of mounts we actually use) -- I am testing this >> as well. raven> The BUG messages were placed there to identify this happening as raven> this problem has come up in various forms several times. raven> In this case it appears to be caused by the order in which the raven> mounts are done (ie. received from auto.net). Given that current raven> autofs implementation of multi-mounts must handle them as a single raven> unit, nested filesystem mounts, made in the wrong order, cause raven> overmounting which caused the umount problem. raven> Perhaps. raven> Depends on whether the mount program has the patch which probes the raven> NFS server. The port usage problem still remains and I expect it raven> will continue to cause problems for us one way or another. Hopefully raven> it will be addressed in the near future. Hmm, I wonder what probing it actually does. I'll have a look and see if we can change the probe code to use non-reserved ports. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 17 08:27:06 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0HGR56S007034 for ; Mon, 17 Jan 2005 08:27:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HGK6a8014476; Mon, 17 Jan 2005 08:20:35 -0800 Received: from nwd2mail1.analog.com (nwd2mail1.analog.com [137.71.25.50]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0HGJwIq014329 for ; Mon, 17 Jan 2005 08:20:01 -0800 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j0HGJroU012975; Mon, 17 Jan 2005 11:19:53 -0500 Received: from jetcar.spd.analog.com ([10.64.82.61]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id LAA14357; Mon, 17 Jan 2005 11:19:51 -0500 (EST) Received: (from dmeleedy@localhost) by jetcar.spd.analog.com (8.12.9/8.12.9) id j0HGJpEC029321; Mon, 17 Jan 2005 11:19:51 -0500 (EST) Message-Id: <200501171619.j0HGJpEC029321@jetcar.spd.analog.com> X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.4 #57[UCI] To: raven@themaw.net Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: Your message of "Mon, 17 Jan 2005 22:01:31 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jan 2005 11:19:51 -0500 From: David Meleedy X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanned-By: MIMEDefang 2.48 on 137.71.25.50 Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > Hi David, > > I've found a small problem with the patch. > Please update your rpms with the extra patch below or get the version I > have uploaded to the autofs v4 directory on kernel.org. The small patch to the patch you sent did not work, however the updated patch in: ftp://ftp.kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.3-multi-over.patch worked just fine. I will get some testing done today and let you know how it worked out. Thanks again Ian, -Dave ________________________________________________________________________ David Meleedy Analog Devices, Inc. David.Meleedy@analog.com Three Technology Way Phone: 781 461 3494 Norwood, MA 02062-9106 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 17 17:39:55 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0I1dpu1010003 for ; Mon, 17 Jan 2005 17:39:55 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0I1UPQN016113; Mon, 17 Jan 2005 17:31:15 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0I1UKTf016104 for ; Mon, 17 Jan 2005 17:30:22 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0I1VKlm000314 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Jan 2005 09:31:21 +0800 Date: Tue, 18 Jan 2005 09:31:20 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Jeff Moyer Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <16875.53538.836665.652032@segfault.boston.redhat.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 17 Jan 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; raven@themaw.net adds: > > raven> On Fri, 14 Jan 2005, David Meleedy wrote: > >> Ian, I have installed the multi-over patch into our version of the > >> automounter 4.1.3-67 (with updated large-program-map patch) and so far > >> everything looks great! I am going to test our machines for a longer > >> period of time and make sure everything looks stable, but so far, so > >> good! > > raven> That sounds very encouraging. Great! > > Very encouraging indeed. Good catch, Ian! > > >> It seems to have eliminated the "BUG" message in the messages file, and > >> it seems as though the automounter can unmount /net/aflac which it was > >> not able to do in the past during a reboot. I suspect that this means > >> it will use a lot less ports, and I might not even need the kernel patch > >> (given the small amount of mounts we actually use) -- I am testing this > >> as well. > > raven> The BUG messages were placed there to identify this happening as > raven> this problem has come up in various forms several times. > > raven> In this case it appears to be caused by the order in which the > raven> mounts are done (ie. received from auto.net). Given that current > raven> autofs implementation of multi-mounts must handle them as a single > raven> unit, nested filesystem mounts, made in the wrong order, cause > raven> overmounting which caused the umount problem. > > raven> Perhaps. > > raven> Depends on whether the mount program has the patch which probes the > raven> NFS server. The port usage problem still remains and I expect it > raven> will continue to cause problems for us one way or another. Hopefully > raven> it will be addressed in the near future. > > Hmm, I wonder what probing it actually does. I'll have a look and see if > we can change the probe code to use non-reserved ports. I looked at the code in an FC2 mount and found that it did quite a bit of probing. In itself this is probably a good thing as it's more comprehensive than what I do for replicated server mount entries and it may be a precursor to providing that functionality in mount. This just means that we need to get a handle on the objections to RPC transport multiplexing and get it done. Using non-priveledged ports has other dependencies. For example, on Debian with 2.4.27 mountd rejects connections from non-priveledged ports. I didn't spend much time to find out if I could work around it but never the less it likely will generate a bit of noise. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 17 17:49:44 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0I1nhTk010165 for ; Mon, 17 Jan 2005 17:49:44 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0I1bYn2018503; Mon, 17 Jan 2005 17:37:37 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0I1WJdI016177 for ; Mon, 17 Jan 2005 17:32:19 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0I1XGlm000379 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Jan 2005 09:33:16 +0800 Date: Tue, 18 Jan 2005 09:33:16 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: David Meleedy Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <200501171619.j0HGJpEC029321@jetcar.spd.analog.com> Message-ID: References: <200501171619.j0HGJpEC029321@jetcar.spd.analog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 17 Jan 2005, David Meleedy wrote: > > > Hi David, > > > > I've found a small problem with the patch. > > Please update your rpms with the extra patch below or get the version I > > have uploaded to the autofs v4 directory on kernel.org. > > The small patch to the patch you sent did not work, however > the updated patch in: > > ftp://ftp.kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.3-multi-over.patch > > worked just fine. I will get some testing done today and let you > know how it worked out. Oops. Alls well that ends well! Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 06:26:31 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IEQU5l032164 for ; Tue, 18 Jan 2005 06:26:31 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IEN3JO005114; Tue, 18 Jan 2005 06:23:05 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IEKtZ1005019 for ; Tue, 18 Jan 2005 06:20:55 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0IEKonv004779; Tue, 18 Jan 2005 09:20:50 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0IEKoO27937; Tue, 18 Jan 2005 09:20:50 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0IEKop5022570; Tue, 18 Jan 2005 09:20:50 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0IEKIkn010825; Tue, 18 Jan 2005 09:20:18 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0IEKInx010822; Tue, 18 Jan 2005 09:20:18 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16877.6946.710259.562902@segfault.boston.redhat.com> Date: Tue, 18 Jan 2005 09:20:18 -0500 To: Ian Kent Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] >> = port usage problems; raven@themaw.net adds: >> raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> >> Ian, I have installed the multi-over patch into our version of the >> >> automounter 4.1.3-67 (with updated large-program-map patch) and so far >> >> everything looks great! I am going to test our machines for a longer >> >> period of time and make sure everything looks stable, but so far, so >> >> good! >> raven> That sounds very encouraging. Great! >> Very encouraging indeed. Good catch, Ian! >> >> >> It seems to have eliminated the "BUG" message in the messages file, >> and >> it seems as though the automounter can unmount /net/aflac which >> it was >> not able to do in the past during a reboot. I suspect that >> this means >> it will use a lot less ports, and I might not even need >> the kernel patch >> (given the small amount of mounts we actually use) >> -- I am testing this >> as well. >> raven> The BUG messages were placed there to identify this happening as raven> this problem has come up in various forms several times. >> raven> In this case it appears to be caused by the order in which the raven> mounts are done (ie. received from auto.net). Given that current raven> autofs implementation of multi-mounts must handle them as a single raven> unit, nested filesystem mounts, made in the wrong order, cause raven> overmounting which caused the umount problem. >> raven> Perhaps. >> raven> Depends on whether the mount program has the patch which probes the raven> NFS server. The port usage problem still remains and I expect it raven> will continue to cause problems for us one way or another. Hopefully raven> it will be addressed in the near future. >> Hmm, I wonder what probing it actually does. I'll have a look and see >> if we can change the probe code to use non-reserved ports. raven> I looked at the code in an FC2 mount and found that it did quite a raven> bit of probing. [snip] raven> This just means that we need to get a handle on the objections to raven> RPC transport multiplexing and get it done. I forwarded Mike's patch off to Steve Dickson. However, with the caveats he listed, I'm not optimistic. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 06:27:29 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IERTGa032174 for ; Tue, 18 Jan 2005 06:27:29 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IEJm8w004831; Tue, 18 Jan 2005 06:20:27 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IEJdI1004822 for ; Tue, 18 Jan 2005 06:19:40 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0IEJYUa004051; Tue, 18 Jan 2005 09:19:34 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0IEJWO27108; Tue, 18 Jan 2005 09:19:32 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0IEJWp5022406; Tue, 18 Jan 2005 09:19:32 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0IEJ0DW010793; Tue, 18 Jan 2005 09:19:00 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0IEIvK3010790; Tue, 18 Jan 2005 09:18:57 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16877.6865.609132.621298@segfault.boston.redhat.com> Date: Tue, 18 Jan 2005 09:18:57 -0500 To: Ian Kent Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] >> = port usage problems; raven@themaw.net adds: >> raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> >> Ian, I have installed the multi-over patch into our version of the >> >> automounter 4.1.3-67 (with updated large-program-map patch) and so far >> >> everything looks great! I am going to test our machines for a longer >> >> period of time and make sure everything looks stable, but so far, so >> >> good! >> raven> That sounds very encouraging. Great! >> Very encouraging indeed. Good catch, Ian! >> >> >> It seems to have eliminated the "BUG" message in the messages file, >> and >> it seems as though the automounter can unmount /net/aflac which >> it was >> not able to do in the past during a reboot. I suspect that >> this means >> it will use a lot less ports, and I might not even need >> the kernel patch >> (given the small amount of mounts we actually use) >> -- I am testing this >> as well. >> raven> The BUG messages were placed there to identify this happening as raven> this problem has come up in various forms several times. >> raven> In this case it appears to be caused by the order in which the raven> mounts are done (ie. received from auto.net). Given that current raven> autofs implementation of multi-mounts must handle them as a single raven> unit, nested filesystem mounts, made in the wrong order, cause raven> overmounting which caused the umount problem. >> raven> Perhaps. >> raven> Depends on whether the mount program has the patch which probes the raven> NFS server. The port usage problem still remains and I expect it raven> will continue to cause problems for us one way or another. Hopefully raven> it will be addressed in the near future. >> Hmm, I wonder what probing it actually does. I'll have a look and see >> if we can change the probe code to use non-reserved ports. raven> I looked at the code in an FC2 mount and found that it did quite a raven> bit of probing. raven> In itself this is probably a good thing as it's more comprehensive raven> than what I do for replicated server mount entries and it may be a raven> precursor to providing that functionality in mount. This just means raven> that we need to get a handle on the objections to RPC transport raven> multiplexing and get it done. Umm, you want mount to support replicated servers? Interesting idea, but I'm not sure I like it. raven> Using non-priveledged ports has other dependencies. For example, on raven> Debian with 2.4.27 mountd rejects connections from non-priveledged raven> ports. I didn't spend much time to find out if I could work around raven> it but never the less it likely will generate a bit of noise. Right. But you can still try to connect using non-priveledged ports, and fallback to the current code path if that fails. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 09:12:51 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IHCoCk032439 for ; Tue, 18 Jan 2005 09:12:51 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH0oNe011645; Tue, 18 Jan 2005 09:01:14 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH0EjE011549 for ; Tue, 18 Jan 2005 09:00:16 -0800 Received: from raven-wl.themaw.net (203-59-212-138.dyn.iinet.net.au [203.59.212.138]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0IH1Flm020260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Jan 2005 01:01:16 +0800 Date: Wed, 19 Jan 2005 01:00:28 +0800 (WST) From: Ian Kent To: Jeff Moyer Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <16877.6865.609132.621298@segfault.boston.redhat.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6865.609132.621298@segfault.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-101.4, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 18 Jan 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: > > raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: > >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] > >> = port usage problems; raven@themaw.net adds: > >> > raven> On Fri, 14 Jan 2005, David Meleedy wrote: > >> >> Ian, I have installed the multi-over patch into our version of the >> > >> automounter 4.1.3-67 (with updated large-program-map patch) and so far > >> >> everything looks great! I am going to test our machines for a longer > >> >> period of time and make sure everything looks stable, but so far, so > >> >> good! > >> > raven> That sounds very encouraging. Great! > >> Very encouraging indeed. Good catch, Ian! > >> > >> >> It seems to have eliminated the "BUG" message in the messages file, > >> and >> it seems as though the automounter can unmount /net/aflac which > >> it was >> not able to do in the past during a reboot. I suspect that > >> this means >> it will use a lot less ports, and I might not even need > >> the kernel patch >> (given the small amount of mounts we actually use) > >> -- I am testing this >> as well. > >> > raven> The BUG messages were placed there to identify this happening as > raven> this problem has come up in various forms several times. > >> > raven> In this case it appears to be caused by the order in which the > raven> mounts are done (ie. received from auto.net). Given that current > raven> autofs implementation of multi-mounts must handle them as a single > raven> unit, nested filesystem mounts, made in the wrong order, cause > raven> overmounting which caused the umount problem. > >> > raven> Perhaps. > >> > raven> Depends on whether the mount program has the patch which probes the > raven> NFS server. The port usage problem still remains and I expect it > raven> will continue to cause problems for us one way or another. Hopefully > raven> it will be addressed in the near future. > >> Hmm, I wonder what probing it actually does. I'll have a look and see > >> if we can change the probe code to use non-reserved ports. > > raven> I looked at the code in an FC2 mount and found that it did quite a > raven> bit of probing. > > raven> In itself this is probably a good thing as it's more comprehensive > raven> than what I do for replicated server mount entries and it may be a > raven> precursor to providing that functionality in mount. This just means > raven> that we need to get a handle on the objections to RPC transport > raven> multiplexing and get it done. > > Umm, you want mount to support replicated servers? Interesting idea, but > I'm not sure I like it. > > raven> Using non-priveledged ports has other dependencies. For example, on > raven> Debian with 2.4.27 mountd rejects connections from non-priveledged > raven> ports. I didn't spend much time to find out if I could work around > raven> it but never the less it likely will generate a bit of noise. > > Right. But you can still try to connect using non-priveledged ports, and > fallback to the current code path if that fails. But mount doesn't work (in this case) when the kernel on the server end doesn't support non-priveledged ports but the client does. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 09:13:56 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IHDtdO032453 for ; Tue, 18 Jan 2005 09:13:56 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH5pMu012671; Tue, 18 Jan 2005 09:05:54 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH5eQN012568 for ; Tue, 18 Jan 2005 09:05:40 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0IH5X53027830; Tue, 18 Jan 2005 12:05:33 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0IH5XO24645; Tue, 18 Jan 2005 12:05:33 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0IH5Xp5004374; Tue, 18 Jan 2005 12:05:33 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0IH51wW015389; Tue, 18 Jan 2005 12:05:01 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0IH51ZB015386; Tue, 18 Jan 2005 12:05:01 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16877.16829.641377.849073@segfault.boston.redhat.com> Date: Tue, 18 Jan 2005 12:05:01 -0500 To: Ian Kent Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6865.609132.621298@segfault.boston.redhat.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: raven> On Tue, 18 Jan 2005, Jeff Moyer wrote: >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] >> = port usage problems; Ian Kent adds: >> raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: >> >> ==> Regarding Re: [autofs] BUG: autofs4 + cd >> /net//vol/vol[0-3] >> = port usage problems; raven@themaw.net >> adds: >> >> raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> >> >> Ian, I have installed the multi-over patch into our version of the >> >> >> automounter 4.1.3-67 (with updated large-program-map patch) and so >> far >> >> everything looks great! I am going to test our machines for a >> longer >> >> period of time and make sure everything looks stable, but >> so far, so >> >> good! >> >> raven> That sounds very encouraging. Great! >> >> Very encouraging indeed. Good catch, Ian! >> >> >> >> >> It seems to have eliminated the "BUG" message in the messages >> file, >> and >> it seems as though the automounter can unmount >> /net/aflac which >> it was >> not able to do in the past during a >> reboot. I suspect that >> this means >> it will use a lot less ports, >> and I might not even need >> the kernel patch >> (given the small amount >> of mounts we actually use) >> -- I am testing this >> as well. >> >> raven> The BUG messages were placed there to identify this happening as raven> this problem has come up in various forms several times. >> >> raven> In this case it appears to be caused by the order in which the raven> mounts are done (ie. received from auto.net). Given that current raven> autofs implementation of multi-mounts must handle them as a single raven> unit, nested filesystem mounts, made in the wrong order, cause raven> overmounting which caused the umount problem. >> >> raven> Perhaps. >> >> raven> Depends on whether the mount program has the patch which probes the raven> NFS server. The port usage problem still remains and I expect it raven> will continue to cause problems for us one way or another. Hopefully raven> it will be addressed in the near future. >> >> Hmm, I wonder what probing it actually does. I'll have a look and >> see >> if we can change the probe code to use non-reserved ports. >> raven> I looked at the code in an FC2 mount and found that it did quite a raven> bit of probing. >> raven> In itself this is probably a good thing as it's more comprehensive raven> than what I do for replicated server mount entries and it may be a raven> precursor to providing that functionality in mount. This just means raven> that we need to get a handle on the objections to RPC transport raven> multiplexing and get it done. >> Umm, you want mount to support replicated servers? Interesting idea, >> but I'm not sure I like it. >> raven> Using non-priveledged ports has other dependencies. For example, on raven> Debian with 2.4.27 mountd rejects connections from non-priveledged raven> ports. I didn't spend much time to find out if I could work around raven> it but never the less it likely will generate a bit of noise. >> Right. But you can still try to connect using non-priveledged ports, >> and fallback to the current code path if that fails. raven> But mount doesn't work (in this case) when the kernel on the server raven> end doesn't support non-priveledged ports but the client does. Seems we have a disconnect. I thought you were only talking about the probe code. I don't know how to work around this, either, but I think mount is supposed to try reserved ports first? -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 09:20:17 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IHKG8F032471 for ; Tue, 18 Jan 2005 09:20:17 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH4NXJ011987; Tue, 18 Jan 2005 09:04:26 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH4H5a011950 for ; Tue, 18 Jan 2005 09:04:18 -0800 Received: from raven-wl.themaw.net (203-59-212-138.dyn.iinet.net.au [203.59.212.138]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0IH5Olm020353 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Jan 2005 01:05:25 +0800 Date: Wed, 19 Jan 2005 01:04:37 +0800 (WST) From: Ian Kent To: Jeff Moyer Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <16877.6946.710259.562902@segfault.boston.redhat.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6946.710259.562902@segfault.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-101.4, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 18 Jan 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: > > raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: > >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] > >> = port usage problems; raven@themaw.net adds: > >> > raven> On Fri, 14 Jan 2005, David Meleedy wrote: > >> >> Ian, I have installed the multi-over patch into our version of the >> > >> automounter 4.1.3-67 (with updated large-program-map patch) and so far > >> >> everything looks great! I am going to test our machines for a longer > >> >> period of time and make sure everything looks stable, but so far, so > >> >> good! > >> > raven> That sounds very encouraging. Great! > >> Very encouraging indeed. Good catch, Ian! > >> > >> >> It seems to have eliminated the "BUG" message in the messages file, > >> and >> it seems as though the automounter can unmount /net/aflac which > >> it was >> not able to do in the past during a reboot. I suspect that > >> this means >> it will use a lot less ports, and I might not even need > >> the kernel patch >> (given the small amount of mounts we actually use) > >> -- I am testing this >> as well. > >> > raven> The BUG messages were placed there to identify this happening as > raven> this problem has come up in various forms several times. > >> > raven> In this case it appears to be caused by the order in which the > raven> mounts are done (ie. received from auto.net). Given that current > raven> autofs implementation of multi-mounts must handle them as a single > raven> unit, nested filesystem mounts, made in the wrong order, cause > raven> overmounting which caused the umount problem. > >> > raven> Perhaps. > >> > raven> Depends on whether the mount program has the patch which probes the > raven> NFS server. The port usage problem still remains and I expect it > raven> will continue to cause problems for us one way or another. Hopefully > raven> it will be addressed in the near future. > >> Hmm, I wonder what probing it actually does. I'll have a look and see > >> if we can change the probe code to use non-reserved ports. > > raven> I looked at the code in an FC2 mount and found that it did quite a > raven> bit of probing. > > [snip] > > raven> This just means that we need to get a handle on the objections to > raven> RPC transport multiplexing and get it done. > > I forwarded Mike's patch off to Steve Dickson. However, with the caveats > he listed, I'm not optimistic. Neither am I. The patch that Trond originally did is probably a better starting point. There's quite a bit to do meantime such as, general testing, scalability testing, dynamically allocating a new transport if a request slot can't be allocated and so on. There will be quite a bit more discussion on this I expect. What is Steves responsibility here? Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 09:20:19 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IHKIme032474 for ; Tue, 18 Jan 2005 09:20:19 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH8YPe013166; Tue, 18 Jan 2005 09:08:35 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IH8RrG013140 for ; Tue, 18 Jan 2005 09:08:28 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0IH8OTR028648; Tue, 18 Jan 2005 12:08:24 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0IH8NO25395; Tue, 18 Jan 2005 12:08:23 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0IH8Np5004536; Tue, 18 Jan 2005 12:08:23 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0IH7qZD015447; Tue, 18 Jan 2005 12:07:52 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0IH7qBc015444; Tue, 18 Jan 2005 12:07:52 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16877.17000.262046.386856@segfault.boston.redhat.com> Date: Tue, 18 Jan 2005 12:07:52 -0500 To: Ian Kent Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6946.710259.562902@segfault.boston.redhat.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: raven> On Tue, 18 Jan 2005, Jeff Moyer wrote: >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] >> = port usage problems; Ian Kent adds: >> raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: >> >> ==> Regarding Re: [autofs] BUG: autofs4 + cd >> /net//vol/vol[0-3] >> = port usage problems; raven@themaw.net >> adds: >> >> raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> >> >> Ian, I have installed the multi-over patch into our version of the >> >> >> automounter 4.1.3-67 (with updated large-program-map patch) and so >> far >> >> everything looks great! I am going to test our machines for a >> longer >> >> period of time and make sure everything looks stable, but >> so far, so >> >> good! >> >> raven> That sounds very encouraging. Great! >> >> Very encouraging indeed. Good catch, Ian! >> >> >> >> >> It seems to have eliminated the "BUG" message in the messages >> file, >> and >> it seems as though the automounter can unmount >> /net/aflac which >> it was >> not able to do in the past during a >> reboot. I suspect that >> this means >> it will use a lot less ports, >> and I might not even need >> the kernel patch >> (given the small amount >> of mounts we actually use) >> -- I am testing this >> as well. >> >> raven> The BUG messages were placed there to identify this happening as raven> this problem has come up in various forms several times. >> >> raven> In this case it appears to be caused by the order in which the raven> mounts are done (ie. received from auto.net). Given that current raven> autofs implementation of multi-mounts must handle them as a single raven> unit, nested filesystem mounts, made in the wrong order, cause raven> overmounting which caused the umount problem. >> >> raven> Perhaps. >> >> raven> Depends on whether the mount program has the patch which probes the raven> NFS server. The port usage problem still remains and I expect it raven> will continue to cause problems for us one way or another. Hopefully raven> it will be addressed in the near future. >> >> Hmm, I wonder what probing it actually does. I'll have a look and >> see >> if we can change the probe code to use non-reserved ports. >> raven> I looked at the code in an FC2 mount and found that it did quite a raven> bit of probing. >> [snip] >> raven> This just means that we need to get a handle on the objections to raven> RPC transport multiplexing and get it done. >> I forwarded Mike's patch off to Steve Dickson. However, with the >> caveats he listed, I'm not optimistic. raven> Neither am I. The patch that Trond originally did is probably a raven> better starting point. raven> There's quite a bit to do meantime such as, general testing, raven> scalability testing, dynamically allocating a new transport if a raven> request slot can't be allocated and so on. raven> There will be quite a bit more discussion on this I expect. raven> What is Steves responsibility here? Steve is our NFS maintainer. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 09:45:37 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0IHja8P032554 for ; Tue, 18 Jan 2005 09:45:37 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IHWxiv017486; Tue, 18 Jan 2005 09:33:13 -0800 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0IHWt16017479 for ; Tue, 18 Jan 2005 09:32:55 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0IHWsdv004815 for ; Tue, 18 Jan 2005 10:32:54 -0700 (MST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IAI00C01WPFCS@mpk-mail1.sfbay.sun.com> (original mail from Michael.Waychison@Sun.COM) for autofs@linux.kernel.org; Tue, 18 Jan 2005 09:32:54 -0800 (PST) Received: from [129.150.29.146] (vpn-129-150-29-146.SFBay.Sun.COM [129.150.29.146]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IAI003LLWQJ9O@mpk-mail1.sfbay.sun.com>; Tue, 18 Jan 2005 09:32:44 -0800 (PST) Date: Tue, 18 Jan 2005 12:32:29 -0500 From: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-reply-to: To: Ian Kent Message-id: <41ED482D.8090203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6946.710259.562902@segfault.boston.redhat.com> X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Kent wrote: > On Tue, 18 Jan 2005, Jeff Moyer wrote: > > >>==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: >> >>raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: >> >>>>==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] >>>>= port usage problems; raven@themaw.net adds: >>>> >> >>raven> On Fri, 14 Jan 2005, David Meleedy wrote: >> >>>>>>Ian, I have installed the multi-over patch into our version of the >> >>>> >>>>automounter 4.1.3-67 (with updated large-program-map patch) and so far >>>> >>>>>>everything looks great! I am going to test our machines for a longer >>>>>>period of time and make sure everything looks stable, but so far, so >>>>>>good! >>>> >>raven> That sounds very encouraging. Great! >> >>>>Very encouraging indeed. Good catch, Ian! >>>> >>>> >>>>>>It seems to have eliminated the "BUG" message in the messages file, >>>> >>>>and >> it seems as though the automounter can unmount /net/aflac which >>>>it was >> not able to do in the past during a reboot. I suspect that >>>>this means >> it will use a lot less ports, and I might not even need >>>>the kernel patch >> (given the small amount of mounts we actually use) >>>>-- I am testing this >> as well. >>>> >> >>raven> The BUG messages were placed there to identify this happening as >>raven> this problem has come up in various forms several times. >> >>raven> In this case it appears to be caused by the order in which the >>raven> mounts are done (ie. received from auto.net). Given that current >>raven> autofs implementation of multi-mounts must handle them as a single >>raven> unit, nested filesystem mounts, made in the wrong order, cause >>raven> overmounting which caused the umount problem. >> >>raven> Perhaps. >> >>raven> Depends on whether the mount program has the patch which probes the >>raven> NFS server. The port usage problem still remains and I expect it >>raven> will continue to cause problems for us one way or another. Hopefully >>raven> it will be addressed in the near future. >> >>>>Hmm, I wonder what probing it actually does. I'll have a look and see >>>>if we can change the probe code to use non-reserved ports. >> >>raven> I looked at the code in an FC2 mount and found that it did quite a >>raven> bit of probing. >> >>[snip] >> >>raven> This just means that we need to get a handle on the objections to >>raven> RPC transport multiplexing and get it done. >> >>I forwarded Mike's patch off to Steve Dickson. However, with the caveats >>he listed, I'm not optimistic. > > > Neither am I. The patch that Trond originally did is probably a better > starting point. Which patches are we referring to by chance? I'm guessing the xprt stuff? I don't know of Trond's patches that do the same. > > There's quite a bit to do meantime such as, general testing, scalability > testing, dynamically allocating a new transport if a request slot can't be > allocated and so on. > > There will be quite a bit more discussion on this I expect. > > What is Steves responsibility here? > > Ian > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7UgtdQs4kOxk3/MRAjaqAJwIYgp0GjlAH2X9Jl/wCs885AIRVgCfYBqI 0nJ1cZt77/sebi1MjVlV7pk= =n93V -----END PGP SIGNATURE----- _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 17:45:49 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0J1jlJa001018 for ; Tue, 18 Jan 2005 17:45:49 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0J1Ouw4025806; Tue, 18 Jan 2005 17:25:47 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0J1OnfP025799 for ; Tue, 18 Jan 2005 17:24:50 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0J1PXlm030738 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Jan 2005 09:25:35 +0800 Date: Wed, 19 Jan 2005 09:25:33 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Jeff Moyer Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <16877.16829.641377.849073@segfault.boston.redhat.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6865.609132.621298@segfault.boston.redhat.com> <16877.16829.641377.849073@segfault.boston.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 18 Jan 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: > > raven> On Tue, 18 Jan 2005, Jeff Moyer wrote: > >> ==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] > >> = port usage problems; Ian Kent adds: > >> > raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: > >> >> ==> Regarding Re: [autofs] BUG: autofs4 + cd > >> /net//vol/vol[0-3] >> = port usage problems; raven@themaw.net > >> adds: > >> >> > raven> On Fri, 14 Jan 2005, David Meleedy wrote: > >> >> >> Ian, I have installed the multi-over patch into our version of the > >> >> >> automounter 4.1.3-67 (with updated large-program-map patch) and so > >> far >> >> everything looks great! I am going to test our machines for a > >> longer >> >> period of time and make sure everything looks stable, but > >> so far, so >> >> good! > >> >> > raven> That sounds very encouraging. Great! > >> >> Very encouraging indeed. Good catch, Ian! > >> >> > >> >> >> It seems to have eliminated the "BUG" message in the messages > >> file, >> and >> it seems as though the automounter can unmount > >> /net/aflac which >> it was >> not able to do in the past during a > >> reboot. I suspect that >> this means >> it will use a lot less ports, > >> and I might not even need >> the kernel patch >> (given the small amount > >> of mounts we actually use) >> -- I am testing this >> as well. > >> >> > raven> The BUG messages were placed there to identify this happening as > raven> this problem has come up in various forms several times. > >> >> > raven> In this case it appears to be caused by the order in which the > raven> mounts are done (ie. received from auto.net). Given that current > raven> autofs implementation of multi-mounts must handle them as a single > raven> unit, nested filesystem mounts, made in the wrong order, cause > raven> overmounting which caused the umount problem. > >> >> > raven> Perhaps. > >> >> > raven> Depends on whether the mount program has the patch which probes the > raven> NFS server. The port usage problem still remains and I expect it > raven> will continue to cause problems for us one way or another. Hopefully > raven> it will be addressed in the near future. > >> >> Hmm, I wonder what probing it actually does. I'll have a look and > >> see >> if we can change the probe code to use non-reserved ports. > >> > raven> I looked at the code in an FC2 mount and found that it did quite a > raven> bit of probing. > >> > raven> In itself this is probably a good thing as it's more comprehensive > raven> than what I do for replicated server mount entries and it may be a > raven> precursor to providing that functionality in mount. This just means > raven> that we need to get a handle on the objections to RPC transport > raven> multiplexing and get it done. > >> Umm, you want mount to support replicated servers? Interesting idea, > >> but I'm not sure I like it. > >> > raven> Using non-priveledged ports has other dependencies. For example, on > raven> Debian with 2.4.27 mountd rejects connections from non-priveledged > raven> ports. I didn't spend much time to find out if I could work around > raven> it but never the less it likely will generate a bit of noise. > >> Right. But you can still try to connect using non-priveledged ports, > >> and fallback to the current code path if that fails. > > raven> But mount doesn't work (in this case) when the kernel on the server > raven> end doesn't support non-priveledged ports but the client does. > > Seems we have a disconnect. I thought you were only talking about the > probe code. I don't know how to work around this, either, but I think > mount is supposed to try reserved ports first? Yea, but I'm talking about when there are lots of mounts. It may be purely a mount issue I haven't dug deep enough. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 18 20:26:25 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0J4QOA4001343 for ; Tue, 18 Jan 2005 20:26:25 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0J4KSDU013784; Tue, 18 Jan 2005 20:20:41 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0J4KL9B013513 for ; Tue, 18 Jan 2005 20:20:22 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0J4LBlm001341 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Jan 2005 12:21:11 +0800 Date: Wed, 19 Jan 2005 12:21:11 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Mike Waychison Subject: Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems In-Reply-To: <41ED482D.8090203@sun.com> Message-ID: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6946.710259.562902@segfault.boston.redhat.com> <41ED482D.8090203@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs mailing list , nfs@lists.sourceforge.net, David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 18 Jan 2005, Mike Waychison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ian Kent wrote: > > On Tue, 18 Jan 2005, Jeff Moyer wrote: > > > > > >>==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems; Ian Kent adds: > >> > >>raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: > >> > >>>>==> Regarding Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] > >>>>= port usage problems; raven@themaw.net adds: > >>>> > >> > >>raven> On Fri, 14 Jan 2005, David Meleedy wrote: > >> > >>>>>>Ian, I have installed the multi-over patch into our version of the >> > >>>> > >>>>automounter 4.1.3-67 (with updated large-program-map patch) and so far > >>>> > >>>>>>everything looks great! I am going to test our machines for a longer > >>>>>>period of time and make sure everything looks stable, but so far, so > >>>>>>good! > >>>> > >>raven> That sounds very encouraging. Great! > >> > >>>>Very encouraging indeed. Good catch, Ian! > >>>> > >>>> > >>>>>>It seems to have eliminated the "BUG" message in the messages file, > >>>> > >>>>and >> it seems as though the automounter can unmount /net/aflac which > >>>>it was >> not able to do in the past during a reboot. I suspect that > >>>>this means >> it will use a lot less ports, and I might not even need > >>>>the kernel patch >> (given the small amount of mounts we actually use) > >>>>-- I am testing this >> as well. > >>>> > >> > >>raven> The BUG messages were placed there to identify this happening as > >>raven> this problem has come up in various forms several times. > >> > >>raven> In this case it appears to be caused by the order in which the > >>raven> mounts are done (ie. received from auto.net). Given that current > >>raven> autofs implementation of multi-mounts must handle them as a single > >>raven> unit, nested filesystem mounts, made in the wrong order, cause > >>raven> overmounting which caused the umount problem. > >> > >>raven> Perhaps. > >> > >>raven> Depends on whether the mount program has the patch which probes the > >>raven> NFS server. The port usage problem still remains and I expect it > >>raven> will continue to cause problems for us one way or another. Hopefully > >>raven> it will be addressed in the near future. > >> > >>>>Hmm, I wonder what probing it actually does. I'll have a look and see > >>>>if we can change the probe code to use non-reserved ports. > >> > >>raven> I looked at the code in an FC2 mount and found that it did quite a > >>raven> bit of probing. > >> > >>[snip] > >> > >>raven> This just means that we need to get a handle on the objections to > >>raven> RPC transport multiplexing and get it done. > >> > >>I forwarded Mike's patch off to Steve Dickson. However, with the caveats > >>he listed, I'm not optimistic. > > > > > > Neither am I. The patch that Trond originally did is probably a better > > starting point. > > Which patches are we referring to by chance? I'm guessing the xprt > stuff? I don't know of Trond's patches that do the same. Trond never finished them. He probably got too much flack about scalability and request slot exhastion and gave up on it. He reffered to them in a previous discussion on the same topic and said that if anyone wanted to port them to a current kernel and finish them they were welcome. So I did that at the time for vanila kernels (2.4.22 amd 2.6.0) but had no confidence in my work as my understanding of the RPC subsystem is fairly poor and was worse at the time. I asked Trond to check them but he clearly didn't have time. If you wish to look for youself they can be found at http://www.kernel.org/pub/kernel/people/raven/nfs The patch takes account of other kernel RPC users, lockd and portmap. Basically it moves the transport allocation into the transmit/receive FSM using a get/put mechanism, requiring only that kernel RPC users allocate the client struct. It looks to me like this approach would lend itself to dynamic allocation of additional transports upon request slot exhaustion. I spent some time checking this last weekend and it looks like porting them to current kernels is not too hard but will be tedious. Mind you I've transcribed these from Tronds' original patch and there could be errors in that work so they will need to be sanity checked anyway. I'm keen to spend some more time on this, so perhaps between this and what you have already done we can get something that will make it into the RPC subsystem. Stranger things have happened. > > > > > There's quite a bit to do meantime such as, general testing, scalability > > testing, dynamically allocating a new transport if a request slot can't be > > allocated and so on. > > > > There will be quite a bit more discussion on this I expect. > > > > What is Steves responsibility here? > > > > Ian > > > > _______________________________________________ > > autofs mailing list > > autofs@linux.kernel.org > > http://linux.kernel.org/mailman/listinfo/autofs > > > - -- > Mike Waychison > Sun Microsystems, Inc. > 1 (650) 352-5299 voice > 1 (416) 202-8336 voice > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: The opinions expressed in this email are held by me, > and may not represent the views of Sun Microsystems, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB7UgtdQs4kOxk3/MRAjaqAJwIYgp0GjlAH2X9Jl/wCs885AIRVgCfYBqI > 0nJ1cZt77/sebi1MjVlV7pk= > =n93V > -----END PGP SIGNATURE----- > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 19 09:07:10 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0JH748b002998 for ; Wed, 19 Jan 2005 09:07:10 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0JGhulF019122; Wed, 19 Jan 2005 08:44:23 -0800 Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0JGhWG8019051 for ; Wed, 19 Jan 2005 08:43:32 -0800 Received: from smtp1.corp.netapp.com (10.57.156.124) by mx1.netapp.com with ESMTP; 19 Jan 2005 08:43:27 -0800 X-IronPort-AV: i="3.88,138,1102320000"; d="scan'208"; a="85923602:sNHT20068096" Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j0JGhPvg001909; Wed, 19 Jan 2005 08:43:26 -0800 (PST) Received: from burgundy.hq.netapp.com ([10.56.10.66]) by svlexc01.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jan 2005 08:43:25 -0800 Received: from lavender.hq.netapp.com ([10.56.11.75]) by burgundy.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jan 2005 08:43:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = portusage problems Date: Wed, 19 Jan 2005 08:43:25 -0800 Message-ID: <482A3FA0050D21419C269D13989C61130853963C@lavender-fe.eng.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = portusage problems Thread-Index: AcT93zivXiuRCV+6RwGEEq0oprPj6gAZptCg From: "Lever, Charles" To: "Ian Kent" , "Mike Waychison" X-OriginalArrivalTime: 19 Jan 2005 16:43:25.0798 (UTC) FILETIME=[FF05B860:01C4FE45] X-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id j0JGhWG8019051 Cc: autofs mailing list , nfs@lists.sourceforge.net, David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ian, you, mike and i should should discuss transport multiplexing offline. my transport switch patches are here, if you want to review them: http://troy.citi.umich.edu/~cel/linux-2.6/2.6.9-a/release-notes.html > -----Original Message----- > From: Ian Kent [mailto:raven@themaw.net] > Sent: Tuesday, January 18, 2005 11:21 PM > To: Mike Waychison > Cc: autofs mailing list; nfs@lists.sourceforge.net; David Meleedy > Subject: Re: [autofs] BUG: autofs4 + cd > /net//vol/vol[0-3] = portusage problems > > > On Tue, 18 Jan 2005, Mike Waychison wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Ian Kent wrote: > > > On Tue, 18 Jan 2005, Jeff Moyer wrote: > > > > > > > > >>==> Regarding Re: [autofs] BUG: autofs4 + cd > > >>/net//vol/vol[0-3] = port usage problems; Ian Kent > > >> adds: > > >> > > >>raven> On Mon, 17 Jan 2005, Jeff Moyer wrote: > > >> > > >>>>==> Regarding Re: [autofs] BUG: autofs4 + cd > > >>>>/net//vol/vol[0-3] = port usage problems; > raven@themaw.net > > >>>>adds: > > >>>> > > >> > > >>raven> On Fri, 14 Jan 2005, David Meleedy wrote: > > >> > > >>>>>>Ian, I have installed the multi-over patch into our > version of > > >>>>>>the >> > > >>>> > > >>>>automounter 4.1.3-67 (with updated large-program-map > patch) and so > > >>>>far > > >>>> > > >>>>>>everything looks great! I am going to test our > machines for a > > >>>>>>longer period of time and make sure everything looks > stable, but > > >>>>>>so far, so good! > > >>>> > > >>raven> That sounds very encouraging. Great! > > >> > > >>>>Very encouraging indeed. Good catch, Ian! > > >>>> > > >>>> > > >>>>>>It seems to have eliminated the "BUG" message in the messages > > >>>>>>file, > > >>>> > > >>>>and >> it seems as though the automounter can unmount > /net/aflac > > >>>>which it was >> not able to do in the past during a reboot. I > > >>>>suspect that this means >> it will use a lot less ports, and I > > >>>>might not even need the kernel patch >> (given the > small amount of > > >>>>mounts we actually use) > > >>>>-- I am testing this >> as well. > > >>>> > > >> > > >>raven> The BUG messages were placed there to identify > this happening > > >>raven> as this problem has come up in various forms several times. > > >> > > >>raven> In this case it appears to be caused by the order in which > > >>raven> the mounts are done (ie. received from auto.net). > Given that > > >>raven> current autofs implementation of multi-mounts must handle > > >>raven> them as a single unit, nested filesystem mounts, > made in the > > >>raven> wrong order, cause overmounting which caused the umount > > >>raven> problem. > > >> > > >>raven> Perhaps. > > >> > > >>raven> Depends on whether the mount program has the patch which > > >>raven> probes the NFS server. The port usage problem > still remains > > >>raven> and I expect it will continue to cause problems for us one > > >>raven> way or another. Hopefully it will be addressed in the near > > >>raven> future. > > >> > > >>>>Hmm, I wonder what probing it actually does. I'll have > a look and > > >>>>see if we can change the probe code to use non-reserved ports. > > >> > > >>raven> I looked at the code in an FC2 mount and found that it did > > >>raven> quite a bit of probing. > > >> > > >>[snip] > > >> > > >>raven> This just means that we need to get a handle on the > > >>raven> objections to RPC transport multiplexing and get it done. > > >> > > >>I forwarded Mike's patch off to Steve Dickson. However, with the > > >>caveats he listed, I'm not optimistic. > > > > > > > > > Neither am I. The patch that Trond originally did is probably a > > > better > > > starting point. > > > > Which patches are we referring to by chance? I'm guessing the xprt > > stuff? I don't know of Trond's patches that do the same. > > Trond never finished them. He probably got too much flack about > scalability and request slot exhastion and gave up on it. > > He reffered to them in a previous discussion on the same > topic and said > that if anyone wanted to port them to a current kernel and > finish them > they were welcome. > > So I did that at the time for vanila kernels (2.4.22 amd > 2.6.0) but had no > confidence in my work as my understanding of the RPC > subsystem is fairly > poor and was worse at the time. I asked Trond to check them > but he clearly > didn't have time. > > If you wish to look for youself they can be found at > http://www.kernel.org/pub/kernel/people/raven/nfs > > The patch takes account of other kernel RPC users, lockd and portmap. > > Basically it moves the transport allocation into the > transmit/receive FSM > using a get/put mechanism, requiring only that kernel RPC > users allocate > the client struct. It looks to me like this approach would > lend itself to > dynamic allocation of additional transports upon request slot > exhaustion. > > I spent some time checking this last weekend and it looks > like porting > them to current kernels is not too hard but will be tedious. > > Mind you I've transcribed these from Tronds' original patch and there > could be errors in that work so they will need to be sanity checked > anyway. > > I'm keen to spend some more time on this, so perhaps between > this and what > you have already done we can get something that will make it > into the RPC > subsystem. Stranger things have happened. > > > > > > > > > There's quite a bit to do meantime such as, general testing, > > > scalability > > > testing, dynamically allocating a new transport if a > request slot can't be > > > allocated and so on. > > > > > > There will be quite a bit more discussion on this I expect. > > > > > > What is Steves responsibility here? > > > > > > Ian > > > > > > _______________________________________________ > > > autofs mailing list > > > autofs@linux.kernel.org > > > http://linux.kernel.org/mailman/listinfo/autofs > > > > > > - -- > > Mike Waychison > > Sun Microsystems, Inc. > > 1 (650) 352-5299 voice > > 1 (416) 202-8336 voice > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > NOTICE: The opinions expressed in this email are held by > me, and may > > not represent the views of Sun Microsystems, Inc. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.5 (GNU/Linux) > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > > iD8DBQFB7UgtdQs4kOxk3/MRAjaqAJwIYgp0GjlAH2X9Jl/wCs885AIRVgCfYBqI > > 0nJ1cZt77/sebi1MjVlV7pk= > > =n93V > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autof> s > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 20 14:22:51 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0KMMoLf031772 for ; Thu, 20 Jan 2005 14:22:51 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0KMGJpw024662; Thu, 20 Jan 2005 14:16:59 -0800 Received: from XCGMD810.ngxcgmdr1.northgrum.com (xcgmd810.northgrum.com [155.104.240.104]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0KMGEQs024653 for ; Thu, 20 Jan 2005 14:16:15 -0800 Received: from xcgmd800.northgrum.com ([155.104.118.187]) by XCGMD810.ngxcgmdr1.northgrum.com with InterScan Messaging Security Suite; Thu, 20 Jan 2005 14:15:08 -0800 Received: from xcgil100.northgrum.com ([153.113.53.36]) by xcgmd800.northgrum.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 14:16:04 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 20 Jan 2005 16:15:31 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: softlink creation on startup Thread-Index: AcT/PY6cw9U+91r5T8O+cyQ+qS1nvg== From: "Dege, Robert C." To: X-OriginalArrivalTime: 20 Jan 2005 22:16:04.0831 (UTC) FILETIME=[A1F236F0:01C4FF3D] X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id j0KMGEQs024653 Subject: [autofs] softlink creation on startup X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi, I'm trying to integrate a linux box into a TRU64 UNIX network, and am seeking some insight with automounting. Our TRU64 network uses NIS to propagate data among our client systems. The systems have been configured to use the NIS auto.master map to establish automount links. Here's a snippet of the file: # Razor Links /newrazor -rw,intr newrazor:/razor /arazor -rw,intr cerberus:/razor # Misc. Alpha Links /home -rw,intr mercury:/home /vxdisk -rw,intr as2508:/vxdisk I am already aware that the auto.master file format is incompatible with autofs. I am working with automount2amd to generate a local auto.master file for the linux box. The feature that I'm looking for is the soft link generation upon autofs startup. In TRU64, when automount is started, softlinks are created in root, based on the NIS auto.master map. So, an ls -l in a TRU64 client would display this: ... lrwxrwxrwx 1 root system 20 Jan 17 16:46 arazor -> /.automount/arazor lrwxrwxrwx 1 root system 20 Jan 20 17:05 home -> /.automount/home lrwxrwxrwx 1 root system 20 Jan 20 07:51 newrazor -> /.automount/newrazor lrwxrwxrwx 1 root system 20 Jan 17 16:46 vxdisk -> /.automount/vxdisk ... My question is this: Is it possible to configure auto.master so that when autofs starts up, These soft links will be automatically created. When autofs is shutdown, the softlinks are automatically removed. -Rob PS - If I didn't convey my question coherently, please let me know so that I can elaborate. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 20 15:39:11 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0KNd9Na031915 for ; Thu, 20 Jan 2005 15:39:10 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0KNTaFX013578; Thu, 20 Jan 2005 15:29:55 -0800 Received: from harlech.math.ucla.edu (harlech.math.ucla.edu [128.97.4.250]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0KNTXUv013571 for ; Thu, 20 Jan 2005 15:29:33 -0800 Received: from xena.cft.ca.us (lsanca1-ar2-4-60-045-106.lsanca1.dsl-verizon.net [4.60.45.106]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "James F. Carter", Issuer "UCLA-Mathnet Root Certificate" (verified OK)) by harlech.math.ucla.edu (Postfix) with ESMTP id 8EDE075359; Thu, 20 Jan 2005 15:29:30 -0800 (PST) Received: by xena.cft.ca.us (Postfix, from userid 228) id 5BD37273A3; Thu, 20 Jan 2005 15:29:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xena.cft.ca.us (Postfix) with ESMTP id 54AEB61E6E; Thu, 20 Jan 2005 15:29:28 -0800 (PST) Date: Thu, 20 Jan 2005 15:29:28 -0800 (PST) From: Jim Carter To: "Dege, Robert C." Subject: Re: [autofs] softlink creation on startup In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 20 Jan 2005, Dege, Robert C. wrote: > I'm trying to integrate a linux box into a TRU64 UNIX network, and am > seeking some insight with automounting. Our TRU64 network uses NIS to > propagate data among our client systems. The systems have been > configured to use the NIS auto.master map to establish automount links. I've never dealt with TRU64, but it looks like they use a quite different philosophy than we do, coming from a Sun-Solaris background. To answer your question, I don't see a native way to make the desired symlinks appear, but you can do pretty arbitrary things with a programmatic map. I've attached UCLA-Mathnet's programmatic host map as an example that you might modify to both make the links happen and manage the autofs subprocesses. If your requirement is to imitate closely the TRU64 paradigm then the following advice is useless, but... I don't like a lot of random stuff in my root directory. Much better I like the Solaris-style structure: /net/$host/$mountpoint, with an indirect map for the host, not a direct map as apparently you use in TRU64. With the attached map file, any machine can mount any exported filesystem from any other machine, not needing any per machine configuration of automount files, and no NIS table listing each exported filesystem. (Access is controlled by the exporter, not through automount visibility.) The only limitation is that the exported filesystems have to be in a consistent directory across machines, which for us is the root directory, e.g. /home1, /home2, ... Sun implements a map like this intrinsically, calling it the "hosts" map type. If any reader notices that I've missed a feature, so that the programmatically generated indirect map file could be replaced by a single generic file with a substitutable argument, or something like that, I would very much appreciate a heads-up, which would let me replace this kludge, with something really elegant. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) #!/bin/sh # Equivalent of the "hosts" map on Sun's automounter. # Copyright (c) 2001 by The Regents of the University of California # Author: Jim Carter, UCLA-Mathnet , 2001-08-23 # This is an executable map file, mounted on /net. When the automounter sees # /net/$host/restof/path, it runs this script with $1 = hostname ($host). # This program creates a generic file map in /rete/$host, then emits a map # line which induces the caller to spawn a separate automount process to # serve that map (which will presumably be able to mount the filesystem # titled "restof" in this example). # Specify -d for debug mode. if [ X$1 != X-d ] ; then # If you want to customize the name of the secondary mount directory rete=/rete # Minimum time in minutes between purging unused host maps purgetime=60 # autobase is the basename of the automount program autobase=automount else shift opt_d=DEBUG rete=./rete purgetime=1 autobase=sleep fi # Idiotproof for testing if [ -z "$1" ] ; then echo "Usage: $0 hostname (hostname required)" 1>&2 fi # Purge unused host-specific map files. This occurs # at most once an hour. # find: -mmin is true if the file's mtime is N minutes old. # There's a race condition here, though we've never been # bitten. Should be improved. stamp=`find $rete/TIMESTAMP -mmin -$purgetime -print 2> /dev/null` if [ -z "$stamp" ] ; then mkdir $rete/KEEP for f in /net/* ; do bn=`basename $f` if [ -f "$rete/$bn" ] ; then mv "$rete/$bn" $rete/KEEP ; fi done rm -f $rete/[a-z]* mv $rete/KEEP/* $rete 2> /dev/null rmdir $rete/KEEP date "+host map files last purged at %Y-%m-%d %H:%M:%S" > $rete/TIMESTAMP fi # Create map file for the host-specific automount process. # Example: requesting /net/redwood/h1/whatever, map file says # "* redwood:/&" causing "mount -t nfs redwood:/h1 \ # /net/redwood/h1". echo "* $1:/&" > $rete/$1 # Emit map row to cause an autofs submount to be spawned. # Don't want key, just "-options,fstype=autofs type:mapfile". # Resulting command line is: # /usr/sbin/automount --submount /net/$1 file $rete/$1 # followed by map options if any were specified. echo "-rsize=8192,wsize=8192,retry=1,soft,fstype=autofs file:$rete/$1" exit 0 _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 21 05:01:40 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0LD1eg8000633 for ; Fri, 21 Jan 2005 05:01:40 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0LCr27h008140; Fri, 21 Jan 2005 04:53:45 -0800 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0J50iK4026352 for ; Tue, 18 Jan 2005 21:00:48 -0800 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1Cr7xK-0000gI-54; Wed, 19 Jan 2005 06:00:34 +0100 Received: from pcp09227127pcs.sanarb01.mi.comcast.net ([69.241.228.143] helo=bench-f.netapp.com) by mail-mx6.uio.no with asmtp (SSLv3:RC4-MD5:128) (Exim 4.34) id 1Cr7xG-0002Sm-BR; Wed, 19 Jan 2005 06:00:30 +0100 Subject: Re: [NFS] Re: [autofs] BUG: autofs4 + cd /net//vol/vol[0-3] = port usage problems From: Trond Myklebust To: Ian Kent In-Reply-To: References: <200501142238.j0EMcbOT002214@jetcar.spd.analog.com> <16875.53538.836665.652032@segfault.boston.redhat.com> <16877.6946.710259.562902@segfault.boston.redhat.com> <41ED482D.8090203@sun.com> Content-Type: text/plain Date: Wed, 19 Jan 2005 00:00:16 -0500 Message-Id: <1106110817.12390.12.camel@lade.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Fri, 21 Jan 2005 04:52:58 -0800 Cc: autofs mailing list , nfs@lists.sourceforge.net, Mike Waychison , David Meleedy X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: on den 19.01.2005 Klokka 12:21 (+0800) skreiv Ian Kent: > Trond never finished them. He probably got too much flack about > scalability and request slot exhastion and gave up on it. > > He reffered to them in a previous discussion on the same topic and said > that if anyone wanted to port them to a current kernel and finish them > they were welcome. > > So I did that at the time for vanila kernels (2.4.22 amd 2.6.0) but had no > confidence in my work as my understanding of the RPC subsystem is fairly > poor and was worse at the time. I asked Trond to check them but he clearly > didn't have time. No, I haven't given up on those changes, but I've postponed merging them until after Chuck finishes testing his "transport switch". The latter is the abstraction layer that is expected to take us beyond the single udp/tcp socket paradigm so that we can add IPv6, infiniband, and multipathing. IOW it touches fairly heavily on the code in xprt.c. btw, we're aiming to have that code ready for testing at Connectathon, so if any of you are going to be attending, we can perhaps discuss this subject there? Cheers, Trond -- Trond Myklebust _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 21 12:57:44 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0LKvhpI001540 for ; Fri, 21 Jan 2005 12:57:44 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0LKkN5p030869; Fri, 21 Jan 2005 12:47:03 -0800 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0LKkIus030859 for ; Fri, 21 Jan 2005 12:46:19 -0800 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 66125B4E3; Fri, 21 Jan 2005 12:46:11 -0800 (PST) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id C12922E70; Fri, 21 Jan 2005 15:46:10 -0500 (EST) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id j0LKkAw0001265711; Fri, 21 Jan 2005 15:46:10 -0500 (EST) Date: Fri, 21 Jan 2005 15:46:10 -0500 (EST) Message-Id: <200501212046.j0LKkAw0001265711@anw.zk3.dec.com> From: werme@hp.com To: robert.dege@ngc.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_01,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org Subject: [autofs] Re: softlink creation on startup X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: robert.dege@ngc.com wrote: I'm trying to integrate a linux box into a TRU64 UNIX network, and am seeking some insight with automounting. Our TRU64 network uses NIS to propagate data among our client systems. The systems have been configured to use the NIS auto.master map to establish automount links. Here's a snippet of the file: # Razor Links /newrazor -rw,intr newrazor:/razor /arazor -rw,intr cerberus:/razor # Misc. Alpha Links /home -rw,intr mercury:/home /vxdisk -rw,intr as2508:/vxdisk Is that from auto.master map or something like auto.direct? I.e., auto.master often has a line like: % ypcat -k auto.master /home auto.home -nosuid,hard,intr /net -hosts -nosuid,hard,intr /- auto.direct -nosuid,hard,intr Then auto.direct has something like: % ypcat -k auto.direct | grep release /doclib/release_notes -rw,nosuid,soft server:/doclib/release_notes (Pay no attention to that soft mount flag. They are the work of the devil.) At startup, automount does _not_ create symbolic links. It _does_ create "intercept points," NFS mounts that go to a NFS server within the automount daemon: client 24% mount -e | grep non-ODE client:(pid6035) on /usr/doc/public/non-ODE type nfs (v2, ...) When you access the intercept point, the mount is done and then the symbolic link is created: client 25% file /usr/doc/public/non-ODE /usr/doc/public/non-ODE: symbolic link to /tmp_mnt/server/usr/doc/public/non-ODE client 26% mount -e | grep non-ODE client:(pid6035) on /usr/doc/public/non-ODE type nfs (v2, ...) server:/usr/doc/public/non-ODE on /tmp_mnt/server/usr/doc/public/non-ODE type nfs (v3, ...) I am already aware that the auto.master file format is incompatible with autofs. I am working with automount2amd to generate a local auto.master file for the linux box. The feature that I'm looking for is the soft link generation upon autofs startup. That's generally considered a misfeature for various reasons and is "corrected" in autofs implementations. In TRU64, when automount is started, softlinks are created in root, based on the NIS auto.master map. So, an ls -l in a TRU64 client would display this: ... lrwxrwxrwx 1 root system 20 Jan 17 16:46 arazor -> /.automount/arazor No, per above. (The /.automount directory is due to overriding the /tmp_mnt default.) My question is this: Is it possible to configure auto.master so that when autofs starts up, These soft links will be automatically created. When autofs is shutdown, the softlinks are automatically removed. Oh, a Linux autofs question! Beats me. I'll yield the floor. :-) BTW, Tru64 has a HP implemented autofs since V5.0 or so. # man -k autofs autofsd, autofs (8) - Automatically and transparently mounts and unmounts NFS file systems autofsmount (8) - Installs and removes AutoFS intercept points sys_attrs_autofs (5) - autofs subsystem attributes -Ric Werme P.S. This Email might not make it out to the list. Rob, if you don't see it, please post it for me. -- Eric (Ric) Werme | werme@zk3.dec.com Hewlett-Packard Co. | http://werme.8m.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Sun Jan 23 21:07:16 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0O57Eug014763 for ; Sun, 23 Jan 2005 21:07:16 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0O4vldm010695; Sun, 23 Jan 2005 20:58:26 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0O4vfNt010686 for ; Sun, 23 Jan 2005 20:57:42 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0O4wnlm025552 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Jan 2005 12:58:50 +0800 Date: Mon, 24 Jan 2005 12:58:49 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: werme@hp.com Subject: Re: [autofs] Re: softlink creation on startup In-Reply-To: <200501212046.j0LKkAw0001265711@anw.zk3.dec.com> Message-ID: References: <200501212046.j0LKkAw0001265711@anw.zk3.dec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Thanks Ric for the info. I'll try to fill in the Linux autofs bit. On Fri, 21 Jan 2005 werme@hp.com wrote: > robert.dege@ngc.com wrote: > I'm trying to integrate a linux box into a TRU64 UNIX network, and > am seeking some insight with automounting. Our TRU64 network uses > NIS to propagate data among our client systems. The systems have > been configured to use the NIS auto.master map to establish > automount links. > > Here's a snippet of the file: > > # Razor Links > /newrazor -rw,intr newrazor:/razor > /arazor -rw,intr cerberus:/razor > > # Misc. Alpha Links > /home -rw,intr mercury:/home > /vxdisk -rw,intr as2508:/vxdisk > > Is that from auto.master map or something like auto.direct? I.e., > auto.master often has a line like: > > % ypcat -k auto.master > /home auto.home -nosuid,hard,intr > /net -hosts -nosuid,hard,intr > /- auto.direct -nosuid,hard,intr > > Then auto.direct has something like: > > % ypcat -k auto.direct | grep release > /doclib/release_notes -rw,nosuid,soft server:/doclib/release_notes > > (Pay no attention to that soft mount flag. They are the work of the devil.) > > At startup, automount does _not_ create symbolic links. It _does_ create > "intercept points," NFS mounts that go to a NFS server within the automount > daemon: > > client 24% mount -e | grep non-ODE > client:(pid6035) on /usr/doc/public/non-ODE type nfs (v2, ...) > > When you access the intercept point, the mount is done and then the > symbolic link is created: > > client 25% file /usr/doc/public/non-ODE > /usr/doc/public/non-ODE: symbolic link to /tmp_mnt/server/usr/doc/public/non-ODE > > client 26% mount -e | grep non-ODE > client:(pid6035) on /usr/doc/public/non-ODE type nfs (v2, ...) > server:/usr/doc/public/non-ODE on /tmp_mnt/server/usr/doc/public/non-ODE type nfs (v3, ...) The Linux automounter doesn't use the intercept then symlink to triger mounts. The interception is done directly within the kernel so symlinking is not needed. > > I am already aware that the auto.master file format is incompatible > with autofs. I am working with automount2amd to generate a local > auto.master file for the linux box. The feature that I'm looking > for is the soft link generation upon autofs startup. > > That's generally considered a misfeature for various reasons and is > "corrected" in autofs implementations. Yes. Master map syntax needs work (sigh). > > In TRU64, > when automount is started, softlinks are created in root, based on > the NIS auto.master map. So, an ls -l in a TRU64 client would > display this: > > ... > lrwxrwxrwx 1 root system 20 Jan 17 16:46 arazor -> /.automount/arazor > > No, per above. (The /.automount directory is due to overriding the /tmp_mnt > default.) > > My question is this: Is it possible to configure auto.master so > that when autofs starts up, These soft links will be automatically > created. When autofs is shutdown, the softlinks are automatically > removed. > > Oh, a Linux autofs question! Beats me. I'll yield the floor. :-) Don't think so - no. I've never seen anything in the code that would suggest that it would do this. It wouldn't be needed if the direct mount stuff was working. In fact, for single node mounts, like the ones you are having trouble with, the limited direct mount support won't work either. You will still need to manually creatre the symlinks. You'll need to wait until I get to release a 4.2.0 alpha before you will even be able to test it. Don't ask when. I don't know. All I can say is that, fixing the direct mount limitations is my personal itch. So it's right up top in priority and work on the alpha will be starting straight after 4.1.4 is released (4.1.4 beta1 is due this week). Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 24 17:06:08 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0P15xPa023825 for ; Mon, 24 Jan 2005 17:06:07 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0P105wn003186; Mon, 24 Jan 2005 17:00:42 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0P100Sq003147 for ; Mon, 24 Jan 2005 17:00:01 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0P11Clm022149 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Jan 2005 09:01:12 +0800 Date: Tue, 25 Jan 2005 09:01:12 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Chris Feist In-Reply-To: <41F531F3.2040509@redhat.com> Message-ID: References: <41F531F3.2040509@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org Subject: [autofs] Re: [PATCH] No-rmdir-patch X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Looks OK. I'll merge it into 4.1.4 brta1. It wuould be good if you could make your changes against a current CVS snapshot as there have been a lot of changes from 4.1.3. Jeff has the CVS info. Ian On Mon, 24 Jan 2005, Chris Feist wrote: > When you specify a directory where a map will be mounted in auto.master, > if it does not exist, autofs will create it upon startup and remove the > directory when it shuts down. However, if the directory already exists, > autofs will still remove it when you shut down. I've attached a patch > to autofs-4.1.3 which will prevent autofs from removing previously > exisiting directories. > > If you have any questions, let me know! > > Thanks, > Chris > > > > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 24 17:12:51 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0P1CllD023838 for ; Mon, 24 Jan 2005 17:12:51 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0P14Y8w004354; Mon, 24 Jan 2005 17:04:36 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0P14UJm004346 for ; Mon, 24 Jan 2005 17:04:31 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0P150lm022210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Jan 2005 09:05:00 +0800 Date: Tue, 25 Jan 2005 09:05:00 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: Chris Feist In-Reply-To: <41F56D27.1080005@redhat.com> Message-ID: References: <41F56D27.1080005@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org Subject: [autofs] Re: [PATCH] small patch for documenting weighted maps X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 24 Jan 2005, Chris Feist wrote: > In the linux automounter if you have something like this in a map file: > > /test hosta(10):/export localhost(20):/export hostb(30):/export > > the automounter will ignore the weighting and always pick the localhost. > The Sun automounter also behaves in this way. The patch I'm submitted > just clarifies the documentation so the user is not surprised when it > happens. > Thanks Chris I'll apply this as well. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 04:28:05 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PCS4hV027009 for ; Tue, 25 Jan 2005 04:28:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PCInEa022588; Tue, 25 Jan 2005 04:19:44 -0800 Received: from egg.area.ba.cnr.it (egg.area.ba.cnr.it [150.145.80.53]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PCIZ4k022460 for ; Tue, 25 Jan 2005 04:18:37 -0800 Received: from localhost (localhost [127.0.0.1]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PCIXkS023399 for ; Tue, 25 Jan 2005 13:18:33 +0100 Received: from klecker (klecker.ba.issia.cnr.it [150.145.84.32]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PCIToQ023394 for ; Tue, 25 Jan 2005 13:18:29 +0100 Received: from frankie by klecker with local (Exim 4.43) id 1CtPeO-00014E-7r for autofs@linux.kernel.org; Tue, 25 Jan 2005 13:18:28 +0100 Date: Tue, 25 Jan 2005 13:18:27 +0100 From: "Francesco P. Lovergine" To: autofs@linux.kernel.org Message-ID: <20050125121827.GE2032@ba.issia.cnr.it> Mail-Followup-To: autofs@linux.kernel.org References: <41F56D27.1080005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20041102+Sophos at egg.area.ba.cnr.it X-Spam-Status: No, hits=-8.5 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES, USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] NIS maps loading. X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Changes in indirect maps such as auto.home distributed via NIS are ignored until all daemons are killed and restarted. That's of course not always possible or practical (it requires all users logout). This behavior is not present in other *nix such as Solaris or True64, so it can be considered a true bug. -- Francesco P. Lovergine _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 04:43:06 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PCh43I027058 for ; Tue, 25 Jan 2005 04:43:06 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PCaVMU024934; Tue, 25 Jan 2005 04:36:40 -0800 Received: from egg.area.ba.cnr.it (egg.area.ba.cnr.it [150.145.80.53]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PCaM3N024919 for ; Tue, 25 Jan 2005 04:36:23 -0800 Received: from localhost (localhost [127.0.0.1]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PCaL9o025175 for ; Tue, 25 Jan 2005 13:36:21 +0100 Received: from klecker (klecker.ba.issia.cnr.it [150.145.84.32]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PCaDd9025160 for ; Tue, 25 Jan 2005 13:36:13 +0100 Received: from frankie by klecker with local (Exim 4.43) id 1CtPvY-0001A2-AV for autofs@linux.kernel.org; Tue, 25 Jan 2005 13:36:12 +0100 Date: Tue, 25 Jan 2005 13:36:11 +0100 From: "Francesco P. Lovergine" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050125123611.GF2032@ba.issia.cnr.it> Mail-Followup-To: autofs@linux.kernel.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050125121827.GE2032@ba.issia.cnr.it> X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20041102+Sophos at egg.area.ba.cnr.it X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 25, 2005 at 01:18:27PM +0100, Francesco P. Lovergine wrote: > Changes in indirect maps such as auto.home > distributed via NIS are ignored until all daemons are killed and > restarted. > That's of course not always possible or practical (it requires all > users logout). This behavior is not present in other *nix such as > Solaris or True64, so it can be considered a true bug. > ugh, sorry for thread hijacking :-( -- Francesco P. Lovergine _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 07:32:29 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PFWS55027354 for ; Tue, 25 Jan 2005 07:32:29 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFOQ8J017945; Tue, 25 Jan 2005 07:24:46 -0800 Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFOKAV017936 for ; Tue, 25 Jan 2005 07:24:21 -0800 Received: from sedona.intel.com (sedona.ch.intel.com [143.182.201.200]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with ESMTP id j0PFR0JC022544; Tue, 25 Jan 2005 15:27:00 GMT Received: from [143.182.226.71] (chlx001.ch.intel.com [143.182.226.71]) by sedona.intel.com (8.12.10/8.12.9/d:) with ESMTP id j0PFOjHZ008304; Tue, 25 Jan 2005 08:24:45 -0700 (MST) X-Envelope-From: mlblandf@sedona.ch.intel.com Message-ID: <41F6649D.2030602@sedona.intel.com> Date: Tue, 25 Jan 2005 08:24:13 -0700 From: Michael Blandford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Francesco P. Lovergine" Subject: Re: [autofs] NIS maps loading. References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> In-Reply-To: <20050125121827.GE2032@ba.issia.cnr.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Francesco P. Lovergine wrote: >Changes in indirect maps such as auto.home >distributed via NIS are ignored until all daemons are killed and >restarted. >That's of course not always possible or practical (it requires all >users logout). This behavior is not present in other *nix such as >Solaris or True64, so it can be considered a true bug. > > > What version of autofs are you using? Have you applied the kernel patches at kernel.org ( if you aren't using 2.6.10 ) Michael _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 07:46:48 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PFkkUw027409 for ; Tue, 25 Jan 2005 07:46:48 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFc3D2020792; Tue, 25 Jan 2005 07:38:07 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFbvxd020779 for ; Tue, 25 Jan 2005 07:37:58 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0PFbux1024840; Tue, 25 Jan 2005 10:37:56 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0PFbuO17611; Tue, 25 Jan 2005 10:37:56 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0PFbtp5002875; Tue, 25 Jan 2005 10:37:55 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0PFbXcA008723; Tue, 25 Jan 2005 10:37:34 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0PFbXus008720; Tue, 25 Jan 2005 10:37:33 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16886.26557.799629.351909@segfault.boston.redhat.com> Date: Tue, 25 Jan 2005 10:37:33 -0500 To: "Francesco P. Lovergine" Subject: Re: [autofs] NIS maps loading. In-Reply-To: <20050125121827.GE2032@ba.issia.cnr.it> References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" adds: frankie> Changes in indirect maps such as auto.home distributed via NIS are frankie> ignored until all daemons are killed and restarted. That's of frankie> course not always possible or practical (it requires all users frankie> logout). This behavior is not present in other *nix such as frankie> Solaris or True64, so it can be considered a true bug. This is a known issue, and there are patches to address it. Depending on what kernel you are running, you may also have to patch that as well. Unfortunately, I can't find the map update patch in the usual place. You can get it from the srpms here: http://people.redhat.com/jmoyer/ Grab the latest srpm, and extract these two patches: autofs-4.1.3-ian-map-expiry-1.patch autofs-4.1.3-ian-map-expiry-multimount-fix.patch The kernel patch you want is also listed on the website above. You could also just wait for 4.1.4 (or the beta version thereof). Hope this helps. Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 07:47:29 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PFlOk0027415 for ; Tue, 25 Jan 2005 07:47:29 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFfvK4021259; Tue, 25 Jan 2005 07:42:00 -0800 Received: from egg.area.ba.cnr.it (egg.area.ba.cnr.it [150.145.80.53]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFfqK6021252 for ; Tue, 25 Jan 2005 07:41:53 -0800 Received: from localhost (localhost [127.0.0.1]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFforl012274 for ; Tue, 25 Jan 2005 16:41:50 +0100 Received: from klecker (klecker.ba.issia.cnr.it [150.145.84.32]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFffmK012248 for ; Tue, 25 Jan 2005 16:41:41 +0100 Received: from frankie by klecker with local (Exim 4.43) id 1CtSp1-0002Xy-D2 for autofs@linux.kernel.org; Tue, 25 Jan 2005 16:41:39 +0100 Date: Tue, 25 Jan 2005 16:41:38 +0100 From: "Francesco P. Lovergine" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050125154138.GB8093@ba.issia.cnr.it> Mail-Followup-To: autofs@linux.kernel.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <41F6649D.2030602@sedona.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F6649D.2030602@sedona.intel.com> X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20041102+Sophos at egg.area.ba.cnr.it X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 25, 2005 at 08:24:13AM -0700, Michael Blandford wrote: > Francesco P. Lovergine wrote: > > >Changes in indirect maps such as auto.home > >distributed via NIS are ignored until all daemons are killed and > >restarted. > >That's of course not always possible or practical (it requires all > >users logout). This behavior is not present in other *nix such as > >Solaris or True64, so it can be considered a true bug. > > > > > > > > What version of autofs are you using? Have you applied the kernel > patches at kernel.org ( if you aren't using 2.6.10 ) > > Michael Autofs 4.1.3-8 in Debian testing. That's with stock debian kernel 2.6.8 (which is a patched 2.6.8.1). I suspect that has nothing to do with kernel space, anyway. It's a mere missing invalidation of NIS maps. Note that ypcat returns correctly the new map, but autofs continues to use the wrong obsolete one. I can try 2.6.10 if you will feel better with that :) In fact, if the old map auto.home contains something like frankie hostA:/pathA and the new map in the same file frankie hostB:/pathB autofs will mount hostA:/pathA for user frankie instead of the new one. The only workaround is restarting autofs daemon. That's obviuosly true even if user home was not mounted previously. BTW, I have the same problem with FC3. That's quite annoying, also considering that other unices behaves correctly. -- Francesco P. Lovergine _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 07:54:09 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PFs8P8027434 for ; Tue, 25 Jan 2005 07:54:09 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFomFN024878; Tue, 25 Jan 2005 07:50:57 -0800 Received: from egg.area.ba.cnr.it (egg.area.ba.cnr.it [150.145.80.53]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFoY3w024510 for ; Tue, 25 Jan 2005 07:50:34 -0800 Received: from localhost (localhost [127.0.0.1]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFoViX013143; Tue, 25 Jan 2005 16:50:31 +0100 Received: from klecker (klecker.ba.issia.cnr.it [150.145.84.32]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFoORc013137; Tue, 25 Jan 2005 16:50:24 +0100 Received: from frankie by klecker with local (Exim 4.43) id 1CtSxS-0002eB-KJ; Tue, 25 Jan 2005 16:50:22 +0100 Date: Tue, 25 Jan 2005 16:50:21 +0100 From: "Francesco P. Lovergine" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050125155021.GC8093@ba.issia.cnr.it> Mail-Followup-To: autofs@linux.kernel.org, sesse@debian.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16886.26557.799629.351909@segfault.boston.redhat.com> X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20041102+Sophos at egg.area.ba.cnr.it X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: sesse@debian.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 25, 2005 at 10:37:33AM -0500, Jeff Moyer wrote: > ==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" adds: > > frankie> Changes in indirect maps such as auto.home distributed via NIS are > frankie> ignored until all daemons are killed and restarted. That's of > frankie> course not always possible or practical (it requires all users > frankie> logout). This behavior is not present in other *nix such as > frankie> Solaris or True64, so it can be considered a true bug. > > This is a known issue, and there are patches to address it. Depending on > what kernel you are running, you may also have to patch that as well. > > Unfortunately, I can't find the map update patch in the usual place. You > can get it from the srpms here: > > http://people.redhat.com/jmoyer/ > > Grab the latest srpm, and extract these two patches: > > autofs-4.1.3-ian-map-expiry-1.patch > autofs-4.1.3-ian-map-expiry-multimount-fix.patch > > The kernel patch you want is also listed on the website above. You could > also just wait for 4.1.4 (or the beta version thereof). Uhm, probably we missed that in current debian. Isn't it the same of FC3? -- Francesco P. Lovergine _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 08:04:52 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PG4oKR027454 for ; Tue, 25 Jan 2005 08:04:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFucwO026469; Tue, 25 Jan 2005 07:56:42 -0800 Received: from egg.area.ba.cnr.it (egg.area.ba.cnr.it [150.145.80.53]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PFuVKl026462 for ; Tue, 25 Jan 2005 07:56:32 -0800 Received: from localhost (localhost [127.0.0.1]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFuTvJ013842; Tue, 25 Jan 2005 16:56:29 +0100 Received: from klecker (klecker.ba.issia.cnr.it [150.145.84.32]) by egg.area.ba.cnr.it (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id j0PFuPB3013832; Tue, 25 Jan 2005 16:56:25 +0100 Received: from frankie by klecker with local (Exim 4.43) id 1CtT3H-0002gu-EK; Tue, 25 Jan 2005 16:56:23 +0100 Date: Tue, 25 Jan 2005 16:56:22 +0100 From: "Francesco P. Lovergine" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050125155622.GD8093@ba.issia.cnr.it> Mail-Followup-To: autofs@linux.kernel.org, sesse@debian.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> <20050125155021.GC8093@ba.issia.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050125155021.GC8093@ba.issia.cnr.it> X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20041102+Sophos at egg.area.ba.cnr.it X-Spam-Status: No, hits=-8.9 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: sesse@debian.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote: > > > > Grab the latest srpm, and extract these two patches: > > > > autofs-4.1.3-ian-map-expiry-1.patch > > autofs-4.1.3-ian-map-expiry-multimount-fix.patch > > > > The kernel patch you want is also listed on the website above. You could > > also just wait for 4.1.4 (or the beta version thereof). > > Uhm, probably we missed that in current debian. Isn't it the same of FC3? > I meant if those patches are currently in the FC3 edition... -- Francesco P. Lovergine _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 08:25:49 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PGPmeW027862 for ; Tue, 25 Jan 2005 08:25:49 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PGKYD3032214; Tue, 25 Jan 2005 08:20:46 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PGKOlK031881 for ; Tue, 25 Jan 2005 08:20:25 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0PGKLVj006352; Tue, 25 Jan 2005 11:20:21 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0PGKKO00701; Tue, 25 Jan 2005 11:20:20 -0500 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j0PGKKp5006505; Tue, 25 Jan 2005 11:20:20 -0500 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j0PGJwFI011034; Tue, 25 Jan 2005 11:19:58 -0500 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j0PGJw5x011031; Tue, 25 Jan 2005 11:19:58 -0500 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16886.29102.650204.249948@segfault.boston.redhat.com> Date: Tue, 25 Jan 2005 11:19:58 -0500 To: "Francesco P. Lovergine" Subject: Re: [autofs] NIS maps loading. In-Reply-To: <20050125155021.GC8093@ba.issia.cnr.it> References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> <20050125155021.GC8093@ba.issia.cnr.it> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org, sesse@debian.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jmoyer@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: ==> Regarding Re: [autofs] NIS maps loading.; "Francesco P. Lovergine" adds: f.lovergine> On Tue, Jan 25, 2005 at 10:37:33AM -0500, Jeff Moyer wrote: >> ==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" >> adds: >> frankie> Changes in indirect maps such as auto.home distributed via NIS are frankie> ignored until all daemons are killed and restarted. That's of frankie> course not always possible or practical (it requires all users frankie> logout). This behavior is not present in other *nix such as frankie> Solaris or True64, so it can be considered a true bug. >> This is a known issue, and there are patches to address it. Depending >> on what kernel you are running, you may also have to patch that as well. >> >> Unfortunately, I can't find the map update patch in the usual place. >> You can get it from the srpms here: >> >> http://people.redhat.com/jmoyer/ >> >> Grab the latest srpm, and extract these two patches: >> >> autofs-4.1.3-ian-map-expiry-1.patch >> autofs-4.1.3-ian-map-expiry-multimount-fix.patch >> >> The kernel patch you want is also listed on the website above. You >> could also just wait for 4.1.4 (or the beta version thereof). f.lovergine> Uhm, probably we missed that in current debian. Isn't it the f.lovergine> same of FC3? The fc3 tree I'm looking at has this change. If it isn't out there right now, it will be available in the next update (which I think is coming soon). FWIW, RHEL 4 also has this change. -Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 25 08:53:47 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0PGrkjR027919 for ; Tue, 25 Jan 2005 08:53:47 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PGp7Kr008040; Tue, 25 Jan 2005 08:51:11 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0PGorAa007930 for ; Tue, 25 Jan 2005 08:51:00 -0800 Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:204:e2ff:fe39:8e2b] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1CtTtu-0002Gw-Pe for autofs@linux.kernel.org; Tue, 25 Jan 2005 17:50:48 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1CtTtt-0002Gp-00 for ; Tue, 25 Jan 2005 17:50:45 +0100 Date: Tue, 25 Jan 2005 17:50:45 +0100 From: "Steinar H. Gunderson" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050125165045.GA8642@uio.no> Mail-Followup-To: autofs@linux.kernel.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> <20050125155021.GC8093@ba.issia.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050125155021.GC8093@ba.issia.cnr.it> X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote: >> The kernel patch you want is also listed on the website above. You could >> also just wait for 4.1.4 (or the beta version thereof). > Uhm, probably we missed that in current debian. Isn't it the same of FC3? Probably we missed it, yes. I'm still on semi-vacation (although I'm home from the USA, it's hard to do extensive testing without a Linux system :-) ), so I guess I'll simply wait for 4.1.4, which should be a largely problem-free update for us anyhow. BTW, current Debian versions has fixes for whitespace in parse_sun.c (also for non-multimaps); are those fused upstream yet? /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 06:40:31 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QEeTan030760 for ; Wed, 26 Jan 2005 06:40:31 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QEbDB5005020; Wed, 26 Jan 2005 06:37:14 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0OLmQRj008232 for ; Mon, 24 Jan 2005 13:48:26 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0OLmN7u024664; Mon, 24 Jan 2005 16:48:23 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0OLmNO04858; Mon, 24 Jan 2005 16:48:23 -0500 Received: from [172.16.30.26] (gold.msp.redhat.com [172.16.30.26]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j0OLmNOC029397; Mon, 24 Jan 2005 16:48:23 -0500 Message-ID: <41F56D27.1080005@redhat.com> Date: Mon, 24 Jan 2005 15:48:23 -0600 From: Chris Feist Organization: Red Hat, Inc. User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: raven@themaw.net Content-Type: multipart/mixed; boundary="------------010901020209000309090800" X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 26 Jan 2005 06:30:19 -0800 Cc: autofs@linux.kernel.org Subject: [autofs] [PATCH] small patch for documenting weighted maps X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cfeist@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is a multi-part message in MIME format. --------------010901020209000309090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In the linux automounter if you have something like this in a map file: /test hosta(10):/export localhost(20):/export hostb(30):/export the automounter will ignore the weighting and always pick the localhost. The Sun automounter also behaves in this way. The patch I'm submitted just clarifies the documentation so the user is not surprised when it happens. Thanks, Chris --------------010901020209000309090800 Content-Type: text/x-patch; name="autofs-4.1.3-replicated-server-doc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="autofs-4.1.3-replicated-server-doc.patch" --- autofs-4.1.3/README.replicated-server.orig 2005-01-24 15:26:28.609436878 -0600 +++ autofs-4.1.3/README.replicated-server 2005-01-24 15:27:57.592082878 -0600 @@ -27,7 +27,10 @@ Mutliple weighted, replicated hosts same Will pick lowest weighted host that responds to RPC call. RPC time is not counted, only whether the call got a reply at all. Initially does a .1 second timeout, if all hosts -fail this, moves to 10 second timeout. +fail this, moves to 10 second timeout. If one of the hosts +is localhost, the automounter will choose that regardless of +its weight. (This has been done to remain compatible with +Sun's automounter) Multiple weighted, replicated hosts different (potentially) paths: --------------010901020209000309090800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --------------010901020209000309090800-- From autofs-bounces@linux.kernel.org Wed Jan 26 06:40:38 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QEebs7030768 for ; Wed, 26 Jan 2005 06:40:38 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QEanLQ004974; Wed, 26 Jan 2005 06:36:55 -0800 Received: from tangens.sinus.cz (root@tangens.sinus.cz [195.39.17.8]) by hera.kernel.org (8.12.11/8.12.8) with SMTP id j0MLqTFh002556 for ; Sat, 22 Jan 2005 13:52:31 -0800 Received: from tangens.sinus.cz (patrol@localhost [127.0.0.1]) by tangens.sinus.cz (8.12.11/8.12.11) with ESMTP id j0MLqSci015939 for ; Sat, 22 Jan 2005 22:52:28 +0100 Received: (from patrol@localhost) by tangens.sinus.cz (8.12.11/8.12.11/Submit) id j0MLqSxm015938 for autofs@linux.kernel.org; Sat, 22 Jan 2005 22:52:28 +0100 Date: Sat, 22 Jan 2005 22:52:28 +0100 From: Pavel Troller To: autofs@linux.kernel.org Message-ID: <20050122215228.GA14303@tangens.sinus.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-8.1 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 26 Jan 2005 06:30:20 -0800 Subject: [autofs] automount 4.1.3: unmount timeout not working X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pavel Troller List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hello to all the list members, I decided to write to this list after a lot of time spent by trying to find an answer for my question, but I didn't find any so I'm trying the luck here. I'm using automount 4.1.3 with kernel 2.6.10, but the problem appeared formerly, with 2.6.7, and it's not directly related to the kernel, because it didn't appear with a kernel change, but with some other change in my system or setup, which I cannot track down. The problem itself is that the autoumount doesn't unmount automatically after the timeout expires. Of course the mounted volume is not used anymore. Manual umnounting with umount /mnt/volume (by root) works. Forced unmounting by sending SIGUSR1 to automount works too. When a verbose/debug mode is used, there is no message indicating that a timeout expired. It simply seems that the timeout is not triggered at all. I'm inserting an excerpt of the system log made by automount in debug mode: Jan 22 22:26:51 arcus automount[16106]: starting automounter version 4.1.3, path = /mnt, maptype = file, mapname = /etc/autofs/auto.mnt Jan 22 22:26:51 arcus automount[16106]: mount(bind): bind_works = 1 Jan 22 22:26:51 arcus automount[16106]: using kernel protocol version 4.05 Jan 22 22:26:51 arcus automount[16106]: using timeout 2 seconds; freq 1 secs Jan 22 22:26:52 arcus automount[16106]: sig 14 switching from 1 to 2 Jan 22 22:26:52 arcus automount[16106]: get_pkt: state 1, next 2 Jan 22 22:26:52 arcus automount[16106]: st_expire(): state = 1 Jan 22 22:26:52 arcus automount[16106]: expire_proc: exp_proc=16118 Jan 22 22:26:52 arcus automount[16106]: handle_child: got pid 16118, sig 0 (0), stat 0 Jan 22 22:26:52 arcus automount[16106]: sigchld: exp 16118 finished, switching from 1 to 1 Jan 22 22:26:52 arcus automount[16106]: get_pkt: state 2, next 1 Jan 22 22:26:52 arcus automount[16106]: st_ready(): state = 2 Jan 22 22:27:10 arcus automount[16106]: handle_packet: type = 0 Jan 22 22:27:10 arcus automount[16106]: handle_packet_missing: token 24, name udfcd Jan 22 22:27:10 arcus automount[16106]: attempting to mount entry /mnt/udfcd Jan 22 22:27:10 arcus automount[16146]: lookup(file): udfcd -> -fstype=udf,rw,noatime,gid=32,umask=002^I:/dev/pktcdvd/0 [Details about parsing map files and output from packet writing driver removed] Jan 22 22:27:14 arcus kernel: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2004/11/15 17:24 (103c) Jan 22 22:27:14 arcus automount[16146]: mount(generic): mounted /dev/pktcdvd/0 type udf on /mnt/udfcd Jan 22 22:27:14 arcus automount[16106]: handle_child: got pid 16146, sig 0 (0), stat 0 Jan 22 22:27:14 arcus automount[16106]: sig_child: found pending iop pid 16146: signalled 0 (sig 0), exit status 0 Jan 22 22:27:14 arcus automount[16106]: send_ready: token=24 The above log was made by starting the automounter and entering "ls /mnt/udfcd". 2 seconds after these messages, another ones indicating expiration of the mount shoud appear, but they don't, and the volume is still mounted. Now I'm killing with SIGUSR1: Jan 22 22:45:09 arcus automount[16106]: sig 10 switching from 1 to 3 Jan 22 22:45:09 arcus automount[16106]: get_pkt: state 1, next 3 Jan 22 22:45:09 arcus automount[16106]: st_prune(): state = 1 Jan 22 22:45:09 arcus automount[16106]: expire_proc: exp_proc=17400 Jan 22 22:45:09 arcus automount[16106]: handle_packet: type = 2 Jan 22 22:45:09 arcus automount[16106]: handle_packet_expire_multi: token 25, name udfcd Jan 22 22:45:09 arcus automount[17401]: expiring path /mnt/udfcd Jan 22 22:45:09 arcus automount[17401]: umount_multi: path=/mnt/udfcd incl=1 Jan 22 22:45:09 arcus automount[17401]: umount_multi: unmounting dir=/mnt/udfcd Jan 22 22:45:13 arcus automount[17401]: rm_unwanted: /mnt/udfcd Jan 22 22:45:13 arcus automount[17401]: expired /mnt/udfcd Jan 22 22:45:13 arcus automount[16106]: handle_child: got pid 17401, sig 0 (0), stat 0 Jan 22 22:45:13 arcus automount[16106]: sig_child: found pending iop pid 17401: signalled 0 (sig 0), exit status 0 Jan 22 22:45:13 arcus automount[16106]: send_ready: token=25 Jan 22 22:45:13 arcus automount[16106]: handle_child: got pid 17400, sig 0 (0), stat 0 Jan 22 22:45:13 arcus automount[16106]: sigchld: exp 17400 finished, switching from 3 to 1 Jan 22 22:45:13 arcus automount[16106]: get_pkt: state 3, next 1 Jan 22 22:45:13 arcus automount[16106]: st_ready(): state = 3 I'm really unhappy with this, automount worked for a long time for me and now such a problem... Any help would be greatly appreciated! And please, Cc: me, I'm not subscribed to the list. Many thanks in advance! With regards, Pavel Troller _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 06:43:03 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QEh2hx030779 for ; Wed, 26 Jan 2005 06:43:03 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QEb3Q2005000; Wed, 26 Jan 2005 06:37:06 -0800 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0OHZnAK002551 for ; Mon, 24 Jan 2005 09:35:52 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0OHZm85012639; Mon, 24 Jan 2005 12:35:48 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0OHZmO21464; Mon, 24 Jan 2005 12:35:48 -0500 Received: from [172.16.30.26] (gold.msp.redhat.com [172.16.30.26]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j0OHZlEU018143; Mon, 24 Jan 2005 12:35:48 -0500 Message-ID: <41F531F3.2040509@redhat.com> Date: Mon, 24 Jan 2005 11:35:47 -0600 From: Chris Feist Organization: Red Hat, Inc. User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: raven@themaw.net Content-Type: multipart/mixed; boundary="------------030507020706010006000907" X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Wed, 26 Jan 2005 06:30:19 -0800 Cc: autofs@linux.kernel.org Subject: [autofs] [PATCH] No-rmdir-patch X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cfeist@redhat.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is a multi-part message in MIME format. --------------030507020706010006000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When you specify a directory where a map will be mounted in auto.master, if it does not exist, autofs will create it upon startup and remove the directory when it shuts down. However, if the directory already exists, autofs will still remove it when you shut down. I've attached a patch to autofs-4.1.3 which will prevent autofs from removing previously exisiting directories. If you have any questions, let me know! Thanks, Chris --------------030507020706010006000907 Content-Type: text/plain; name="no-rmdir-patch-vanilla" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="no-rmdir-patch-vanilla" --- autofs-4.1.3/daemon/automount.c.orig 2004-04-05 08:14:10.000000000 -0500 +++ autofs-4.1.3/daemon/automount.c 2005-01-24 11:30:37.013417216 -0600 @@ -426,9 +426,17 @@ static int mount_autofs(char *path) ap.pipefd = ap.ioctlfd = -1; /* In case the directory doesn't exist, try to mkdir it */ - if (mkdir_path(path, 0555) < 0 && errno != EEXIST && errno != EROFS) { - crit("failed to create iautofs directory %s", ap.path); - return -1; + if (mkdir_path(path, 0555) < 0) { + if (errno != EEXIST && errno != EROFS) { + crit("failed to create iautofs directory %s", ap.path); + return -1; + } + /* If we recieve an error, and it's EEXIST or EROFS we know + the directory was not created. */ + ap.dir_created = 0; + } else { + /* No errors so the directory was successfully created */ + ap.dir_created = 1; } /* Pipe for kernel communications */ @@ -1341,7 +1349,7 @@ static void cleanup_exit(const char *pat closelog(); - if ((!ap.ghost || !submount) && *(path + 1) != '-') + if ((!ap.ghost || !submount) && (*(path + 1) != '-') && ap.dir_created) if (rmdir(path) == -1) warn("failed to remove dir %s: %m", path); @@ -1664,6 +1672,7 @@ int main(int argc, char *argv[]) ap.exp_timeout = DEFAULT_TIMEOUT; ap.ghost = DEFAULT_GHOST_MODE; ap.type = LKP_INDIRECT; + ap.dir_created = 0; /* We haven't created the main directory yet */ opterr = 0; while ((opt = getopt_long(argc, argv, "+hp:t:vdVg", long_options, NULL)) != EOF) { --- autofs-4.1.3/include/automount.h.orig 2004-05-18 07:20:08.000000000 -0500 +++ autofs-4.1.3/include/automount.h 2005-01-24 11:30:37.014417200 -0600 @@ -111,6 +111,8 @@ struct autofs_point { struct lookup_mod *lookup; /* Lookup module */ enum states state; int state_pipe[2]; + unsigned dir_created; /* Was a directory created for this + mount? */ }; /* Standard function used by daemon or modules */ --------------030507020706010006000907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --------------030507020706010006000907-- From autofs-bounces@linux.kernel.org Wed Jan 26 06:47:52 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QElpCC030791 for ; Wed, 26 Jan 2005 06:47:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QESH4x003971; Wed, 26 Jan 2005 06:29:03 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QESA7O003945 for ; Wed, 26 Jan 2005 06:28:12 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0QETjlm006968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jan 2005 22:29:45 +0800 Date: Wed, 26 Jan 2005 22:17:53 +0800 (WST) From: raven@themaw.net To: linux-fsdevel , autofs mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-96.6, required 8, NO_REAL_NAME, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, SEARCH_ENGINE_PROMO, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_01,NO_REAL_NAME,RCVD_IN_ORBS,SEARCH_ENGINE_PROMO, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: Subject: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi all, It's been a long time between releases so there are many changes that need testing and so this is labeled a beta so we can test it. For more information look at the CHANGELOG in the distribution. There are still a few problems that I'm aware of such as: - the init script for Debian and Gentoo doesn't handle the reload option quite right. - there seems to be a bug with the selection of the default map type when using submounts. I still need to investigate this. So let me know when you find more and I'll fix`em as quick as I can! The distribution can be found at the usual place at: http://www.kernel.org/pub/linux/daemons/autofs/v4 in the tars autofs-4.1.4_beta1.tar.[gz|bz2] also there is a tarball called: autofs-4.1.4-beta1-deb.tar.[gz|bz2] that can be used to build binary debs (see below). It is possible to build packages for testing from the distribution. I'm not the maintainer of any of these distribution packages so please be aware that this is for convenience and testing. To build an rpm package use: rpmbuild -tb autofs-4.1.4_beta1.tar.gz and the binary rpms will end up in the usual location. To merge the package into Gentoo use: tar zxf autofs-4.1.4_beta1.tar.gz cd autofs-4.1.4_beta1/gentoo export PORTDIR_OVERLAY=`pwd` ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild digest ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild clean install ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild qmerge unset PORTDIR_OVERLAY To build binary debs for Debian download the tar refered to above and: tar zxvf autofs-4.1.4-beta1-deb.tar.gz dpkg-source -x autofs_4.1.4-beta1-1.dsc cd autofs-4.1.4-beta1 dpkg-buildpackage -b and the binary debs will be placed in the directory the tar was unpacked. Hopefuly this will help with the testing Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 06:54:19 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QEsIj9030808 for ; Wed, 26 Jan 2005 06:54:19 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QEpp41005532; Wed, 26 Jan 2005 06:51:55 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QEpjKh005521 for ; Wed, 26 Jan 2005 06:51:46 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0QErPlm007557 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jan 2005 22:53:25 +0800 Date: Wed, 26 Jan 2005 22:41:33 +0800 (WST) From: raven@themaw.net To: Pavel Troller Subject: Re: [autofs] automount 4.1.3: unmount timeout not working In-Reply-To: <20050122215228.GA14303@tangens.sinus.cz> Message-ID: References: <20050122215228.GA14303@tangens.sinus.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Sat, 22 Jan 2005, Pavel Troller wrote: > Hello to all the list members, > I decided to write to this list after a lot of time spent by trying to > find an answer for my question, but I didn't find any so I'm trying the luck > here. > I'm using automount 4.1.3 with kernel 2.6.10, but the problem appeared > formerly, with 2.6.7, and it's not directly related to the kernel, because it > didn't appear with a kernel change, but with some other change in my system > or setup, which I cannot track down. > The problem itself is that the autoumount doesn't unmount automatically after > the timeout expires. Of course the mounted volume is not used anymore. Manual > umnounting with umount /mnt/volume (by root) works. Forced unmounting by > sending SIGUSR1 to automount works too. > When a verbose/debug mode is used, there is no message indicating that > a timeout expired. It simply seems that the timeout is not triggered at all. > > I'm inserting an excerpt of the system log made by automount in debug mode: > > Jan 22 22:26:51 arcus automount[16106]: starting automounter version 4.1.3, path = /mnt, maptype = file, mapname = /etc/autofs/auto.mnt > Jan 22 22:26:51 arcus automount[16106]: mount(bind): bind_works = 1 > Jan 22 22:26:51 arcus automount[16106]: using kernel protocol version 4.05 > Jan 22 22:26:51 arcus automount[16106]: using timeout 2 seconds; freq 1 secs > Jan 22 22:26:52 arcus automount[16106]: sig 14 switching from 1 to 2 > Jan 22 22:26:52 arcus automount[16106]: get_pkt: state 1, next 2 > Jan 22 22:26:52 arcus automount[16106]: st_expire(): state = 1 > Jan 22 22:26:52 arcus automount[16106]: expire_proc: exp_proc=16118 > Jan 22 22:26:52 arcus automount[16106]: handle_child: got pid 16118, sig 0 (0), stat 0 > Jan 22 22:26:52 arcus automount[16106]: sigchld: exp 16118 finished, switching from 1 to 1 > Jan 22 22:26:52 arcus automount[16106]: get_pkt: state 2, next 1 > Jan 22 22:26:52 arcus automount[16106]: st_ready(): state = 2 > Jan 22 22:27:10 arcus automount[16106]: handle_packet: type = 0 > Jan 22 22:27:10 arcus automount[16106]: handle_packet_missing: token 24, name udfcd > Jan 22 22:27:10 arcus automount[16106]: attempting to mount entry /mnt/udfcd > Jan 22 22:27:10 arcus automount[16146]: lookup(file): udfcd -> -fstype=udf,rw,noatime,gid=32,umask=002^I:/dev/pktcdvd/0 > [Details about parsing map files and output from packet writing driver removed] > Jan 22 22:27:14 arcus kernel: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2004/11/15 17:24 (103c) > Jan 22 22:27:14 arcus automount[16146]: mount(generic): mounted /dev/pktcdvd/0 type udf on /mnt/udfcd > Jan 22 22:27:14 arcus automount[16106]: handle_child: got pid 16146, sig 0 (0), stat 0 > Jan 22 22:27:14 arcus automount[16106]: sig_child: found pending iop pid 16146: signalled 0 (sig 0), exit status 0 > Jan 22 22:27:14 arcus automount[16106]: send_ready: token=24 > But you leave out the crucial log trace following the mount? Can we see more of what follows here please. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:02:17 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QF2GsQ030835 for ; Wed, 26 Jan 2005 07:02:17 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QF00hs006002; Wed, 26 Jan 2005 07:00:07 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QExsD9005982 for ; Wed, 26 Jan 2005 06:59:55 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0QF0plm007752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jan 2005 23:00:53 +0800 Date: Wed, 26 Jan 2005 22:49:00 +0800 (WST) From: raven@themaw.net To: "Francesco P. Lovergine" Subject: Re: [autofs] NIS maps loading. In-Reply-To: <20050125121827.GE2032@ba.issia.cnr.it> Message-ID: References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 25 Jan 2005, Francesco P. Lovergine wrote: > Changes in indirect maps such as auto.home > distributed via NIS are ignored until all daemons are killed and > restarted. > That's of course not always possible or practical (it requires all > users logout). This behavior is not present in other *nix such as > Solaris or True64, so it can be considered a true bug. Umm ... thats been discussed quite a bit on the list. You must have missed it. It was a fair while ago. As is mentioned later in this thread, I did create patches for this but as it was added funtionality (and was under test) it wasn't placed on kernel.org. It is however in the 4.1.4 beta and I've made some additional fixes during testing the last couple of days. Please test this out in the beta. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:05:59 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QF5w4s030845 for ; Wed, 26 Jan 2005 07:05:59 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QF46KZ006950; Wed, 26 Jan 2005 07:04:10 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QF3xs1006930 for ; Wed, 26 Jan 2005 07:04:00 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0QF4slm007866 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jan 2005 23:04:55 +0800 Date: Wed, 26 Jan 2005 22:53:02 +0800 (WST) From: raven@themaw.net To: "Steinar H. Gunderson" Subject: Re: [autofs] NIS maps loading. In-Reply-To: <20050125165045.GA8642@uio.no> Message-ID: References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> <20050125155021.GC8093@ba.issia.cnr.it> <20050125165045.GA8642@uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 25 Jan 2005, Steinar H. Gunderson wrote: > On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote: >>> The kernel patch you want is also listed on the website above. You could >>> also just wait for 4.1.4 (or the beta version thereof). >> Uhm, probably we missed that in current debian. Isn't it the same of FC3? > > Probably we missed it, yes. I'm still on semi-vacation (although I'm home from > the USA, it's hard to do extensive testing without a Linux system :-) ), so I > guess I'll simply wait for 4.1.4, which should be a largely problem-free > update for us anyhow. Umm ... I hope I haven't made life difficult for you with 4.1.4 beta. There are a dswag of changes. I've worked through and applied as many of the Debian patches as I could. Please let me know if there's more that I can do to help. > > BTW, current Debian versions has fixes for whitespace in parse_sun.c (also > for non-multimaps); are those fused upstream yet? As I said above. I also had white space handling patches that I applied. Once please test the beta. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:16:34 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QFGX7Z030867 for ; Wed, 26 Jan 2005 07:16:34 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFE7Is007404; Wed, 26 Jan 2005 07:14:12 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFDskk007386 for ; Wed, 26 Jan 2005 07:13:57 -0800 Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1Ctorc-0005a3-Ne for autofs@linux.kernel.org; Wed, 26 Jan 2005 16:13:51 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1CtorY-0000QT-00 for ; Wed, 26 Jan 2005 16:13:44 +0100 Date: Wed, 26 Jan 2005 16:13:44 +0100 From: "Steinar H. Gunderson" To: autofs@linux.kernel.org Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release Message-ID: <20050126151344.GA841@uio.no> Mail-Followup-To: autofs@linux.kernel.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-8.7 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, Jan 26, 2005 at 10:17:53PM +0800, raven@themaw.net wrote: > So let me know when you find more and I'll fix`em as quick as I can! Looks like you missed a patch or two from the Debian archive, at least: - Quite recently, I uploaded a patch for the debian/event.d script, but this is probably not relevant for the upstream distribution. - There is a patch for rc.autofs.in missing, changing an "else" to en "elif". The idea is that failure in loading the autofs4 module should not break first-time installation (see http://bugs.debian.org/280276). - There seem to have been a lot of changes in rc.autofs.in (especially related to timeout parsing); I'm unable to follow them all, but I hope you've done the right thing in merging in the Debian patches here :-) - The rc.autofs.in searches for "^automount: ", which breaks if a tab is used instead of a space (see http://bugs.debian.org/277320). - I'm also having a hard time figuring out whether parse_sun.c does the right thing wrt. handling whitespace at the end of maps or not; the code looks different, at least, but I think it's broken for non-multimaps. Could you verify? (Of course, the simplest thing is probably to test :-) ) - I can't see if lookup_file.c handles maps without a trailing newline now (Debian patch 051_maps_without_trailing_newline.diff has a hackish fix which is obviously not applied, but you might have implemented it differently). Apart from those, it appears like everything else from Debian's 4.1.3 package is in, at least -- which removes the need for twenty or so local patches :-) /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:18:23 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QFINfh030876 for ; Wed, 26 Jan 2005 07:18:23 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFGCso007536; Wed, 26 Jan 2005 07:16:15 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFG7IG007525 for ; Wed, 26 Jan 2005 07:16:07 -0800 Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1Ctotp-0005bl-Oh for autofs@linux.kernel.org; Wed, 26 Jan 2005 16:16:06 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1Ctotm-0000Rn-00 for ; Wed, 26 Jan 2005 16:16:02 +0100 Date: Wed, 26 Jan 2005 16:16:02 +0100 From: "Steinar H. Gunderson" To: autofs@linux.kernel.org Subject: Re: [autofs] NIS maps loading. Message-ID: <20050126151602.GB841@uio.no> Mail-Followup-To: autofs@linux.kernel.org References: <41F56D27.1080005@redhat.com> <20050125121827.GE2032@ba.issia.cnr.it> <16886.26557.799629.351909@segfault.boston.redhat.com> <20050125155021.GC8093@ba.issia.cnr.it> <20050125165045.GA8642@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: (No need to send directly to me anymore, I'm on the list :-) ) On Wed, Jan 26, 2005 at 10:53:02PM +0800, raven@themaw.net wrote: > Umm ... I hope I haven't made life difficult for you with 4.1.4 beta. > There are a dswag of changes. Yes, I noticed -- I'll probably let it live in experimental for a while before uploading to unstable, as we're quite near a freeze now. > I've worked through and applied as many of the Debian patches as I could. > Please let me know if there's more that I can do to help. See my last mail to the list; I guess most of the points should be in there. Overall, you're making my work a lot easier :-) /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:34:20 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QFYJpH030911 for ; Wed, 26 Jan 2005 07:34:20 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFU1a2008970; Wed, 26 Jan 2005 07:30:16 -0800 Received: from mailserv.aei.mpg.de (mailserv.aei.mpg.de [194.94.224.6]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFTpDx008915 for ; Wed, 26 Jan 2005 07:29:54 -0800 Received: by mailserv.aei.mpg.de (Postfix, from userid 65534) id 36C2431EF83; Wed, 26 Jan 2005 16:23:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailserv.aei.mpg.de (Postfix) with ESMTP id 56B4B31F99E for ; Wed, 26 Jan 2005 16:21:53 +0100 (CET) Received: from debian-server.aei.mpg.de (dhcp-122.aei.mpg.de [172.16.26.122]) by mailserv.aei.mpg.de (Postfix) with ESMTP id B42CC31F8B4 for ; Wed, 26 Jan 2005 16:20:37 +0100 (CET) Received: from stefgru by debian-server.aei.mpg.de with local (Exim 3.36 #1 (Debian)) id 1CtoyD-0001Yl-00 for ; Wed, 26 Jan 2005 16:20:37 +0100 Date: Wed, 26 Jan 2005 16:20:37 +0100 From: Steffen Grunewald To: autofs@linux.kernel.org Subject: Re: [autofs] automount 4.1.3: unmount timeout not working Message-ID: <20050126152037.GX21479@debian-server.aei.mpg.de> References: <20050122215228.GA14303@tangens.sinus.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050122215228.GA14303@tangens.sinus.cz> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by AMaViS snapshot-20020531 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Level: X-Spam-Status: No, hits=-9.5 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT_MUTT version=2.55 X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Sat, Jan 22, 2005 at 10:52:28PM +0100, Pavel Troller wrote: > Hello to all the list members, > I decided to write to this list after a lot of time spent by trying to > find an answer for my question, but I didn't find any so I'm trying the luck > here. > I'm using automount 4.1.3 with kernel 2.6.10, but the problem appeared > formerly, with 2.6.7, and it's not directly related to the kernel, because it > didn't appear with a kernel change, but with some other change in my system > or setup, which I cannot track down. I also see this (Debian Sarge, installation done some weeks ago, package version is 4.1.3-4). WIth an older installation (another Sarge), still using 3.9.99-4.0.0pre10-16, this doesn't show up. > The problem itself is that the autoumount doesn't unmount automatically after > the timeout expires. An upgrade to 4.1.3-8 apparently cured the problem; I don't know how close the Debian package maintainer Steiner Gundersson works with autofs people, and whether he's introduced some patches that have not been in the previous version (and may have found their way into 4.1.4). Sure, Debian Sarge is called "testing", that's what I'm doing, it's not "stable" yet (but there's still hope), but I'd like to see a close cooperation between the mainstream maintainers and the maintainers of Linux distros... Cheers, steffen -- Steffen Grunewald * * * Merlin cluster admin (http://pandora.aei.mpg.de) Albert-Einstein-Institut (MPI Gravitationsphysik, http://www.aei.mpg.de) Science Park Golm, Am Mühlenberg 1, 14476 Potsdam, Germany e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298} _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 07:50:01 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QFnuvo030948 for ; Wed, 26 Jan 2005 07:50:00 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFkWvw011671; Wed, 26 Jan 2005 07:46:36 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QFkP1t011662 for ; Wed, 26 Jan 2005 07:46:26 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0QFlAlm008875 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Jan 2005 23:47:11 +0800 Date: Wed, 26 Jan 2005 23:35:18 +0800 (WST) From: raven@themaw.net To: "Steinar H. Gunderson" Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release In-Reply-To: <20050126151344.GA841@uio.no> Message-ID: References: <20050126151344.GA841@uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 26 Jan 2005, Steinar H. Gunderson wrote: Cool. I'll work through this during the beta. > On Wed, Jan 26, 2005 at 10:17:53PM +0800, raven@themaw.net wrote: >> So let me know when you find more and I'll fix`em as quick as I can! > > Looks like you missed a patch or two from the Debian archive, at least: > > - Quite recently, I uploaded a patch for the debian/event.d script, but this > is probably not relevant for the upstream distribution. I'll grab it for my Debian package test build. > - There is a patch for rc.autofs.in missing, changing an "else" to en "elif". > The idea is that failure in loading the autofs4 module should not break > first-time installation (see http://bugs.debian.org/280276). I see. What if autofs[4] is not compiled as a module? This might need some more work. > - There seem to have been a lot of changes in rc.autofs.in (especially > related to timeout parsing); I'm unable to follow them all, but I hope > you've done the right thing in merging in the Debian patches here :-) Do you remember what the issues were? > - The rc.autofs.in searches for "^automount: ", which breaks if a tab is used > instead of a space (see http://bugs.debian.org/277320). Missed that one. > - I'm also having a hard time figuring out whether parse_sun.c does the right > thing wrt. handling whitespace at the end of maps or not; the code looks > different, at least, but I think it's broken for non-multimaps. Could you > verify? (Of course, the simplest thing is probably to test :-) ) Yep. There's been a bit of work there, not only related to white space. Please test this out as I need to know what I've broken. > - I can't see if lookup_file.c handles maps without a trailing newline now > (Debian patch 051_maps_without_trailing_newline.diff has a hackish fix > which is obviously not applied, but you might have implemented it > differently). I'll check. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 08:19:34 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QGJWBK031029 for ; Wed, 26 Jan 2005 08:19:34 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGGXO7016160; Wed, 26 Jan 2005 08:16:37 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGGNvj016153 for ; Wed, 26 Jan 2005 08:16:29 -0800 Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:204:e2ff:fe39:8e2b] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1Ctpou-0006FP-H9 for autofs@linux.kernel.org; Wed, 26 Jan 2005 17:16:22 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1Ctpol-0002mx-00 for ; Wed, 26 Jan 2005 17:14:55 +0100 Date: Wed, 26 Jan 2005 17:14:55 +0100 From: "Steinar H. Gunderson" To: autofs@linux.kernel.org Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release Message-ID: <20050126161454.GA9417@uio.no> Mail-Followup-To: autofs@linux.kernel.org References: <20050126151344.GA841@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, Jan 26, 2005 at 11:35:18PM +0800, raven@themaw.net wrote: >>- There is a patch for rc.autofs.in missing, changing an "else" to en >> "elif". The idea is that failure in loading the autofs4 module should not >> break first-time installation (see http://bugs.debian.org/280276). > What if autofs[4] is not compiled as a module? In that case, it is in /proc/filesystems, and there is no problem. You _could_ argue that is autofs3 was compiled into the kernel, it should fail, but I can't find a good way to detect that. >>- There seem to have been a lot of changes in rc.autofs.in (especially >> related to timeout parsing); I'm unable to follow them all, but I hope >> you've done the right thing in merging in the Debian patches here :-) > Do you remember what the issues were? (Just to clear up; "there seems to have been a lot of changes" refers to your changes, not the Debian changes, although there are several of those as well.) I'm afraid this was before I took over the maintainership of the package; the changelog is the best thing I can point you to. > Yep. There's been a bit of work there, not only related to white space. > Please test this out as I need to know what I've broken. OK, I'll give it a shot a bit later. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 08:28:49 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QGSlWS031045 for ; Wed, 26 Jan 2005 08:28:48 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGMi70016447; Wed, 26 Jan 2005 08:22:48 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGMcEj016420 for ; Wed, 26 Jan 2005 08:22:39 -0800 Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:204:e2ff:fe39:8e2b] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1CtpwD-0006Kt-DJ; Wed, 26 Jan 2005 17:22:37 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1CtpwB-0002qv-00; Wed, 26 Jan 2005 17:22:35 +0100 Date: Wed, 26 Jan 2005 17:22:35 +0100 From: "Steinar H. Gunderson" To: steffen.grunewald@aei.mpg.de Subject: Re: [autofs] automount 4.1.3: unmount timeout not working Message-ID: <20050126162235.GB9417@uio.no> Mail-Followup-To: steffen.grunewald@aei.mpg.de, autofs@linux.kernel.org References: <20050122215228.GA14303@tangens.sinus.cz> <20050126152037.GX21479@debian-server.aei.mpg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050126152037.GX21479@debian-server.aei.mpg.de> X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, Jan 26, 2005 at 04:20:37PM +0100, Steffen Grunewald wrote: > I also see this (Debian Sarge, installation done some weeks ago, package > version is 4.1.3-4). WIth an older installation (another Sarge), still using > 3.9.99-4.0.0pre10-16, this doesn't show up. 4.1.3-4 is old, there has bene _lots_ of changes since then. The latest version in sarge is 4.1.3-8; 4.1.3-9 (latest in sid) is broken due to a build problem, and only fixes a minor issue anyhow. > An upgrade to 4.1.3-8 apparently cured the problem; I don't know how > close the Debian package maintainer Steiner Gundersson works with autofs > people, and whether he's introduced some patches that have not been in > the previous version (and may have found their way into 4.1.4). I'm at least here on the list, and we're currently trying to sync most of the Debian packages into 4.1.4 (upstream has already done most of them); see the other discussion today. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 08:36:50 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0QGants031078 for ; Wed, 26 Jan 2005 08:36:50 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGYFN6019025; Wed, 26 Jan 2005 08:34:19 -0800 Received: from houinet7.hou.moc.com (houinet7.hou.moc.com [192.70.218.25]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0QGYBWo019016 for ; Wed, 26 Jan 2005 08:34:12 -0800 Received: from houexc210.mgroupnet.com ([89.60.4.131]) by houinet7.hou.moc.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Jan 2005 10:33:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release Date: Wed, 26 Jan 2005 10:33:34 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release Thread-Index: AcUDvriyexfnRKirQCOzfJSP7/r+QAABWmRg From: "Rigler, Stephen C." To: X-OriginalArrivalTime: 26 Jan 2005 16:33:34.0193 (UTC) FILETIME=[C74A3610:01C503C4] X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_10,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id j0QGYBWo019016 X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > -----Original Message----- > From: autofs-bounces@linux.kernel.org > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of raven@themaw.net > Sent: Wednesday, January 26, 2005 9:35 AM > To: Steinar H. Gunderson > Cc: autofs@linux.kernel.org > Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release > > I see. > > What if autofs[4] is not compiled as a module? > > This might need some more work. > Just to contribute to this, on Altix running SGI's variant of RHEL 3, they compile autofs (3 and 4) into the kernel and not as modules. We've had problems with automount defaulting to version 3 in this case. It works fine when compiled as a module. I opened a case with SGI asking them to ship their kernel with it compiled as a module, but I haven't heard their stance on that yet. -Steve _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 17:30:31 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0R1UPpL000834 for ; Wed, 26 Jan 2005 17:30:31 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R1KTT1020167; Wed, 26 Jan 2005 17:21:16 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R1KPIE020160 for ; Wed, 26 Jan 2005 17:20:26 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0R1LAlm020775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 09:21:10 +0800 Date: Thu, 27 Jan 2005 09:21:10 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: "Steinar H. Gunderson" Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release In-Reply-To: <20050126161454.GA9417@uio.no> Message-ID: References: <20050126151344.GA841@uio.no> <20050126161454.GA9417@uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 26 Jan 2005, Steinar H. Gunderson wrote: > On Wed, Jan 26, 2005 at 11:35:18PM +0800, raven@themaw.net wrote: > >>- There is a patch for rc.autofs.in missing, changing an "else" to en > >> "elif". The idea is that failure in loading the autofs4 module should not > >> break first-time installation (see http://bugs.debian.org/280276). > > What if autofs[4] is not compiled as a module? > > In that case, it is in /proc/filesystems, and there is no problem. You > _could_ argue that is autofs3 was compiled into the kernel, it should fail, > but I can't find a good way to detect that. Unless I see anything else I'll make the approriate change. > > >>- There seem to have been a lot of changes in rc.autofs.in (especially > >> related to timeout parsing); I'm unable to follow them all, but I hope > >> you've done the right thing in merging in the Debian patches here :-) > > Do you remember what the issues were? > > (Just to clear up; "there seems to have been a lot of changes" refers to your > changes, not the Debian changes, although there are several of those as > well.) I'm afraid this was before I took over the maintainership of the > package; the changelog is the best thing I can point you to. That's right. The Debian side of things really refers to the merging of patches I found in the packages (as best as I could) and some init script changes which you are, no doubt checking. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 17:31:42 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0R1VfwH000842 for ; Wed, 26 Jan 2005 17:31:42 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R1OkSp021230; Wed, 26 Jan 2005 17:24:59 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R1MtvN020950 for ; Wed, 26 Jan 2005 17:22:56 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0R1OIlm020820 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 09:24:19 +0800 Date: Thu, 27 Jan 2005 09:24:18 +0800 (WST) From: Ian Kent X-X-Sender: raven@wombat.indigo.net.au To: "Rigler, Stephen C." Subject: RE: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-102.5, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Wed, 26 Jan 2005, Rigler, Stephen C. wrote: > > > > -----Original Message----- > > From: autofs-bounces@linux.kernel.org > > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of raven@themaw.net > > Sent: Wednesday, January 26, 2005 9:35 AM > > To: Steinar H. Gunderson > > Cc: autofs@linux.kernel.org > > Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release > > > > I see. > > > > What if autofs[4] is not compiled as a module? > > > > This might need some more work. > > > > Just to contribute to this, on Altix running SGI's variant of RHEL 3, > they compile autofs (3 and 4) into the kernel and not as modules. > We've had problems with automount defaulting to version 3 in this case. > It works fine when compiled as a module. I opened a case with SGI > asking > them to ship their kernel with it compiled as a module, but I haven't > heard their stance on that yet. Interesting. Seems to me that having both filesystems compiled in can't work as they both attempt to register as "autofs". So first come first served. Deselecting autofs would also work of course. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 18:05:47 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0R25khJ000908 for ; Wed, 26 Jan 2005 18:05:47 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R22j3R026997; Wed, 26 Jan 2005 18:02:59 -0800 Received: from cassarossa.samfundet.no (Debian-exim@cassarossa.samfundet.no [129.241.93.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R22dO7026987 for ; Wed, 26 Jan 2005 18:02:43 -0800 Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1CtyzQ-0003Xn-Bf for autofs@linux.kernel.org; Thu, 27 Jan 2005 03:02:33 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1CtyzP-0001OR-00 for ; Thu, 27 Jan 2005 03:02:31 +0100 Date: Thu, 27 Jan 2005 03:02:31 +0100 From: "Steinar H. Gunderson" To: autofs@linux.kernel.org Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release Message-ID: <20050127020231.GB5087@uio.no> Mail-Followup-To: autofs@linux.kernel.org References: <20050126151344.GA841@uio.no> <20050126161454.GA9417@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.8.1 on a i686 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -2.8 (--) X-Spam-Status: No, hits=-9.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: (I'm still on the list, no need to Cc me :-) ) On Thu, Jan 27, 2005 at 09:21:10AM +0800, Ian Kent wrote: > The Debian side of things really refers to the merging of patches I > found in the packages (as best as I could) and some init script changes > which you are, no doubt checking. Well, I'm afraid I can't check that you got all the Debian-specific init script changes right, as I don't really know or understand half the problems these patches were fixing (and the code they modified seems to have been mostly rewritten). As long as you actually reviewed the changes, I guess we should be OK. If there'll be a 4.1.4-beta2 (with the missing patches I noticed), I'll be happy to put that in experimental and see if people get it to work properly without regressions. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 26 23:27:37 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0R7RaiB001384 for ; Wed, 26 Jan 2005 23:27:37 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R7BVLZ014060; Wed, 26 Jan 2005 23:12:02 -0800 Received: from fcl01exc.argon.corp.ch (gate.atel.ch [194.209.217.130]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0R7BOIi014047 for ; Wed, 26 Jan 2005 23:11:27 -0800 Received: from [10.18.1.59] ([10.18.1.59]) by fcl01exc.argon.corp.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jan 2005 08:11:20 +0100 Message-ID: <41F8A365.8080808@volny.cz> Date: Thu, 27 Jan 2005 08:16:37 +0000 From: Milan Knizek User-Agent: Mozilla Thunderbird 1.0 (X11/20041230) X-Accept-Language: en-us, en MIME-Version: 1.0 To: autofs@linux.kernel.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2005 07:11:20.0435 (UTC) FILETIME=[66D0FC30:01C5043F] X-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_01,RCVD_IN_ORBS,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [autofs] How to automount hidden Windows share X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hello, I am not sure if this relates to kernel or to autofs, so sorry if I am wrong. I also tried to google for the problem, but I have found only questions and no solution. I use autofs-4.1.3, gentoo-dev-sources kernel 2.6.9 compiled with automounter v4 on Gentoo. I have problems with automounting hidden Windows shares - e.g. my /etc/autofs/auto.work includes: n -fstype=smbfs,users,uid=knizek_m,gid=users,credentials=/etc/samba /credentials_argon ://ffile01/Home$ My /etc/autofs/auto.master includes: /mnt/auto.work /etc/autofs/auto.work --timeout=60 When try ls /mnt/auto.work/n, the file does not exist. Syslog reads: Jan 26 12:18:40 n1005 automount[10417]: failed to mount /mnt/auto.work/n Jan 26 12:18:40 n1005 automount[10420]: >> Usage: mount.smbfs service mountpoint [-o options,...] Jan 26 12:18:40 n1005 automount[10420]: >> Version 3.0.9 ... cut on purpose ... Jan 26 12:18:40 n1005 automount[10420]: mount(generic): failed to mount "://ffile01/Home" (type smbfs) o n /mnt/auto.work/n Jan 26 12:18:40 n1005 automount[10420]: failed to mount /mnt/auto.work/n I tried to change the line in auto.work to ://ffile01/Home\$ but it did not help anyway. When I use fstab or mount manually, it works. Also, mounting normal Windows shares (not ending with $) and local devices like cdrom and usb works fine with automount. Is there other way to go? Thanks, Milan knizek@volny.cz _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 27 04:33:12 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0RCX82D003422 for ; Thu, 27 Jan 2005 04:33:12 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RCOf1v004724; Thu, 27 Jan 2005 04:25:20 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RCOSRC004649 for ; Thu, 27 Jan 2005 04:24:29 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0RCOslm007504 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 20:25:00 +0800 Date: Thu, 27 Jan 2005 20:12:49 +0800 (WST) From: raven@themaw.net To: "Steinar H. Gunderson" Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release In-Reply-To: <20050127020231.GB5087@uio.no> Message-ID: References: <20050126151344.GA841@uio.no> <20050126161454.GA9417@uio.no> <20050127020231.GB5087@uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 27 Jan 2005, Steinar H. Gunderson wrote: > (I'm still on the list, no need to Cc me :-) ) > > On Thu, Jan 27, 2005 at 09:21:10AM +0800, Ian Kent wrote: >> The Debian side of things really refers to the merging of patches I >> found in the packages (as best as I could) and some init script changes >> which you are, no doubt checking. > > Well, I'm afraid I can't check that you got all the Debian-specific init > script changes right, as I don't really know or understand half the problems > these patches were fixing (and the code they modified seems to have been > mostly rewritten). As long as you actually reviewed the changes, I guess we > should be OK. If there'll be a 4.1.4-beta2 (with the missing patches I > noticed), I'll be happy to put that in experimental and see if people get it > to work properly without regressions. :-) I'll put the changes you discussed in. The main point here is that we really just want a working init script. The original init script didn't address some problems you were probably unaware of. Mostly related to master maps with a good number of entries. I believe I've delat with much of that within the daemon now so the init script is a little simpler and should be OK. All that really remains then is to ensure that the reported Debian problems have also been addressed. Certainly I've tried to include as many of the Debian patches as I could, some were catered for in other ways or had been applied as part of other patches. So lets see how we go. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 27 04:37:26 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0RCbPMK003435 for ; Thu, 27 Jan 2005 04:37:26 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RCXDt4005512; Thu, 27 Jan 2005 04:33:37 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RCX2So005502 for ; Thu, 27 Jan 2005 04:33:03 -0800 Received: from donald.themaw.net (203-59-151-208.dyn.iinet.net.au [203.59.151.208]) (authenticated bits=0) by wombat.indigo.net.au (8.12.8/8.12.8) with ESMTP id j0RCYdlm007706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 20:34:40 +0800 Date: Thu, 27 Jan 2005 20:22:35 +0800 (WST) From: raven@themaw.net To: Milan Knizek Subject: Re: [autofs] How to automount hidden Windows share In-Reply-To: <41F8A365.8080808@volny.cz> Message-ID: References: <41F8A365.8080808@volny.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.6, required 8, EMAIL_ATTRIBUTION, IN_REP_TO, NO_REAL_NAME, QUOTED_EMAIL_TEXT, RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_PINE, USER_IN_WHITELIST) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 27 Jan 2005, Milan Knizek wrote: > Hello, > > I am not sure if this relates to kernel or to autofs, so sorry if I am wrong. > I also tried to google for the problem, but I have found only questions and > no solution. > > > I use autofs-4.1.3, gentoo-dev-sources kernel 2.6.9 compiled with automounter > v4 on Gentoo. I have problems with automounting hidden Windows shares - e.g. > my /etc/autofs/auto.work includes: > > n -fstype=smbfs,users,uid=knizek_m,gid=users,credentials=/etc/samba What's this^^^^^ > /credentials_argon ://ffile01/Home$ > > My /etc/autofs/auto.master includes: > > /mnt/auto.work /etc/autofs/auto.work --timeout=60 > > > When try ls /mnt/auto.work/n, the file does not exist. Syslog reads: > > Jan 26 12:18:40 n1005 automount[10417]: failed to mount /mnt/auto.work/n > Jan 26 12:18:40 n1005 automount[10420]: >> Usage: mount.smbfs service > mountpoint [-o options,...] > Jan 26 12:18:40 n1005 automount[10420]: >> Version 3.0.9 > I'd like to see the log entries prior to the "failed to mount" message with the --debug option on the entry in the master map please. This looks like a parsing problem. But I would have expected escaping the $ to have worked. > ... cut on purpose ... > > Jan 26 12:18:40 n1005 automount[10420]: mount(generic): failed to mount > "://ffile01/Home" (type smbfs) o > n /mnt/auto.work/n > Jan 26 12:18:40 n1005 automount[10420]: failed to mount /mnt/auto.work/n > > > I tried to change the line in auto.work to ://ffile01/Home\$ but it did not > help anyway. > > When I use fstab or mount manually, it works. Also, mounting normal Windows > shares (not ending with $) and local devices like cdrom and usb works fine > with automount. > > Is there other way to go? > > Thanks, > Milan > knizek@volny.cz > > _______________________________________________ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 27 08:05:51 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0RG5jfm003768 for ; Thu, 27 Jan 2005 08:05:51 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RFqiJr025437; Thu, 27 Jan 2005 07:53:21 -0800 Received: from fcl01exc.argon.corp.ch (gate.atel.ch [194.209.217.130]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0RFqZaM025424 for ; Thu, 27 Jan 2005 07:52:38 -0800 Received: from [10.18.1.59] ([10.18.1.59]) by fcl01exc.argon.corp.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jan 2005 16:52:29 +0100 Message-ID: <41F91D8B.6040501@volny.cz> Date: Thu, 27 Jan 2005 16:57:47 +0000 From: Milan Knizek User-Agent: Mozilla Thunderbird 1.0 (X11/20041230) X-Accept-Language: en-us, en MIME-Version: 1.0 To: raven@themaw.net Subject: Re: [autofs] How to automount hidden Windows share - solved References: <41F8A365.8080808@volny.cz> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2005 15:52:29.0706 (UTC) FILETIME=[34C116A0:01C50488] X-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: raven@themaw.net wrote: > On Thu, 27 Jan 2005, Milan Knizek wrote: > >> n -fstype=smbfs,users,uid=knizek_m,gid=users,credentials=/etc/samba > > What's this^^^^^ ... > This looks like a parsing problem. But I would have expected escaping > the $ to have worked. I got rid of the non-sense option users and escaped the $, rebooted and now it works just fine. n -fstype=smbfs,codepage=cp852,iocharset=iso8859-2,uid=knizek_m,gid=users,credentials=/etc/samba/crede ntials_argon ://ffile01/Home\$ I think that the 'users' option should not have a big influence, since automounting worked for other non-hidden Windows shares with this option, too. Now I am busy with other issues, but later I will try to reproduce the error again (probably relates to restarting the init service) and let you know if I succeed. Thank you for input. Milan knizek@volny.cz _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 28 20:01:20 2005 Return-Path: Received: from hera.kernel.org (hera.kernel.org [209.128.68.125]) by Mail.Linux-Consulting.com (8.12.11/8.12.11/check_local-5) with ESMTP id j0T41GpX007643 for ; Fri, 28 Jan 2005 20:01:20 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.11/8.12.8) with ESMTP id j0T3qm1L015116; Fri, 28 Jan 2005 19:53:15 -0800 Received: from tangens.sinus.cz (root@tangens.sinus.cz [195.39.17.8]) by hera.kernel.org (8.12.11/8.12.8) with SMTP id j0QJmRFg015238 for ; Wed, 26 Jan 2005 11:48:29 -0800 Received: from tangens.sinus.cz (patrol@localhost [127.0.0.1]) by tangens.sinus.cz (8.12.11/8.12.11) with ESMTP id j0QJmPWA004762; Wed, 26 Jan 2005 20:48:25 +0100 Received: (from patrol@localhost) by tangens.sinus.cz (8.12.11/8.12.11/Submit) id j0QJmOvN004761; Wed, 26 Jan 2005 20:48:24 +0100 Date: Wed, 26 Jan 2005 20:48:24 +0100 From: Pavel Troller To: raven@themaw.net Subject: Re: [autofs] automount 4.1.3: unmount timeout not working Message-ID: <20050126194824.GA3627@tangens.sinus.cz> References: <20050122215228.GA14303@tangens.sinus.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-8.7 required=5.0 tests=AWL,BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Mailman-Approved-At: Fri, 28 Jan 2005 19:52:46 -0800 Cc: autofs@linux.kernel.org, Pavel Troller X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pavel Troller List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > > But you leave out the crucial log trace following the mount? > > Can we see more of what follows here please. > > Ian Hello Ian, OK, I'm sending the full system log during the mount/umount... I don't know which part You are interested in, but I don't see anything special... BTW using the UDF packet mode is just an example, umount timeout doesn't work on vfat floppies or iso9660 cd's as well... With regards, Pavel ... automount startup log not included, it' identical to the one sent earlier [ls /mnt/udfcd issued] Jan 26 20:33:32 arcus automount[1989]: handle_packet: type = 0 Jan 26 20:33:32 arcus automount[1989]: handle_packet_missing: token 3, name udfcd Jan 26 20:33:32 arcus automount[1989]: attempting to mount entry /mnt/udfcd Jan 26 20:33:32 arcus automount[3411]: lookup(file): udfcd -> -fstype=udf,rw,noatime,gid=32,umask=002^I:/dev/pktcdvd/0 Jan 26 20:33:32 arcus automount[3411]: parse(sun): expanded entry: -fstype=udf,rw,noatime,gid=32,umask=002^I:/dev/pktcdvd/0 Jan 26 20:33:32 arcus automount[3411]: parse(sun): dequote("fstype=udf,rw,noatime,gid=32,umask=002") -> fstype=udf,rw,noatime,gid=32,umask=002 Jan 26 20:33:32 arcus automount[3411]: parse(sun): gathered options: fstype=udf,rw,noatime,gid=32,umask=002 Jan 26 20:33:32 arcus automount[3411]: parse(sun): dequote("/dev/pktcdvd/0") -> /dev/pktcdvd/0 Jan 26 20:33:32 arcus automount[3411]: parse(sun): core of entry: options=fstype=udf,rw,noatime,gid=32,umask=002, loc=/dev/pktcdvd/0Jan 26 20:33:32 arcus automount[3411]: parse(sun): mounting root /mnt, mountpoint udfcd, what /dev/pktcdvd/0, fstype udf