automount won't start - just hangs

automount won't start - just hangs

[Jim Duda]

I'm attempting to use autofs on some diskless machines which operate 
using an NFS mounted root file system.  I have three different computers 
which share the same root file system (with unique /tmp and /var 
directories) and the same 2.6.22 kernel.

I want to use autofs for removable USB memory sticks.

On one machine, I can use autofs just fine.  Autofs mounts and unmounts 
the usb sticks as I expect it to.  Works nice.

However, on the other two machines, I cannot get automount to start.  It 
simply hangs upon startup, I cannot ^C to exit or anything.  I have to 
kill -9 the process.

I cannot figure out what automount is looking for, and not getting, 
which would cause it to hang.  I've attempted to use gdb to help me find 
the problem, but I haven't had much luck.  (I've downloaded the most 
recent 5.0.2 tar bar and build automount with -g to debug.

I'm hoping someone might shed some light on how best to debug this issue.

On the two machines which fail, I see this message appear on the NFS 
server which is serving up the root file system.

Dec 31 16:05:50 linux mountd[2130]: authenticated unmount request from 
asterisk:621 for /tftpboot/muekow/i386 (/tftpboot/muekow)

I don't see any such message on the machine which works properly (the 
only clue I currently have).

On the diskless machines, I have these mount points already defined 
before I attempt to start automount.

192.168.1.254:/tftpboot/muekow/i386 on /nfsroot type nfs 
(rw,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.168.1.254)
none on /proc type proc (rw)
none on /dev type tmpfs (rw)
/sys on /sys type sysfs (rw)
none on /proc/bus/usb type usbfs (rw)
192.168.1.254:/home on /home type nfs 
(rw,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.168.1.254)
192.168.1.254:/media on /media type nfs 
(rw,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.168.1.254)

Does automount for any reason attempt to unmount nfs mount points which 
are already in place?

Thanks for any advice, I'm really stumped as to why automount won't start.

Jim

Re: automount won't start - just hangs

[Ian Kent]

On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
> I'm attempting to use autofs on some diskless machines which operate 
> using an NFS mounted root file system.  I have three different computers 
> which share the same root file system (with unique /tmp and /var 
> directories) and the same 2.6.22 kernel.
> 
> I want to use autofs for removable USB memory sticks.
> 
> On one machine, I can use autofs just fine.  Autofs mounts and unmounts 
> the usb sticks as I expect it to.  Works nice.
> 
> However, on the other two machines, I cannot get automount to start.  It 
> simply hangs upon startup, I cannot ^C to exit or anything.  I have to 
> kill -9 the process.
> 
> I cannot figure out what automount is looking for, and not getting, 
> which would cause it to hang.  I've attempted to use gdb to help me find 
> the problem, but I haven't had much luck.  (I've downloaded the most 
> recent 5.0.2 tar bar and build automount with -g to debug.

Did you apply any of the patches for 5.0.2?

> 
> I'm hoping someone might shed some light on how best to debug this issue.

Have a look at http://people.redhat.com/jmoyer for what to collect and
post here.

Ian

Re: automount won't start - just hangs

[Jim Duda]

I have gathered the information required in this post.  I have provided 
the common information for machines which work and fail.  I have 
provided the syslog debug message for those that work and also those 
that fail.

lroom# rpm -q autofs
autofs-5.0.1-31

lroom# uname -a
Linux lroom 2.6.22.2-tftp #1 Sun Aug 12 11:14:47 EDT 2007 i686 i686 i386 
GNU/Linux


lroom# cat /etc/auto.master
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
#/misc  /etc/auto.misc
#/net   -hosts
/mnt/usb /etc/auto.usb --timeout=2
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
#+auto.master

lroom# cat /etc/auto.usb
device_a         -fstype=vfat,rw,gid=100,umask=002       :/dev/sda1
device_b         -fstype=vfat,rw,gid=100,umask=002       :/dev/sdb1

lroom# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
#       nisplus or nis+         Use NIS+ (NIS version 3)
#       nis or yp               Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       db                      Use the local database (.db) files
#       compat                  Use NIS on compat mode
#       hesiod                  Use Hesiod for user lookups
#       [NOTFOUND=return]       Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files
shadow:     files
group:      files

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files

publickey:  nisplus

automount:  files
aliases:    files nisplus

lroom# cat /etc/sysconfig/autofs
#
# Define default options for autofs.
#
# MASTER_MAP_NAME - default map name for the master map.
#
#MASTER_MAP_NAME="auto.master"
#
# TIMEOUT - set the default mount timeout (default 600).
#
TIMEOUT=300
#
# BROWSE_MODE - maps are browsable by default.
#
BROWSE_MODE="no"
#
# APPEND_OPTIONS - append to global options instead of replace.
#
#APPEND_OPTIONS="yes"
#
# LOGGING - set default log level "none", "verbose" or "debug"
#
LOGGING="debug"
#
# Define the default LDAP schema to use for lookups
#
# System default
#
#MAP_OBJECT_CLASS="nisMap"
#ENTRY_OBJECT_CLASS="nisObject"
#MAP_ATTRIBUTE="nisMapName"
#ENTRY_ATTRIBUTE="cn"
#VALUE_ATTRIBUTE="nisMapEntry"
#
# Other common LDAP nameing
#
#MAP_OBJECT_CLASS="automountMap"
#ENTRY_OBJECT_CLASS="automount"
#MAP_ATTRIBUTE="ou"
#ENTRY_ATTRIBUTE="cn"
#VALUE_ATTRIBUTE="automountInformation"
#
#MAP_OBJECT_CLASS="automountMap"
#ENTRY_OBJECT_CLASS="automount"
#MAP_ATTRIBUTE="automountMapName"
#ENTRY_ATTRIBUTE="automountKey"
#VALUE_ATTRIBUTE="automountInformation"
#
# AUTH_CONF_FILE - set the default location for the SASL
#                          authentication configuration file.
#
#AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
#
# General global options
#
#OPTIONS=""
#

The "linux" machine is the NFS server which provides the root file 
system for the "lroom" and "gym" machines.  The /tftpboot/muekow/i386 
directory is the root file system for the diskless machines, which is a 
static hard mount setup during the early boot process.

Here are the log files for the "lroom" machine which works properly.

Jan  1 11:43:37 lroom automount[1968]: Starting automounter version 
5.0.1-31, master map auto.master
Jan  1 11:43:37 lroom automount[1968]: using kernel protocol version 5.00
Jan  1 11:43:37 linux mountd[2130]: authenticated unmount request from 
lroom:915 for /tftpboot/muekow/i386 (/tftpboot/muekow)
Jan  1 11:44:12 linux mountd[2130]: authenticated unmount request from 
lroom:637 for /tftpboot/muekow/i386 (/tftpboot/muekow)
Jan  1 11:44:12 lroom automount[1968]: mounted indirect mount on 
/mnt/usb with timeout 2, freq 1 seconds
Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry 
/mnt/usb/DCIM
Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/DCIM
Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry 
/mnt/usb/dcim
Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/dcim
Jan  1 11:45:17 lroom xinetd[1820]: START: telnet pid=2280 
from=192.168.1.254

Here are the log files for the "gym" machine which fails to start 
automount properly.  The automount program is in the hung state at this 
point.

Jan  1 11:49:36 gym automount[1846]: Starting automounter version 
5.0.1-31, master map auto.master
Jan  1 11:49:36 gym automount[1846]: using kernel protocol version 5.00
Jan  1 11:49:36 linux mountd[2130]: authenticated unmount request from 
gym:778 for /tftpboot/muekow/i386 (/tftpboot/muekow)


I realized today that the machines which fail to work are P3 processors 
whereas the one that works is a P4 processor.  I don't know if that has 
meaning or is a pure coincidence.

Thanks for the help.

Jim





Ian Kent wrote:
> On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
>> I'm attempting to use autofs on some diskless machines which operate 
>> using an NFS mounted root file system.  I have three different computers 
>> which share the same root file system (with unique /tmp and /var 
>> directories) and the same 2.6.22 kernel.
>>
>> I want to use autofs for removable USB memory sticks.
>>
>> On one machine, I can use autofs just fine.  Autofs mounts and unmounts 
>> the usb sticks as I expect it to.  Works nice.
>>
>> However, on the other two machines, I cannot get automount to start.  It 
>> simply hangs upon startup, I cannot ^C to exit or anything.  I have to 
>> kill -9 the process.
>>
>> I cannot figure out what automount is looking for, and not getting, 
>> which would cause it to hang.  I've attempted to use gdb to help me find 
>> the problem, but I haven't had much luck.  (I've downloaded the most 
>> recent 5.0.2 tar bar and build automount with -g to debug.
> 
> Did you apply any of the patches for 5.0.2?
> 
>> I'm hoping someone might shed some light on how best to debug this issue.
> 
> Have a look at http://people.redhat.com/jmoyer for what to collect and
> post here.
> 
> Ian

Re: automount won't start - just hangs

[Ian Kent]

On Tue, 2008-01-01 at 11:54 -0500, Jim Duda wrote:
> I have gathered the information required in this post.  I have provided 
> the common information for machines which work and fail.  I have 
> provided the syslog debug message for those that work and also those 
> that fail.

This all looks OK but the debug log doesn't have the debugging info.
Did you set syslog to send daemon.* to the log?

I'm not sure we'll get much more from it but we should at least have a
look at it.

Do you get any core files for automount?

> 
> lroom# rpm -q autofs
> autofs-5.0.1-31
> 
> lroom# uname -a
> Linux lroom 2.6.22.2-tftp #1 Sun Aug 12 11:14:47 EDT 2007 i686 i686 i386 
> GNU/Linux
> 
> 
> lroom# cat /etc/auto.master
> #
> # Sample auto.master file
> # This is an automounter map and it has the following format
> # key [ -mount-options-separated-by-comma ] location
> # For details of the format look at autofs(5).
> #
> #/misc  /etc/auto.misc
> #/net   -hosts
> /mnt/usb /etc/auto.usb --timeout=2
> #
> # Include central master map if it can be found using
> # nsswitch sources.
> #
> # Note that if there are entries for /net or /misc (as
> # above) in the included master map any keys that are the
> # same will not be seen as the first read key seen takes
> # precedence.
> #
> #+auto.master
> 
> lroom# cat /etc/auto.usb
> device_a         -fstype=vfat,rw,gid=100,umask=002       :/dev/sda1
> device_b         -fstype=vfat,rw,gid=100,umask=002       :/dev/sdb1
> 
> lroom# cat /etc/nsswitch.conf
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be
> # sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an
> # entry should stop if the search in the previous entry turned
> # up nothing. Note that if the search failed due to some other reason
> # (like no NIS server responding) then the search continues with the
> # next entry.
> #
> # Legal entries are:
> #
> #       nisplus or nis+         Use NIS+ (NIS version 3)
> #       nis or yp               Use NIS (NIS version 2), also called YP
> #       dns                     Use DNS (Domain Name Service)
> #       files                   Use the local files
> #       db                      Use the local database (.db) files
> #       compat                  Use NIS on compat mode
> #       hesiod                  Use Hesiod for user lookups
> #       [NOTFOUND=return]       Stop searching if not found so far
> #
> 
> # To use db, put the "db" in front of "files" for entries you want to be
> # looked up first in the databases
> #
> # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
> 
> passwd:     files
> shadow:     files
> group:      files
> 
> #hosts:     db files nisplus nis dns
> hosts:      files dns
> 
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
> 
> bootparams: nisplus [NOTFOUND=return] files
> 
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:   files
> 
> netgroup:   files
> 
> publickey:  nisplus
> 
> automount:  files
> aliases:    files nisplus
> 
> lroom# cat /etc/sysconfig/autofs
> #
> # Define default options for autofs.
> #
> # MASTER_MAP_NAME - default map name for the master map.
> #
> #MASTER_MAP_NAME="auto.master"
> #
> # TIMEOUT - set the default mount timeout (default 600).
> #
> TIMEOUT=300
> #
> # BROWSE_MODE - maps are browsable by default.
> #
> BROWSE_MODE="no"
> #
> # APPEND_OPTIONS - append to global options instead of replace.
> #
> #APPEND_OPTIONS="yes"
> #
> # LOGGING - set default log level "none", "verbose" or "debug"
> #
> LOGGING="debug"
> #
> # Define the default LDAP schema to use for lookups
> #
> # System default
> #
> #MAP_OBJECT_CLASS="nisMap"
> #ENTRY_OBJECT_CLASS="nisObject"
> #MAP_ATTRIBUTE="nisMapName"
> #ENTRY_ATTRIBUTE="cn"
> #VALUE_ATTRIBUTE="nisMapEntry"
> #
> # Other common LDAP nameing
> #
> #MAP_OBJECT_CLASS="automountMap"
> #ENTRY_OBJECT_CLASS="automount"
> #MAP_ATTRIBUTE="ou"
> #ENTRY_ATTRIBUTE="cn"
> #VALUE_ATTRIBUTE="automountInformation"
> #
> #MAP_OBJECT_CLASS="automountMap"
> #ENTRY_OBJECT_CLASS="automount"
> #MAP_ATTRIBUTE="automountMapName"
> #ENTRY_ATTRIBUTE="automountKey"
> #VALUE_ATTRIBUTE="automountInformation"
> #
> # AUTH_CONF_FILE - set the default location for the SASL
> #                          authentication configuration file.
> #
> #AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
> #
> # General global options
> #
> #OPTIONS=""
> #
> 
> The "linux" machine is the NFS server which provides the root file 
> system for the "lroom" and "gym" machines.  The /tftpboot/muekow/i386 
> directory is the root file system for the diskless machines, which is a 
> static hard mount setup during the early boot process.
> 
> Here are the log files for the "lroom" machine which works properly.
> 
> Jan  1 11:43:37 lroom automount[1968]: Starting automounter version 
> 5.0.1-31, master map auto.master
> Jan  1 11:43:37 lroom automount[1968]: using kernel protocol version 5.00
> Jan  1 11:43:37 linux mountd[2130]: authenticated unmount request from 
> lroom:915 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> Jan  1 11:44:12 linux mountd[2130]: authenticated unmount request from 
> lroom:637 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> Jan  1 11:44:12 lroom automount[1968]: mounted indirect mount on 
> /mnt/usb with timeout 2, freq 1 seconds
> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry 
> /mnt/usb/DCIM
> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/DCIM
> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry 
> /mnt/usb/dcim
> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/dcim
> Jan  1 11:45:17 lroom xinetd[1820]: START: telnet pid=2280 
> from=192.168.1.254
> 
> Here are the log files for the "gym" machine which fails to start 
> automount properly.  The automount program is in the hung state at this 
> point.
> 
> Jan  1 11:49:36 gym automount[1846]: Starting automounter version 
> 5.0.1-31, master map auto.master
> Jan  1 11:49:36 gym automount[1846]: using kernel protocol version 5.00
> Jan  1 11:49:36 linux mountd[2130]: authenticated unmount request from 
> gym:778 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> 
> 
> I realized today that the machines which fail to work are P3 processors 
> whereas the one that works is a P4 processor.  I don't know if that has 
> meaning or is a pure coincidence.
> 
> Thanks for the help.
> 
> Jim
> 
> 
> 
> 
> 
> Ian Kent wrote:
> > On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
> >> I'm attempting to use autofs on some diskless machines which operate 
> >> using an NFS mounted root file system.  I have three different computers 
> >> which share the same root file system (with unique /tmp and /var 
> >> directories) and the same 2.6.22 kernel.
> >>
> >> I want to use autofs for removable USB memory sticks.
> >>
> >> On one machine, I can use autofs just fine.  Autofs mounts and unmounts 
> >> the usb sticks as I expect it to.  Works nice.
> >>
> >> However, on the other two machines, I cannot get automount to start.  It 
> >> simply hangs upon startup, I cannot ^C to exit or anything.  I have to 
> >> kill -9 the process.
> >>
> >> I cannot figure out what automount is looking for, and not getting, 
> >> which would cause it to hang.  I've attempted to use gdb to help me find 
> >> the problem, but I haven't had much luck.  (I've downloaded the most 
> >> recent 5.0.2 tar bar and build automount with -g to debug.
> > 
> > Did you apply any of the patches for 5.0.2?
> > 
> >> I'm hoping someone might shed some light on how best to debug this issue.
> > 
> > Have a look at http://people.redhat.com/jmoyer for what to collect and
> > post here.
> > 
> > Ian
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: automount won't start - just hangs

[Jim Duda]

My syslog.conf has this:
*.* @192.168.1.254
Doesn't that cover "everything", including daemon?

No core dumps.

I started using gdb to find where the program was hanging.  I was down deep into reading the nisswitch.conf file, then 
got lost.

Jim


"Ian Kent" <raven@themaw.net> wrote in message news:1199238944.3072.10.camel@raven.themaw.net...
> On Tue, 2008-01-01 at 11:54 -0500, Jim Duda wrote:
>> I have gathered the information required in this post.  I have provided
>> the common information for machines which work and fail.  I have
>> provided the syslog debug message for those that work and also those
>> that fail.
>
> This all looks OK but the debug log doesn't have the debugging info.
> Did you set syslog to send daemon.* to the log?
>
> I'm not sure we'll get much more from it but we should at least have a
> look at it.
>
> Do you get any core files for automount?
>
>>
>> lroom# rpm -q autofs
>> autofs-5.0.1-31
>>
>> lroom# uname -a
>> Linux lroom 2.6.22.2-tftp #1 Sun Aug 12 11:14:47 EDT 2007 i686 i686 i386
>> GNU/Linux
>>
>>
>> lroom# cat /etc/auto.master
>> #
>> # Sample auto.master file
>> # This is an automounter map and it has the following format
>> # key [ -mount-options-separated-by-comma ] location
>> # For details of the format look at autofs(5).
>> #
>> #/misc  /etc/auto.misc
>> #/net   -hosts
>> /mnt/usb /etc/auto.usb --timeout=2
>> #
>> # Include central master map if it can be found using
>> # nsswitch sources.
>> #
>> # Note that if there are entries for /net or /misc (as
>> # above) in the included master map any keys that are the
>> # same will not be seen as the first read key seen takes
>> # precedence.
>> #
>> #+auto.master
>>
>> lroom# cat /etc/auto.usb
>> device_a         -fstype=vfat,rw,gid=100,umask=002       :/dev/sda1
>> device_b         -fstype=vfat,rw,gid=100,umask=002       :/dev/sdb1
>>
>> lroom# cat /etc/nsswitch.conf
>> #
>> # /etc/nsswitch.conf
>> #
>> # An example Name Service Switch config file. This file should be
>> # sorted with the most-used services at the beginning.
>> #
>> # The entry '[NOTFOUND=return]' means that the search for an
>> # entry should stop if the search in the previous entry turned
>> # up nothing. Note that if the search failed due to some other reason
>> # (like no NIS server responding) then the search continues with the
>> # next entry.
>> #
>> # Legal entries are:
>> #
>> #       nisplus or nis+         Use NIS+ (NIS version 3)
>> #       nis or yp               Use NIS (NIS version 2), also called YP
>> #       dns                     Use DNS (Domain Name Service)
>> #       files                   Use the local files
>> #       db                      Use the local database (.db) files
>> #       compat                  Use NIS on compat mode
>> #       hesiod                  Use Hesiod for user lookups
>> #       [NOTFOUND=return]       Stop searching if not found so far
>> #
>>
>> # To use db, put the "db" in front of "files" for entries you want to be
>> # looked up first in the databases
>> #
>> # Example:
>> #passwd:    db files nisplus nis
>> #shadow:    db files nisplus nis
>> #group:     db files nisplus nis
>>
>> passwd:     files
>> shadow:     files
>> group:      files
>>
>> #hosts:     db files nisplus nis dns
>> hosts:      files dns
>>
>> # Example - obey only what nisplus tells us...
>> #services:   nisplus [NOTFOUND=return] files
>> #networks:   nisplus [NOTFOUND=return] files
>> #protocols:  nisplus [NOTFOUND=return] files
>> #rpc:        nisplus [NOTFOUND=return] files
>> #ethers:     nisplus [NOTFOUND=return] files
>> #netmasks:   nisplus [NOTFOUND=return] files
>>
>> bootparams: nisplus [NOTFOUND=return] files
>>
>> ethers:     files
>> netmasks:   files
>> networks:   files
>> protocols:  files
>> rpc:        files
>> services:   files
>>
>> netgroup:   files
>>
>> publickey:  nisplus
>>
>> automount:  files
>> aliases:    files nisplus
>>
>> lroom# cat /etc/sysconfig/autofs
>> #
>> # Define default options for autofs.
>> #
>> # MASTER_MAP_NAME - default map name for the master map.
>> #
>> #MASTER_MAP_NAME="auto.master"
>> #
>> # TIMEOUT - set the default mount timeout (default 600).
>> #
>> TIMEOUT=300
>> #
>> # BROWSE_MODE - maps are browsable by default.
>> #
>> BROWSE_MODE="no"
>> #
>> # APPEND_OPTIONS - append to global options instead of replace.
>> #
>> #APPEND_OPTIONS="yes"
>> #
>> # LOGGING - set default log level "none", "verbose" or "debug"
>> #
>> LOGGING="debug"
>> #
>> # Define the default LDAP schema to use for lookups
>> #
>> # System default
>> #
>> #MAP_OBJECT_CLASS="nisMap"
>> #ENTRY_OBJECT_CLASS="nisObject"
>> #MAP_ATTRIBUTE="nisMapName"
>> #ENTRY_ATTRIBUTE="cn"
>> #VALUE_ATTRIBUTE="nisMapEntry"
>> #
>> # Other common LDAP nameing
>> #
>> #MAP_OBJECT_CLASS="automountMap"
>> #ENTRY_OBJECT_CLASS="automount"
>> #MAP_ATTRIBUTE="ou"
>> #ENTRY_ATTRIBUTE="cn"
>> #VALUE_ATTRIBUTE="automountInformation"
>> #
>> #MAP_OBJECT_CLASS="automountMap"
>> #ENTRY_OBJECT_CLASS="automount"
>> #MAP_ATTRIBUTE="automountMapName"
>> #ENTRY_ATTRIBUTE="automountKey"
>> #VALUE_ATTRIBUTE="automountInformation"
>> #
>> # AUTH_CONF_FILE - set the default location for the SASL
>> #                          authentication configuration file.
>> #
>> #AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
>> #
>> # General global options
>> #
>> #OPTIONS=""
>> #
>>
>> The "linux" machine is the NFS server which provides the root file
>> system for the "lroom" and "gym" machines.  The /tftpboot/muekow/i386
>> directory is the root file system for the diskless machines, which is a
>> static hard mount setup during the early boot process.
>>
>> Here are the log files for the "lroom" machine which works properly.
>>
>> Jan  1 11:43:37 lroom automount[1968]: Starting automounter version
>> 5.0.1-31, master map auto.master
>> Jan  1 11:43:37 lroom automount[1968]: using kernel protocol version 5.00
>> Jan  1 11:43:37 linux mountd[2130]: authenticated unmount request from
>> lroom:915 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>> Jan  1 11:44:12 linux mountd[2130]: authenticated unmount request from
>> lroom:637 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>> Jan  1 11:44:12 lroom automount[1968]: mounted indirect mount on
>> /mnt/usb with timeout 2, freq 1 seconds
>> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
>> /mnt/usb/DCIM
>> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/DCIM
>> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
>> /mnt/usb/dcim
>> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/dcim
>> Jan  1 11:45:17 lroom xinetd[1820]: START: telnet pid=2280
>> from=192.168.1.254
>>
>> Here are the log files for the "gym" machine which fails to start
>> automount properly.  The automount program is in the hung state at this
>> point.
>>
>> Jan  1 11:49:36 gym automount[1846]: Starting automounter version
>> 5.0.1-31, master map auto.master
>> Jan  1 11:49:36 gym automount[1846]: using kernel protocol version 5.00
>> Jan  1 11:49:36 linux mountd[2130]: authenticated unmount request from
>> gym:778 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>>
>>
>> I realized today that the machines which fail to work are P3 processors
>> whereas the one that works is a P4 processor.  I don't know if that has
>> meaning or is a pure coincidence.
>>
>> Thanks for the help.
>>
>> Jim
>>
>>
>>
>>
>>
>> Ian Kent wrote:
>> > On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
>> >> I'm attempting to use autofs on some diskless machines which operate
>> >> using an NFS mounted root file system.  I have three different computers
>> >> which share the same root file system (with unique /tmp and /var
>> >> directories) and the same 2.6.22 kernel.
>> >>
>> >> I want to use autofs for removable USB memory sticks.
>> >>
>> >> On one machine, I can use autofs just fine.  Autofs mounts and unmounts
>> >> the usb sticks as I expect it to.  Works nice.
>> >>
>> >> However, on the other two machines, I cannot get automount to start.  It
>> >> simply hangs upon startup, I cannot ^C to exit or anything.  I have to
>> >> kill -9 the process.
>> >>
>> >> I cannot figure out what automount is looking for, and not getting,
>> >> which would cause it to hang.  I've attempted to use gdb to help me find
>> >> the problem, but I haven't had much luck.  (I've downloaded the most
>> >> recent 5.0.2 tar bar and build automount with -g to debug.
>> >
>> > Did you apply any of the patches for 5.0.2?
>> >
>> >> I'm hoping someone might shed some light on how best to debug this issue.
>> >
>> > Have a look at http://people.redhat.com/jmoyer for what to collect and
>> > post here.
>> >
>> > Ian
>>
>> _______________________________________________
>> autofs mailing list
>> autofs@linux.kernel.org
>> http://linux.kernel.org/mailman/listinfo/autofs 

Re: automount won't start - just hangs

[Ian Kent]

On Wed, 2008-01-02 at 13:53 -0500, Jim Duda wrote:
> My syslog.conf has this:
> *.* @192.168.1.254
> Doesn't that cover "everything", including daemon?

You'd think so.
All I can say is that the log is missing a bunch of info so there's
something not right.

> 
> No core dumps.
> 
> I started using gdb to find where the program was hanging.  I was down deep into reading the nisswitch.conf file, then 
> got lost.

If you can get into gdb when autofs is wedged then how about just doing:

info threads

and

thr a a bt

> 
> Jim
> 
> 
> "Ian Kent" <raven@themaw.net> wrote in message news:1199238944.3072.10.camel@raven.themaw.net...
> > On Tue, 2008-01-01 at 11:54 -0500, Jim Duda wrote:
> >> I have gathered the information required in this post.  I have provided
> >> the common information for machines which work and fail.  I have
> >> provided the syslog debug message for those that work and also those
> >> that fail.
> >
> > This all looks OK but the debug log doesn't have the debugging info.
> > Did you set syslog to send daemon.* to the log?
> >
> > I'm not sure we'll get much more from it but we should at least have a
> > look at it.
> >
> > Do you get any core files for automount?
> >
> >>
> >> lroom# rpm -q autofs
> >> autofs-5.0.1-31
> >>
> >> lroom# uname -a
> >> Linux lroom 2.6.22.2-tftp #1 Sun Aug 12 11:14:47 EDT 2007 i686 i686 i386
> >> GNU/Linux
> >>
> >>
> >> lroom# cat /etc/auto.master
> >> #
> >> # Sample auto.master file
> >> # This is an automounter map and it has the following format
> >> # key [ -mount-options-separated-by-comma ] location
> >> # For details of the format look at autofs(5).
> >> #
> >> #/misc  /etc/auto.misc
> >> #/net   -hosts
> >> /mnt/usb /etc/auto.usb --timeout=2
> >> #
> >> # Include central master map if it can be found using
> >> # nsswitch sources.
> >> #
> >> # Note that if there are entries for /net or /misc (as
> >> # above) in the included master map any keys that are the
> >> # same will not be seen as the first read key seen takes
> >> # precedence.
> >> #
> >> #+auto.master
> >>
> >> lroom# cat /etc/auto.usb
> >> device_a         -fstype=vfat,rw,gid=100,umask=002       :/dev/sda1
> >> device_b         -fstype=vfat,rw,gid=100,umask=002       :/dev/sdb1
> >>
> >> lroom# cat /etc/nsswitch.conf
> >> #
> >> # /etc/nsswitch.conf
> >> #
> >> # An example Name Service Switch config file. This file should be
> >> # sorted with the most-used services at the beginning.
> >> #
> >> # The entry '[NOTFOUND=return]' means that the search for an
> >> # entry should stop if the search in the previous entry turned
> >> # up nothing. Note that if the search failed due to some other reason
> >> # (like no NIS server responding) then the search continues with the
> >> # next entry.
> >> #
> >> # Legal entries are:
> >> #
> >> #       nisplus or nis+         Use NIS+ (NIS version 3)
> >> #       nis or yp               Use NIS (NIS version 2), also called YP
> >> #       dns                     Use DNS (Domain Name Service)
> >> #       files                   Use the local files
> >> #       db                      Use the local database (.db) files
> >> #       compat                  Use NIS on compat mode
> >> #       hesiod                  Use Hesiod for user lookups
> >> #       [NOTFOUND=return]       Stop searching if not found so far
> >> #
> >>
> >> # To use db, put the "db" in front of "files" for entries you want to be
> >> # looked up first in the databases
> >> #
> >> # Example:
> >> #passwd:    db files nisplus nis
> >> #shadow:    db files nisplus nis
> >> #group:     db files nisplus nis
> >>
> >> passwd:     files
> >> shadow:     files
> >> group:      files
> >>
> >> #hosts:     db files nisplus nis dns
> >> hosts:      files dns
> >>
> >> # Example - obey only what nisplus tells us...
> >> #services:   nisplus [NOTFOUND=return] files
> >> #networks:   nisplus [NOTFOUND=return] files
> >> #protocols:  nisplus [NOTFOUND=return] files
> >> #rpc:        nisplus [NOTFOUND=return] files
> >> #ethers:     nisplus [NOTFOUND=return] files
> >> #netmasks:   nisplus [NOTFOUND=return] files
> >>
> >> bootparams: nisplus [NOTFOUND=return] files
> >>
> >> ethers:     files
> >> netmasks:   files
> >> networks:   files
> >> protocols:  files
> >> rpc:        files
> >> services:   files
> >>
> >> netgroup:   files
> >>
> >> publickey:  nisplus
> >>
> >> automount:  files
> >> aliases:    files nisplus
> >>
> >> lroom# cat /etc/sysconfig/autofs
> >> #
> >> # Define default options for autofs.
> >> #
> >> # MASTER_MAP_NAME - default map name for the master map.
> >> #
> >> #MASTER_MAP_NAME="auto.master"
> >> #
> >> # TIMEOUT - set the default mount timeout (default 600).
> >> #
> >> TIMEOUT=300
> >> #
> >> # BROWSE_MODE - maps are browsable by default.
> >> #
> >> BROWSE_MODE="no"
> >> #
> >> # APPEND_OPTIONS - append to global options instead of replace.
> >> #
> >> #APPEND_OPTIONS="yes"
> >> #
> >> # LOGGING - set default log level "none", "verbose" or "debug"
> >> #
> >> LOGGING="debug"
> >> #
> >> # Define the default LDAP schema to use for lookups
> >> #
> >> # System default
> >> #
> >> #MAP_OBJECT_CLASS="nisMap"
> >> #ENTRY_OBJECT_CLASS="nisObject"
> >> #MAP_ATTRIBUTE="nisMapName"
> >> #ENTRY_ATTRIBUTE="cn"
> >> #VALUE_ATTRIBUTE="nisMapEntry"
> >> #
> >> # Other common LDAP nameing
> >> #
> >> #MAP_OBJECT_CLASS="automountMap"
> >> #ENTRY_OBJECT_CLASS="automount"
> >> #MAP_ATTRIBUTE="ou"
> >> #ENTRY_ATTRIBUTE="cn"
> >> #VALUE_ATTRIBUTE="automountInformation"
> >> #
> >> #MAP_OBJECT_CLASS="automountMap"
> >> #ENTRY_OBJECT_CLASS="automount"
> >> #MAP_ATTRIBUTE="automountMapName"
> >> #ENTRY_ATTRIBUTE="automountKey"
> >> #VALUE_ATTRIBUTE="automountInformation"
> >> #
> >> # AUTH_CONF_FILE - set the default location for the SASL
> >> #                          authentication configuration file.
> >> #
> >> #AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
> >> #
> >> # General global options
> >> #
> >> #OPTIONS=""
> >> #
> >>
> >> The "linux" machine is the NFS server which provides the root file
> >> system for the "lroom" and "gym" machines.  The /tftpboot/muekow/i386
> >> directory is the root file system for the diskless machines, which is a
> >> static hard mount setup during the early boot process.
> >>
> >> Here are the log files for the "lroom" machine which works properly.
> >>
> >> Jan  1 11:43:37 lroom automount[1968]: Starting automounter version
> >> 5.0.1-31, master map auto.master
> >> Jan  1 11:43:37 lroom automount[1968]: using kernel protocol version 5.00
> >> Jan  1 11:43:37 linux mountd[2130]: authenticated unmount request from
> >> lroom:915 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> >> Jan  1 11:44:12 linux mountd[2130]: authenticated unmount request from
> >> lroom:637 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> >> Jan  1 11:44:12 lroom automount[1968]: mounted indirect mount on
> >> /mnt/usb with timeout 2, freq 1 seconds
> >> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
> >> /mnt/usb/DCIM
> >> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/DCIM
> >> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
> >> /mnt/usb/dcim
> >> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/dcim
> >> Jan  1 11:45:17 lroom xinetd[1820]: START: telnet pid=2280
> >> from=192.168.1.254
> >>
> >> Here are the log files for the "gym" machine which fails to start
> >> automount properly.  The automount program is in the hung state at this
> >> point.
> >>
> >> Jan  1 11:49:36 gym automount[1846]: Starting automounter version
> >> 5.0.1-31, master map auto.master
> >> Jan  1 11:49:36 gym automount[1846]: using kernel protocol version 5.00
> >> Jan  1 11:49:36 linux mountd[2130]: authenticated unmount request from
> >> gym:778 for /tftpboot/muekow/i386 (/tftpboot/muekow)
> >>
> >>
> >> I realized today that the machines which fail to work are P3 processors
> >> whereas the one that works is a P4 processor.  I don't know if that has
> >> meaning or is a pure coincidence.
> >>
> >> Thanks for the help.
> >>
> >> Jim
> >>
> >>
> >>
> >>
> >>
> >> Ian Kent wrote:
> >> > On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
> >> >> I'm attempting to use autofs on some diskless machines which operate
> >> >> using an NFS mounted root file system.  I have three different computers
> >> >> which share the same root file system (with unique /tmp and /var
> >> >> directories) and the same 2.6.22 kernel.
> >> >>
> >> >> I want to use autofs for removable USB memory sticks.
> >> >>
> >> >> On one machine, I can use autofs just fine.  Autofs mounts and unmounts
> >> >> the usb sticks as I expect it to.  Works nice.
> >> >>
> >> >> However, on the other two machines, I cannot get automount to start.  It
> >> >> simply hangs upon startup, I cannot ^C to exit or anything.  I have to
> >> >> kill -9 the process.
> >> >>
> >> >> I cannot figure out what automount is looking for, and not getting,
> >> >> which would cause it to hang.  I've attempted to use gdb to help me find
> >> >> the problem, but I haven't had much luck.  (I've downloaded the most
> >> >> recent 5.0.2 tar bar and build automount with -g to debug.
> >> >
> >> > Did you apply any of the patches for 5.0.2?
> >> >
> >> >> I'm hoping someone might shed some light on how best to debug this issue.
> >> >
> >> > Have a look at http://people.redhat.com/jmoyer for what to collect and
> >> > post here.
> >> >
> >> > 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

Re: automount won't start - just hangs

[Jim Duda]

Ian,

Adding *.daemon simply resulted in the same information being dumped to 
the syslog file, however, twice.  So, no new information.

Once automount gets wedged, I cannot use gdb to interrogate the threads, 
I cannot break into the program after it's wedged.

I'm by no means a power gdb user.

I did:

set detach-on-fork off, simply based on a recommended help from ddd.

I traced the program all the way down into mount_bind.c, in the 
mount_init function, then into spawn.c, where it did the first fork. 
The program was wedged in spawn.c on line 186 at the first do while loop 
after the fork.

The program though do_read_master, mod->lookup_int, then into open_mount 
for "nfs" before it got to the first spawn.

I don't know how helpful any of this information is for you in helping 
me determine what is different about my funky root file system which 
causes a lockup, but thanks for trying.

Again, one machine works fine while two others get wedged.

Jim

Ian Kent wrote:
> On Wed, 2008-01-02 at 13:53 -0500, Jim Duda wrote:
>> My syslog.conf has this:
>> *.* @192.168.1.254
>> Doesn't that cover "everything", including daemon?
> 
> You'd think so.
> All I can say is that the log is missing a bunch of info so there's
> something not right.
> 
>> No core dumps.
>>
>> I started using gdb to find where the program was hanging.  I was down deep into reading the nisswitch.conf file, then 
>> got lost.
> 
> If you can get into gdb when autofs is wedged then how about just doing:
> 
> info threads
> 
> and
> 
> thr a a bt
> 
>> Jim
>>
>>
>> "Ian Kent" <raven@themaw.net> wrote in message news:1199238944.3072.10.camel@raven.themaw.net...
>>> On Tue, 2008-01-01 at 11:54 -0500, Jim Duda wrote:
>>>> I have gathered the information required in this post.  I have provided
>>>> the common information for machines which work and fail.  I have
>>>> provided the syslog debug message for those that work and also those
>>>> that fail.
>>> This all looks OK but the debug log doesn't have the debugging info.
>>> Did you set syslog to send daemon.* to the log?
>>>
>>> I'm not sure we'll get much more from it but we should at least have a
>>> look at it.
>>>
>>> Do you get any core files for automount?
>>>
>>>> lroom# rpm -q autofs
>>>> autofs-5.0.1-31
>>>>
>>>> lroom# uname -a
>>>> Linux lroom 2.6.22.2-tftp #1 Sun Aug 12 11:14:47 EDT 2007 i686 i686 i386
>>>> GNU/Linux
>>>>
>>>>
>>>> lroom# cat /etc/auto.master
>>>> #
>>>> # Sample auto.master file
>>>> # This is an automounter map and it has the following format
>>>> # key [ -mount-options-separated-by-comma ] location
>>>> # For details of the format look at autofs(5).
>>>> #
>>>> #/misc  /etc/auto.misc
>>>> #/net   -hosts
>>>> /mnt/usb /etc/auto.usb --timeout=2
>>>> #
>>>> # Include central master map if it can be found using
>>>> # nsswitch sources.
>>>> #
>>>> # Note that if there are entries for /net or /misc (as
>>>> # above) in the included master map any keys that are the
>>>> # same will not be seen as the first read key seen takes
>>>> # precedence.
>>>> #
>>>> #+auto.master
>>>>
>>>> lroom# cat /etc/auto.usb
>>>> device_a         -fstype=vfat,rw,gid=100,umask=002       :/dev/sda1
>>>> device_b         -fstype=vfat,rw,gid=100,umask=002       :/dev/sdb1
>>>>
>>>> lroom# cat /etc/nsswitch.conf
>>>> #
>>>> # /etc/nsswitch.conf
>>>> #
>>>> # An example Name Service Switch config file. This file should be
>>>> # sorted with the most-used services at the beginning.
>>>> #
>>>> # The entry '[NOTFOUND=return]' means that the search for an
>>>> # entry should stop if the search in the previous entry turned
>>>> # up nothing. Note that if the search failed due to some other reason
>>>> # (like no NIS server responding) then the search continues with the
>>>> # next entry.
>>>> #
>>>> # Legal entries are:
>>>> #
>>>> #       nisplus or nis+         Use NIS+ (NIS version 3)
>>>> #       nis or yp               Use NIS (NIS version 2), also called YP
>>>> #       dns                     Use DNS (Domain Name Service)
>>>> #       files                   Use the local files
>>>> #       db                      Use the local database (.db) files
>>>> #       compat                  Use NIS on compat mode
>>>> #       hesiod                  Use Hesiod for user lookups
>>>> #       [NOTFOUND=return]       Stop searching if not found so far
>>>> #
>>>>
>>>> # To use db, put the "db" in front of "files" for entries you want to be
>>>> # looked up first in the databases
>>>> #
>>>> # Example:
>>>> #passwd:    db files nisplus nis
>>>> #shadow:    db files nisplus nis
>>>> #group:     db files nisplus nis
>>>>
>>>> passwd:     files
>>>> shadow:     files
>>>> group:      files
>>>>
>>>> #hosts:     db files nisplus nis dns
>>>> hosts:      files dns
>>>>
>>>> # Example - obey only what nisplus tells us...
>>>> #services:   nisplus [NOTFOUND=return] files
>>>> #networks:   nisplus [NOTFOUND=return] files
>>>> #protocols:  nisplus [NOTFOUND=return] files
>>>> #rpc:        nisplus [NOTFOUND=return] files
>>>> #ethers:     nisplus [NOTFOUND=return] files
>>>> #netmasks:   nisplus [NOTFOUND=return] files
>>>>
>>>> bootparams: nisplus [NOTFOUND=return] files
>>>>
>>>> ethers:     files
>>>> netmasks:   files
>>>> networks:   files
>>>> protocols:  files
>>>> rpc:        files
>>>> services:   files
>>>>
>>>> netgroup:   files
>>>>
>>>> publickey:  nisplus
>>>>
>>>> automount:  files
>>>> aliases:    files nisplus
>>>>
>>>> lroom# cat /etc/sysconfig/autofs
>>>> #
>>>> # Define default options for autofs.
>>>> #
>>>> # MASTER_MAP_NAME - default map name for the master map.
>>>> #
>>>> #MASTER_MAP_NAME="auto.master"
>>>> #
>>>> # TIMEOUT - set the default mount timeout (default 600).
>>>> #
>>>> TIMEOUT=300
>>>> #
>>>> # BROWSE_MODE - maps are browsable by default.
>>>> #
>>>> BROWSE_MODE="no"
>>>> #
>>>> # APPEND_OPTIONS - append to global options instead of replace.
>>>> #
>>>> #APPEND_OPTIONS="yes"
>>>> #
>>>> # LOGGING - set default log level "none", "verbose" or "debug"
>>>> #
>>>> LOGGING="debug"
>>>> #
>>>> # Define the default LDAP schema to use for lookups
>>>> #
>>>> # System default
>>>> #
>>>> #MAP_OBJECT_CLASS="nisMap"
>>>> #ENTRY_OBJECT_CLASS="nisObject"
>>>> #MAP_ATTRIBUTE="nisMapName"
>>>> #ENTRY_ATTRIBUTE="cn"
>>>> #VALUE_ATTRIBUTE="nisMapEntry"
>>>> #
>>>> # Other common LDAP nameing
>>>> #
>>>> #MAP_OBJECT_CLASS="automountMap"
>>>> #ENTRY_OBJECT_CLASS="automount"
>>>> #MAP_ATTRIBUTE="ou"
>>>> #ENTRY_ATTRIBUTE="cn"
>>>> #VALUE_ATTRIBUTE="automountInformation"
>>>> #
>>>> #MAP_OBJECT_CLASS="automountMap"
>>>> #ENTRY_OBJECT_CLASS="automount"
>>>> #MAP_ATTRIBUTE="automountMapName"
>>>> #ENTRY_ATTRIBUTE="automountKey"
>>>> #VALUE_ATTRIBUTE="automountInformation"
>>>> #
>>>> # AUTH_CONF_FILE - set the default location for the SASL
>>>> #                          authentication configuration file.
>>>> #
>>>> #AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
>>>> #
>>>> # General global options
>>>> #
>>>> #OPTIONS=""
>>>> #
>>>>
>>>> The "linux" machine is the NFS server which provides the root file
>>>> system for the "lroom" and "gym" machines.  The /tftpboot/muekow/i386
>>>> directory is the root file system for the diskless machines, which is a
>>>> static hard mount setup during the early boot process.
>>>>
>>>> Here are the log files for the "lroom" machine which works properly.
>>>>
>>>> Jan  1 11:43:37 lroom automount[1968]: Starting automounter version
>>>> 5.0.1-31, master map auto.master
>>>> Jan  1 11:43:37 lroom automount[1968]: using kernel protocol version 5.00
>>>> Jan  1 11:43:37 linux mountd[2130]: authenticated unmount request from
>>>> lroom:915 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>>>> Jan  1 11:44:12 linux mountd[2130]: authenticated unmount request from
>>>> lroom:637 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>>>> Jan  1 11:44:12 lroom automount[1968]: mounted indirect mount on
>>>> /mnt/usb with timeout 2, freq 1 seconds
>>>> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
>>>> /mnt/usb/DCIM
>>>> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/DCIM
>>>> Jan  1 11:45:06 lroom automount[1968]: attempting to mount entry
>>>> /mnt/usb/dcim
>>>> Jan  1 11:45:06 lroom automount[1968]: failed to mount /mnt/usb/dcim
>>>> Jan  1 11:45:17 lroom xinetd[1820]: START: telnet pid=2280
>>>> from=192.168.1.254
>>>>
>>>> Here are the log files for the "gym" machine which fails to start
>>>> automount properly.  The automount program is in the hung state at this
>>>> point.
>>>>
>>>> Jan  1 11:49:36 gym automount[1846]: Starting automounter version
>>>> 5.0.1-31, master map auto.master
>>>> Jan  1 11:49:36 gym automount[1846]: using kernel protocol version 5.00
>>>> Jan  1 11:49:36 linux mountd[2130]: authenticated unmount request from
>>>> gym:778 for /tftpboot/muekow/i386 (/tftpboot/muekow)
>>>>
>>>>
>>>> I realized today that the machines which fail to work are P3 processors
>>>> whereas the one that works is a P4 processor.  I don't know if that has
>>>> meaning or is a pure coincidence.
>>>>
>>>> Thanks for the help.
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ian Kent wrote:
>>>>> On Mon, 2007-12-31 at 17:03 -0500, Jim Duda wrote:
>>>>>> I'm attempting to use autofs on some diskless machines which operate
>>>>>> using an NFS mounted root file system.  I have three different computers
>>>>>> which share the same root file system (with unique /tmp and /var
>>>>>> directories) and the same 2.6.22 kernel.
>>>>>>
>>>>>> I want to use autofs for removable USB memory sticks.
>>>>>>
>>>>>> On one machine, I can use autofs just fine.  Autofs mounts and unmounts
>>>>>> the usb sticks as I expect it to.  Works nice.
>>>>>>
>>>>>> However, on the other two machines, I cannot get automount to start.  It
>>>>>> simply hangs upon startup, I cannot ^C to exit or anything.  I have to
>>>>>> kill -9 the process.
>>>>>>
>>>>>> I cannot figure out what automount is looking for, and not getting,
>>>>>> which would cause it to hang.  I've attempted to use gdb to help me find
>>>>>> the problem, but I haven't had much luck.  (I've downloaded the most
>>>>>> recent 5.0.2 tar bar and build automount with -g to debug.
>>>>> Did you apply any of the patches for 5.0.2?
>>>>>
>>>>>> I'm hoping someone might shed some light on how best to debug this issue.
>>>>> Have a look at http://people.redhat.com/jmoyer for what to collect and
>>>>> post here.
>>>>>
>>>>> 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

Re: automount won't start - just hangs

[Ian Kent]

On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> Ian,
> 
> Adding *.daemon simply resulted in the same information being dumped to 
> the syslog file, however, twice.  So, no new information.

That should be daemon.* and usually you would log it to a different file
when adding a syslog entry like that but I don't think that will make
any difference.

I can't remember how logging to a syslog server works now but does the
syslog configuration on the server also limit what is logged?

> 
> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
> I cannot break into the program after it's wedged.
> 
> I'm by no means a power gdb user.

Me nether.

> 
> I did:
> 
> set detach-on-fork off, simply based on a recommended help from ddd.
> 
> I traced the program all the way down into mount_bind.c, in the 
> mount_init function, then into spawn.c, where it did the first fork. 
> The program was wedged in spawn.c on line 186 at the first do while loop 
> after the fork.
> 
> The program though do_read_master, mod->lookup_int, then into open_mount 
> for "nfs" before it got to the first spawn.
> 
> I don't know how helpful any of this information is for you in helping 
> me determine what is different about my funky root file system which 
> causes a lockup, but thanks for trying.

I'm not sure either but one thing is sure, problems are almost always
different from what you think they are when you finally get hard
evidence.

In autofs-5.0.1-31, line 186 corresponds to an if statement?

How about we try getting rid of a recent patch to this area of the code
and rebuild autofs and see if that helps. The one I have in mind is
close to the chopping block already.

In particular:

[raven@raven F-7]$ cvs diff -u autofs.spec 
Index: autofs.spec
===================================================================
RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
retrieving revision 1.221
diff -u -r1.221 autofs.spec
--- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
+++ autofs.spec 4 Jan 2008 02:20:20 -0000
@@ -127,7 +127,7 @@
 %patch35 -p1
 %patch36 -p1
 %patch37 -p1
-%patch38 -p1
+#%patch38 -p1
 %patch39 -p1
 
 %build

Re: automount won't start - just hangs

[Jim Duda]

Ian,

I do have daemon.*, I got it backwards in the last post.

I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?

Jim

Ian Kent wrote:
> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
>> Ian,
>>
>> Adding *.daemon simply resulted in the same information being dumped to 
>> the syslog file, however, twice.  So, no new information.
> 
> That should be daemon.* and usually you would log it to a different file
> when adding a syslog entry like that but I don't think that will make
> any difference.
> 
> I can't remember how logging to a syslog server works now but does the
> syslog configuration on the server also limit what is logged?
> 
>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
>> I cannot break into the program after it's wedged.
>>
>> I'm by no means a power gdb user.
> 
> Me nether.
> 
>> I did:
>>
>> set detach-on-fork off, simply based on a recommended help from ddd.
>>
>> I traced the program all the way down into mount_bind.c, in the 
>> mount_init function, then into spawn.c, where it did the first fork. 
>> The program was wedged in spawn.c on line 186 at the first do while loop 
>> after the fork.
>>
>> The program though do_read_master, mod->lookup_int, then into open_mount 
>> for "nfs" before it got to the first spawn.
>>
>> I don't know how helpful any of this information is for you in helping 
>> me determine what is different about my funky root file system which 
>> causes a lockup, but thanks for trying.
> 
> I'm not sure either but one thing is sure, problems are almost always
> different from what you think they are when you finally get hard
> evidence.
> 
> In autofs-5.0.1-31, line 186 corresponds to an if statement?
> 
> How about we try getting rid of a recent patch to this area of the code
> and rebuild autofs and see if that helps. The one I have in mind is
> close to the chopping block already.
> 
> In particular:
> 
> [raven@raven F-7]$ cvs diff -u autofs.spec 
> Index: autofs.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> retrieving revision 1.221
> diff -u -r1.221 autofs.spec
> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> @@ -127,7 +127,7 @@
>  %patch35 -p1
>  %patch36 -p1
>  %patch37 -p1
> -%patch38 -p1
> +#%patch38 -p1
>  %patch39 -p1
>  
>  %build

Re: automount won't start - just hangs

[Jim Duda]

Ian,

Here in spawn.c

		errp = 0;
		do {
			while ((errn =
				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
			       && errno == EINTR);


Jim Duda wrote:
> Ian,
> 
> I do have daemon.*, I got it backwards in the last post.
> 
> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
> 
> Jim
> 
> Ian Kent wrote:
>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
>>> Ian,
>>>
>>> Adding *.daemon simply resulted in the same information being dumped to 
>>> the syslog file, however, twice.  So, no new information.
>> That should be daemon.* and usually you would log it to a different file
>> when adding a syslog entry like that but I don't think that will make
>> any difference.
>>
>> I can't remember how logging to a syslog server works now but does the
>> syslog configuration on the server also limit what is logged?
>>
>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
>>> I cannot break into the program after it's wedged.
>>>
>>> I'm by no means a power gdb user.
>> Me nether.
>>
>>> I did:
>>>
>>> set detach-on-fork off, simply based on a recommended help from ddd.
>>>
>>> I traced the program all the way down into mount_bind.c, in the 
>>> mount_init function, then into spawn.c, where it did the first fork. 
>>> The program was wedged in spawn.c on line 186 at the first do while loop 
>>> after the fork.
>>>
>>> The program though do_read_master, mod->lookup_int, then into open_mount 
>>> for "nfs" before it got to the first spawn.
>>>
>>> I don't know how helpful any of this information is for you in helping 
>>> me determine what is different about my funky root file system which 
>>> causes a lockup, but thanks for trying.
>> I'm not sure either but one thing is sure, problems are almost always
>> different from what you think they are when you finally get hard
>> evidence.
>>
>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
>>
>> How about we try getting rid of a recent patch to this area of the code
>> and rebuild autofs and see if that helps. The one I have in mind is
>> close to the chopping block already.
>>
>> In particular:
>>
>> [raven@raven F-7]$ cvs diff -u autofs.spec 
>> Index: autofs.spec
>> ===================================================================
>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
>> retrieving revision 1.221
>> diff -u -r1.221 autofs.spec
>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
>> @@ -127,7 +127,7 @@
>>  %patch35 -p1
>>  %patch36 -p1
>>  %patch37 -p1
>> -%patch38 -p1
>> +#%patch38 -p1
>>  %patch39 -p1
>>  
>>  %build

Re: automount won't start - just hangs

[Ian Kent]

On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
> Ian,
> 
> Here in spawn.c
> 
> 		errp = 0;
> 		do {
> 			while ((errn =
> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
> 			       && errno == EINTR);

I'm not sure this really says much except that autofs is waiting for
mount(8) (or umount(8) as the case may be) to complete.

Usually you will see a mount process running if mount isn't completing,
in which case, it becomes a matter of working out why mount can't
complete the mount. If we were logging debug info then usually we would
be able to get the mount command used which is often helpful. OTOH, if
there isn't any process (either mount or another automount process) then
perhaps mount has seg faulted and autofs is waiting for a reply but,
usually, if that happens the daemon gets a signal and continues with
what looks like a successful mount which it often really isn't.

> 
> 
> Jim Duda wrote:
> > Ian,
> > 
> > I do have daemon.*, I got it backwards in the last post.
> > 
> > I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
> > 
> > Jim
> > 
> > Ian Kent wrote:
> >> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> >>> Ian,
> >>>
> >>> Adding *.daemon simply resulted in the same information being dumped to 
> >>> the syslog file, however, twice.  So, no new information.
> >> That should be daemon.* and usually you would log it to a different file
> >> when adding a syslog entry like that but I don't think that will make
> >> any difference.
> >>
> >> I can't remember how logging to a syslog server works now but does the
> >> syslog configuration on the server also limit what is logged?
> >>
> >>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
> >>> I cannot break into the program after it's wedged.

I haven't seen that behavior before and I've debugged some really broken
code in the early version 5 development. Perhaps this is something other
than just autofs?

> >>>
> >>> I'm by no means a power gdb user.
> >> Me nether.
> >>
> >>> I did:
> >>>
> >>> set detach-on-fork off, simply based on a recommended help from ddd.
> >>>
> >>> I traced the program all the way down into mount_bind.c, in the 
> >>> mount_init function, then into spawn.c, where it did the first fork. 
> >>> The program was wedged in spawn.c on line 186 at the first do while loop 
> >>> after the fork.
> >>>
> >>> The program though do_read_master, mod->lookup_int, then into open_mount 
> >>> for "nfs" before it got to the first spawn.
> >>>
> >>> I don't know how helpful any of this information is for you in helping 
> >>> me determine what is different about my funky root file system which 
> >>> causes a lockup, but thanks for trying.
> >> I'm not sure either but one thing is sure, problems are almost always
> >> different from what you think they are when you finally get hard
> >> evidence.
> >>
> >> In autofs-5.0.1-31, line 186 corresponds to an if statement?
> >>
> >> How about we try getting rid of a recent patch to this area of the code
> >> and rebuild autofs and see if that helps. The one I have in mind is
> >> close to the chopping block already.
> >>
> >> In particular:
> >>
> >> [raven@raven F-7]$ cvs diff -u autofs.spec 
> >> Index: autofs.spec
> >> ===================================================================
> >> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> >> retrieving revision 1.221
> >> diff -u -r1.221 autofs.spec
> >> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
> >> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> >> @@ -127,7 +127,7 @@
> >>  %patch35 -p1
> >>  %patch36 -p1
> >>  %patch37 -p1
> >> -%patch38 -p1
> >> +#%patch38 -p1
> >>  %patch39 -p1
> >>  
> >>  %build
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: automount won't start - just hangs

[Jim Duda]

Ian,

On the machine that don't work properly, I get this from showmount.

asterisk> showmount
Broken pipe

Does that mean anything to you?

Note that in my auto.master file, I have /net commented out ...

Jim

Ian Kent wrote:
> On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
>> Ian,
>>
>> Here in spawn.c
>>
>> 		errp = 0;
>> 		do {
>> 			while ((errn =
>> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
>> 			       && errno == EINTR);
> 
> I'm not sure this really says much except that autofs is waiting for
> mount(8) (or umount(8) as the case may be) to complete.
> 
> Usually you will see a mount process running if mount isn't completing,
> in which case, it becomes a matter of working out why mount can't
> complete the mount. If we were logging debug info then usually we would
> be able to get the mount command used which is often helpful. OTOH, if
> there isn't any process (either mount or another automount process) then
> perhaps mount has seg faulted and autofs is waiting for a reply but,
> usually, if that happens the daemon gets a signal and continues with
> what looks like a successful mount which it often really isn't.
> 
>>
>> Jim Duda wrote:
>>> Ian,
>>>
>>> I do have daemon.*, I got it backwards in the last post.
>>>
>>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
>>>
>>> Jim
>>>
>>> Ian Kent wrote:
>>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
>>>>> Ian,
>>>>>
>>>>> Adding *.daemon simply resulted in the same information being dumped to 
>>>>> the syslog file, however, twice.  So, no new information.
>>>> That should be daemon.* and usually you would log it to a different file
>>>> when adding a syslog entry like that but I don't think that will make
>>>> any difference.
>>>>
>>>> I can't remember how logging to a syslog server works now but does the
>>>> syslog configuration on the server also limit what is logged?
>>>>
>>>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
>>>>> I cannot break into the program after it's wedged.
> 
> I haven't seen that behavior before and I've debugged some really broken
> code in the early version 5 development. Perhaps this is something other
> than just autofs?
> 
>>>>> I'm by no means a power gdb user.
>>>> Me nether.
>>>>
>>>>> I did:
>>>>>
>>>>> set detach-on-fork off, simply based on a recommended help from ddd.
>>>>>
>>>>> I traced the program all the way down into mount_bind.c, in the 
>>>>> mount_init function, then into spawn.c, where it did the first fork. 
>>>>> The program was wedged in spawn.c on line 186 at the first do while loop 
>>>>> after the fork.
>>>>>
>>>>> The program though do_read_master, mod->lookup_int, then into open_mount 
>>>>> for "nfs" before it got to the first spawn.
>>>>>
>>>>> I don't know how helpful any of this information is for you in helping 
>>>>> me determine what is different about my funky root file system which 
>>>>> causes a lockup, but thanks for trying.
>>>> I'm not sure either but one thing is sure, problems are almost always
>>>> different from what you think they are when you finally get hard
>>>> evidence.
>>>>
>>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
>>>>
>>>> How about we try getting rid of a recent patch to this area of the code
>>>> and rebuild autofs and see if that helps. The one I have in mind is
>>>> close to the chopping block already.
>>>>
>>>> In particular:
>>>>
>>>> [raven@raven F-7]$ cvs diff -u autofs.spec 
>>>> Index: autofs.spec
>>>> ===================================================================
>>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
>>>> retrieving revision 1.221
>>>> diff -u -r1.221 autofs.spec
>>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
>>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
>>>> @@ -127,7 +127,7 @@
>>>>  %patch35 -p1
>>>>  %patch36 -p1
>>>>  %patch37 -p1
>>>> -%patch38 -p1
>>>> +#%patch38 -p1
>>>>  %patch39 -p1
>>>>  
>>>>  %build
>> _______________________________________________
>> autofs mailing list
>> autofs@linux.kernel.org
>> http://linux.kernel.org/mailman/listinfo/autofs

Re: automount won't start - just hangs

[Ian Kent]

On Fri, 2008-01-04 at 21:46 -0500, Jim Duda wrote:
> Ian,
> 
> On the machine that don't work properly, I get this from showmount.
> 
> asterisk> showmount
> Broken pipe

That doesn't look very good.
It may be an indication that RPC is somehow not right on the machine.
I would expect output like (assuming the machine isn't actually being
used as an NFS server):
showmount: RPC: Program not registered

Maybe the problem is as simple as portmap or rpcbind not running on the
machine. But then I'd expect showmount to just return nothing.

> 
> Does that mean anything to you?
> 
> Note that in my auto.master file, I have /net commented out ...
> 
> Jim
> 
> Ian Kent wrote:
> > On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
> >> Ian,
> >>
> >> Here in spawn.c
> >>
> >> 		errp = 0;
> >> 		do {
> >> 			while ((errn =
> >> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
> >> 			       && errno == EINTR);
> > 
> > I'm not sure this really says much except that autofs is waiting for
> > mount(8) (or umount(8) as the case may be) to complete.
> > 
> > Usually you will see a mount process running if mount isn't completing,
> > in which case, it becomes a matter of working out why mount can't
> > complete the mount. If we were logging debug info then usually we would
> > be able to get the mount command used which is often helpful. OTOH, if
> > there isn't any process (either mount or another automount process) then
> > perhaps mount has seg faulted and autofs is waiting for a reply but,
> > usually, if that happens the daemon gets a signal and continues with
> > what looks like a successful mount which it often really isn't.
> > 
> >>
> >> Jim Duda wrote:
> >>> Ian,
> >>>
> >>> I do have daemon.*, I got it backwards in the last post.
> >>>
> >>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
> >>>
> >>> Jim
> >>>
> >>> Ian Kent wrote:
> >>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> >>>>> Ian,
> >>>>>
> >>>>> Adding *.daemon simply resulted in the same information being dumped to 
> >>>>> the syslog file, however, twice.  So, no new information.
> >>>> That should be daemon.* and usually you would log it to a different file
> >>>> when adding a syslog entry like that but I don't think that will make
> >>>> any difference.
> >>>>
> >>>> I can't remember how logging to a syslog server works now but does the
> >>>> syslog configuration on the server also limit what is logged?
> >>>>
> >>>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
> >>>>> I cannot break into the program after it's wedged.
> > 
> > I haven't seen that behavior before and I've debugged some really broken
> > code in the early version 5 development. Perhaps this is something other
> > than just autofs?
> > 
> >>>>> I'm by no means a power gdb user.
> >>>> Me nether.
> >>>>
> >>>>> I did:
> >>>>>
> >>>>> set detach-on-fork off, simply based on a recommended help from ddd.
> >>>>>
> >>>>> I traced the program all the way down into mount_bind.c, in the 
> >>>>> mount_init function, then into spawn.c, where it did the first fork. 
> >>>>> The program was wedged in spawn.c on line 186 at the first do while loop 
> >>>>> after the fork.
> >>>>>
> >>>>> The program though do_read_master, mod->lookup_int, then into open_mount 
> >>>>> for "nfs" before it got to the first spawn.
> >>>>>
> >>>>> I don't know how helpful any of this information is for you in helping 
> >>>>> me determine what is different about my funky root file system which 
> >>>>> causes a lockup, but thanks for trying.
> >>>> I'm not sure either but one thing is sure, problems are almost always
> >>>> different from what you think they are when you finally get hard
> >>>> evidence.
> >>>>
> >>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
> >>>>
> >>>> How about we try getting rid of a recent patch to this area of the code
> >>>> and rebuild autofs and see if that helps. The one I have in mind is
> >>>> close to the chopping block already.
> >>>>
> >>>> In particular:
> >>>>
> >>>> [raven@raven F-7]$ cvs diff -u autofs.spec 
> >>>> Index: autofs.spec
> >>>> ===================================================================
> >>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> >>>> retrieving revision 1.221
> >>>> diff -u -r1.221 autofs.spec
> >>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
> >>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> >>>> @@ -127,7 +127,7 @@
> >>>>  %patch35 -p1
> >>>>  %patch36 -p1
> >>>>  %patch37 -p1
> >>>> -%patch38 -p1
> >>>> +#%patch38 -p1
> >>>>  %patch39 -p1
> >>>>  
> >>>>  %build
> >> _______________________________________________
> >> autofs mailing list
> >> autofs@linux.kernel.org
> >> http://linux.kernel.org/mailman/listinfo/autofs
> 

Re: automount won't start - just hangs

[Jim Duda]

Ian,

I cannot explain why, but I wasn't able to get any debug message via 
SYSLOG, however, I found that by using msg(""), I was able to add my own 
debugging.

I finally figured out the root cause of the hang.  The program was 
blocked down inside replicate.d, at the read of /dev/random.

I have both /dev/random and /dev/urandom.

By simply replacing /dev/random with /dev/urandom in replicate.c, my 
hang problem was resolved and automount works just great.

Does that make any sense?

Jim

Ian Kent wrote:
> On Fri, 2008-01-04 at 21:46 -0500, Jim Duda wrote:
>> Ian,
>>
>> On the machine that don't work properly, I get this from showmount.
>>
>> asterisk> showmount
>> Broken pipe
> 
> That doesn't look very good.
> It may be an indication that RPC is somehow not right on the machine.
> I would expect output like (assuming the machine isn't actually being
> used as an NFS server):
> showmount: RPC: Program not registered
> 
> Maybe the problem is as simple as portmap or rpcbind not running on the
> machine. But then I'd expect showmount to just return nothing.
> 
>> Does that mean anything to you?
>>
>> Note that in my auto.master file, I have /net commented out ...
>>
>> Jim
>>
>> Ian Kent wrote:
>>> On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
>>>> Ian,
>>>>
>>>> Here in spawn.c
>>>>
>>>> 		errp = 0;
>>>> 		do {
>>>> 			while ((errn =
>>>> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
>>>> 			       && errno == EINTR);
>>> I'm not sure this really says much except that autofs is waiting for
>>> mount(8) (or umount(8) as the case may be) to complete.
>>>
>>> Usually you will see a mount process running if mount isn't completing,
>>> in which case, it becomes a matter of working out why mount can't
>>> complete the mount. If we were logging debug info then usually we would
>>> be able to get the mount command used which is often helpful. OTOH, if
>>> there isn't any process (either mount or another automount process) then
>>> perhaps mount has seg faulted and autofs is waiting for a reply but,
>>> usually, if that happens the daemon gets a signal and continues with
>>> what looks like a successful mount which it often really isn't.
>>>
>>>> Jim Duda wrote:
>>>>> Ian,
>>>>>
>>>>> I do have daemon.*, I got it backwards in the last post.
>>>>>
>>>>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
>>>>>
>>>>> Jim
>>>>>
>>>>> Ian Kent wrote:
>>>>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
>>>>>>> Ian,
>>>>>>>
>>>>>>> Adding *.daemon simply resulted in the same information being dumped to 
>>>>>>> the syslog file, however, twice.  So, no new information.
>>>>>> That should be daemon.* and usually you would log it to a different file
>>>>>> when adding a syslog entry like that but I don't think that will make
>>>>>> any difference.
>>>>>>
>>>>>> I can't remember how logging to a syslog server works now but does the
>>>>>> syslog configuration on the server also limit what is logged?
>>>>>>
>>>>>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
>>>>>>> I cannot break into the program after it's wedged.
>>> I haven't seen that behavior before and I've debugged some really broken
>>> code in the early version 5 development. Perhaps this is something other
>>> than just autofs?
>>>
>>>>>>> I'm by no means a power gdb user.
>>>>>> Me nether.
>>>>>>
>>>>>>> I did:
>>>>>>>
>>>>>>> set detach-on-fork off, simply based on a recommended help from ddd.
>>>>>>>
>>>>>>> I traced the program all the way down into mount_bind.c, in the 
>>>>>>> mount_init function, then into spawn.c, where it did the first fork. 
>>>>>>> The program was wedged in spawn.c on line 186 at the first do while loop 
>>>>>>> after the fork.
>>>>>>>
>>>>>>> The program though do_read_master, mod->lookup_int, then into open_mount 
>>>>>>> for "nfs" before it got to the first spawn.
>>>>>>>
>>>>>>> I don't know how helpful any of this information is for you in helping 
>>>>>>> me determine what is different about my funky root file system which 
>>>>>>> causes a lockup, but thanks for trying.
>>>>>> I'm not sure either but one thing is sure, problems are almost always
>>>>>> different from what you think they are when you finally get hard
>>>>>> evidence.
>>>>>>
>>>>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
>>>>>>
>>>>>> How about we try getting rid of a recent patch to this area of the code
>>>>>> and rebuild autofs and see if that helps. The one I have in mind is
>>>>>> close to the chopping block already.
>>>>>>
>>>>>> In particular:
>>>>>>
>>>>>> [raven@raven F-7]$ cvs diff -u autofs.spec 
>>>>>> Index: autofs.spec
>>>>>> ===================================================================
>>>>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
>>>>>> retrieving revision 1.221
>>>>>> diff -u -r1.221 autofs.spec
>>>>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
>>>>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
>>>>>> @@ -127,7 +127,7 @@
>>>>>>  %patch35 -p1
>>>>>>  %patch36 -p1
>>>>>>  %patch37 -p1
>>>>>> -%patch38 -p1
>>>>>> +#%patch38 -p1
>>>>>>  %patch39 -p1
>>>>>>  
>>>>>>  %build
>>>> _______________________________________________
>>>> autofs mailing list
>>>> autofs@linux.kernel.org
>>>> http://linux.kernel.org/mailman/listinfo/autofs

Re: automount won't start - just hangs

[Jim Duda]

Ian,

All of my NFS based root file system computers operate without mice or 
keyboards.  I read a few posts which claim that /dev/random might not 
provide any data on these type of machines.

In my rc.local, I have simply removed /dev/random and created a link 
from random to /dev/urandom.

Now everything works just fine!!

Thanks for all your patience on this thread.

Jim

Jim Duda wrote:
> Ian,
> 
> I cannot explain why, but I wasn't able to get any debug message via 
> SYSLOG, however, I found that by using msg(""), I was able to add my own 
> debugging.
> 
> I finally figured out the root cause of the hang.  The program was 
> blocked down inside replicate.d, at the read of /dev/random.
> 
> I have both /dev/random and /dev/urandom.
> 
> By simply replacing /dev/random with /dev/urandom in replicate.c, my 
> hang problem was resolved and automount works just great.
> 
> Does that make any sense?
> 
> Jim
> 
> Ian Kent wrote:
>> On Fri, 2008-01-04 at 21:46 -0500, Jim Duda wrote:
>>> Ian,
>>>
>>> On the machine that don't work properly, I get this from showmount.
>>>
>>> asterisk> showmount
>>> Broken pipe
>> That doesn't look very good.
>> It may be an indication that RPC is somehow not right on the machine.
>> I would expect output like (assuming the machine isn't actually being
>> used as an NFS server):
>> showmount: RPC: Program not registered
>>
>> Maybe the problem is as simple as portmap or rpcbind not running on the
>> machine. But then I'd expect showmount to just return nothing.
>>
>>> Does that mean anything to you?
>>>
>>> Note that in my auto.master file, I have /net commented out ...
>>>
>>> Jim
>>>
>>> Ian Kent wrote:
>>>> On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
>>>>> Ian,
>>>>>
>>>>> Here in spawn.c
>>>>>
>>>>> 		errp = 0;
>>>>> 		do {
>>>>> 			while ((errn =
>>>>> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
>>>>> 			       && errno == EINTR);
>>>> I'm not sure this really says much except that autofs is waiting for
>>>> mount(8) (or umount(8) as the case may be) to complete.
>>>>
>>>> Usually you will see a mount process running if mount isn't completing,
>>>> in which case, it becomes a matter of working out why mount can't
>>>> complete the mount. If we were logging debug info then usually we would
>>>> be able to get the mount command used which is often helpful. OTOH, if
>>>> there isn't any process (either mount or another automount process) then
>>>> perhaps mount has seg faulted and autofs is waiting for a reply but,
>>>> usually, if that happens the daemon gets a signal and continues with
>>>> what looks like a successful mount which it often really isn't.
>>>>
>>>>> Jim Duda wrote:
>>>>>> Ian,
>>>>>>
>>>>>> I do have daemon.*, I got it backwards in the last post.
>>>>>>
>>>>>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
>>>>>>
>>>>>> Jim
>>>>>>
>>>>>> Ian Kent wrote:
>>>>>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
>>>>>>>> Ian,
>>>>>>>>
>>>>>>>> Adding *.daemon simply resulted in the same information being dumped to 
>>>>>>>> the syslog file, however, twice.  So, no new information.
>>>>>>> That should be daemon.* and usually you would log it to a different file
>>>>>>> when adding a syslog entry like that but I don't think that will make
>>>>>>> any difference.
>>>>>>>
>>>>>>> I can't remember how logging to a syslog server works now but does the
>>>>>>> syslog configuration on the server also limit what is logged?
>>>>>>>
>>>>>>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
>>>>>>>> I cannot break into the program after it's wedged.
>>>> I haven't seen that behavior before and I've debugged some really broken
>>>> code in the early version 5 development. Perhaps this is something other
>>>> than just autofs?
>>>>
>>>>>>>> I'm by no means a power gdb user.
>>>>>>> Me nether.
>>>>>>>
>>>>>>>> I did:
>>>>>>>>
>>>>>>>> set detach-on-fork off, simply based on a recommended help from ddd.
>>>>>>>>
>>>>>>>> I traced the program all the way down into mount_bind.c, in the 
>>>>>>>> mount_init function, then into spawn.c, where it did the first fork. 
>>>>>>>> The program was wedged in spawn.c on line 186 at the first do while loop 
>>>>>>>> after the fork.
>>>>>>>>
>>>>>>>> The program though do_read_master, mod->lookup_int, then into open_mount 
>>>>>>>> for "nfs" before it got to the first spawn.
>>>>>>>>
>>>>>>>> I don't know how helpful any of this information is for you in helping 
>>>>>>>> me determine what is different about my funky root file system which 
>>>>>>>> causes a lockup, but thanks for trying.
>>>>>>> I'm not sure either but one thing is sure, problems are almost always
>>>>>>> different from what you think they are when you finally get hard
>>>>>>> evidence.
>>>>>>>
>>>>>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
>>>>>>>
>>>>>>> How about we try getting rid of a recent patch to this area of the code
>>>>>>> and rebuild autofs and see if that helps. The one I have in mind is
>>>>>>> close to the chopping block already.
>>>>>>>
>>>>>>> In particular:
>>>>>>>
>>>>>>> [raven@raven F-7]$ cvs diff -u autofs.spec 
>>>>>>> Index: autofs.spec
>>>>>>> ===================================================================
>>>>>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
>>>>>>> retrieving revision 1.221
>>>>>>> diff -u -r1.221 autofs.spec
>>>>>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
>>>>>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
>>>>>>> @@ -127,7 +127,7 @@
>>>>>>>  %patch35 -p1
>>>>>>>  %patch36 -p1
>>>>>>>  %patch37 -p1
>>>>>>> -%patch38 -p1
>>>>>>> +#%patch38 -p1
>>>>>>>  %patch39 -p1
>>>>>>>  
>>>>>>>  %build
>>>>> _______________________________________________
>>>>> autofs mailing list
>>>>> autofs@linux.kernel.org
>>>>> http://linux.kernel.org/mailman/listinfo/autofs

Re: automount won't start - just hangs

[Ian Kent]

On Sun, 2008-01-06 at 13:34 -0500, Jim Duda wrote:
> Ian,
> 
> All of my NFS based root file system computers operate without mice or 
> keyboards.  I read a few posts which claim that /dev/random might not 
> provide any data on these type of machines.
> 
> In my rc.local, I have simply removed /dev/random and created a link 
> from random to /dev/urandom.
> 
> Now everything works just fine!!
> 
> Thanks for all your patience on this thread.

Wow, that's a surprise and yet so obvious in hindsight.
I'll have to work out a way to deal with that.

> 
> Jim
> 
> Jim Duda wrote:
> > Ian,
> > 
> > I cannot explain why, but I wasn't able to get any debug message via 
> > SYSLOG, however, I found that by using msg(""), I was able to add my own 
> > debugging.
> > 
> > I finally figured out the root cause of the hang.  The program was 
> > blocked down inside replicate.d, at the read of /dev/random.
> > 
> > I have both /dev/random and /dev/urandom.
> > 
> > By simply replacing /dev/random with /dev/urandom in replicate.c, my 
> > hang problem was resolved and automount works just great.
> > 
> > Does that make any sense?
> > 
> > Jim
> > 
> > Ian Kent wrote:
> >> On Fri, 2008-01-04 at 21:46 -0500, Jim Duda wrote:
> >>> Ian,
> >>>
> >>> On the machine that don't work properly, I get this from showmount.
> >>>
> >>> asterisk> showmount
> >>> Broken pipe
> >> That doesn't look very good.
> >> It may be an indication that RPC is somehow not right on the machine.
> >> I would expect output like (assuming the machine isn't actually being
> >> used as an NFS server):
> >> showmount: RPC: Program not registered
> >>
> >> Maybe the problem is as simple as portmap or rpcbind not running on the
> >> machine. But then I'd expect showmount to just return nothing.
> >>
> >>> Does that mean anything to you?
> >>>
> >>> Note that in my auto.master file, I have /net commented out ...
> >>>
> >>> Jim
> >>>
> >>> Ian Kent wrote:
> >>>> On Thu, 2008-01-03 at 22:48 -0500, Jim Duda wrote:
> >>>>> Ian,
> >>>>>
> >>>>> Here in spawn.c
> >>>>>
> >>>>> 		errp = 0;
> >>>>> 		do {
> >>>>> 			while ((errn =
> >>>>> 				read(pipefd[0], errbuf + errp, ERRBUFSIZ - errp)) == -1
> >>>>> 			       && errno == EINTR);
> >>>> I'm not sure this really says much except that autofs is waiting for
> >>>> mount(8) (or umount(8) as the case may be) to complete.
> >>>>
> >>>> Usually you will see a mount process running if mount isn't completing,
> >>>> in which case, it becomes a matter of working out why mount can't
> >>>> complete the mount. If we were logging debug info then usually we would
> >>>> be able to get the mount command used which is often helpful. OTOH, if
> >>>> there isn't any process (either mount or another automount process) then
> >>>> perhaps mount has seg faulted and autofs is waiting for a reply but,
> >>>> usually, if that happens the daemon gets a signal and continues with
> >>>> what looks like a successful mount which it often really isn't.
> >>>>
> >>>>> Jim Duda wrote:
> >>>>>> Ian,
> >>>>>>
> >>>>>> I do have daemon.*, I got it backwards in the last post.
> >>>>>>
> >>>>>> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?
> >>>>>>
> >>>>>> Jim
> >>>>>>
> >>>>>> Ian Kent wrote:
> >>>>>>> On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> >>>>>>>> Ian,
> >>>>>>>>
> >>>>>>>> Adding *.daemon simply resulted in the same information being dumped to 
> >>>>>>>> the syslog file, however, twice.  So, no new information.
> >>>>>>> That should be daemon.* and usually you would log it to a different file
> >>>>>>> when adding a syslog entry like that but I don't think that will make
> >>>>>>> any difference.
> >>>>>>>
> >>>>>>> I can't remember how logging to a syslog server works now but does the
> >>>>>>> syslog configuration on the server also limit what is logged?
> >>>>>>>
> >>>>>>>> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
> >>>>>>>> I cannot break into the program after it's wedged.
> >>>> I haven't seen that behavior before and I've debugged some really broken
> >>>> code in the early version 5 development. Perhaps this is something other
> >>>> than just autofs?
> >>>>
> >>>>>>>> I'm by no means a power gdb user.
> >>>>>>> Me nether.
> >>>>>>>
> >>>>>>>> I did:
> >>>>>>>>
> >>>>>>>> set detach-on-fork off, simply based on a recommended help from ddd.
> >>>>>>>>
> >>>>>>>> I traced the program all the way down into mount_bind.c, in the 
> >>>>>>>> mount_init function, then into spawn.c, where it did the first fork. 
> >>>>>>>> The program was wedged in spawn.c on line 186 at the first do while loop 
> >>>>>>>> after the fork.
> >>>>>>>>
> >>>>>>>> The program though do_read_master, mod->lookup_int, then into open_mount 
> >>>>>>>> for "nfs" before it got to the first spawn.
> >>>>>>>>
> >>>>>>>> I don't know how helpful any of this information is for you in helping 
> >>>>>>>> me determine what is different about my funky root file system which 
> >>>>>>>> causes a lockup, but thanks for trying.
> >>>>>>> I'm not sure either but one thing is sure, problems are almost always
> >>>>>>> different from what you think they are when you finally get hard
> >>>>>>> evidence.
> >>>>>>>
> >>>>>>> In autofs-5.0.1-31, line 186 corresponds to an if statement?
> >>>>>>>
> >>>>>>> How about we try getting rid of a recent patch to this area of the code
> >>>>>>> and rebuild autofs and see if that helps. The one I have in mind is
> >>>>>>> close to the chopping block already.
> >>>>>>>
> >>>>>>> In particular:
> >>>>>>>
> >>>>>>> [raven@raven F-7]$ cvs diff -u autofs.spec 
> >>>>>>> Index: autofs.spec
> >>>>>>> ===================================================================
> >>>>>>> RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> >>>>>>> retrieving revision 1.221
> >>>>>>> diff -u -r1.221 autofs.spec
> >>>>>>> --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
> >>>>>>> +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> >>>>>>> @@ -127,7 +127,7 @@
> >>>>>>>  %patch35 -p1
> >>>>>>>  %patch36 -p1
> >>>>>>>  %patch37 -p1
> >>>>>>> -%patch38 -p1
> >>>>>>> +#%patch38 -p1
> >>>>>>>  %patch39 -p1
> >>>>>>>  
> >>>>>>>  %build
> >>>>> _______________________________________________
> >>>>> autofs mailing list
> >>>>> autofs@linux.kernel.org
> >>>>> http://linux.kernel.org/mailman/listinfo/autofs
> 

Re: automount won't start - just hangs

[Ian Kent]

On Thu, 2008-01-03 at 21:32 -0500, Jim Duda wrote:
> Ian,
> 
> I do have daemon.*, I got it backwards in the last post.
> 
> I downloaded autofs-5.0.2.tar.gz, do you want me to download 5.1.31 ?

I only said that because you mentioned using autofs-5.0.1-31 in a
previous mail. You did mention you had downloaded the tar but didn't say
if you had applied the patches when I asked and in a mail following you
provided output from "rpm -q autofs" that showed you were using revision
31.

The patch I referred to isn't included in the tar or any of the patches
that should be applied to it.

> 
> Jim
> 
> Ian Kent wrote:
> > On Thu, 2008-01-03 at 20:55 -0500, Jim Duda wrote:
> >> Ian,
> >>
> >> Adding *.daemon simply resulted in the same information being dumped to 
> >> the syslog file, however, twice.  So, no new information.
> > 
> > That should be daemon.* and usually you would log it to a different file
> > when adding a syslog entry like that but I don't think that will make
> > any difference.
> > 
> > I can't remember how logging to a syslog server works now but does the
> > syslog configuration on the server also limit what is logged?
> > 
> >> Once automount gets wedged, I cannot use gdb to interrogate the threads, 
> >> I cannot break into the program after it's wedged.
> >>
> >> I'm by no means a power gdb user.
> > 
> > Me nether.
> > 
> >> I did:
> >>
> >> set detach-on-fork off, simply based on a recommended help from ddd.
> >>
> >> I traced the program all the way down into mount_bind.c, in the 
> >> mount_init function, then into spawn.c, where it did the first fork. 
> >> The program was wedged in spawn.c on line 186 at the first do while loop 
> >> after the fork.
> >>
> >> The program though do_read_master, mod->lookup_int, then into open_mount 
> >> for "nfs" before it got to the first spawn.
> >>
> >> I don't know how helpful any of this information is for you in helping 
> >> me determine what is different about my funky root file system which 
> >> causes a lockup, but thanks for trying.
> > 
> > I'm not sure either but one thing is sure, problems are almost always
> > different from what you think they are when you finally get hard
> > evidence.
> > 
> > In autofs-5.0.1-31, line 186 corresponds to an if statement?
> > 
> > How about we try getting rid of a recent patch to this area of the code
> > and rebuild autofs and see if that helps. The one I have in mind is
> > close to the chopping block already.
> > 
> > In particular:
> > 
> > [raven@raven F-7]$ cvs diff -u autofs.spec 
> > Index: autofs.spec
> > ===================================================================
> > RCS file: /cvs/pkgs/rpms/autofs/F-7/autofs.spec,v
> > retrieving revision 1.221
> > diff -u -r1.221 autofs.spec
> > --- autofs.spec 21 Dec 2007 10:21:18 -0000      1.221
> > +++ autofs.spec 4 Jan 2008 02:20:20 -0000
> > @@ -127,7 +127,7 @@
> >  %patch35 -p1
> >  %patch36 -p1
> >  %patch37 -p1
> > -%patch38 -p1
> > +#%patch38 -p1
> >  %patch39 -p1
> >  
> >  %build
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs