Bug 448510 - Autofs needs to wait for a network up event before starting
Autofs needs to wait for a network up event before starting
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
19
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-27 07:33 EDT by Bart Baars
Modified: 2015-02-18 06:57 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:57:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dump of relevant part of ldap (1.39 KB, text/x-ldif)
2008-05-27 12:58 EDT, Bart Baars
no flags Details
debug log (62.93 KB, text/plain)
2008-05-27 13:00 EDT, Bart Baars
no flags Details
Debug log without autofs being restarted (23.09 KB, text/plain)
2008-05-28 17:52 EDT, Bart Baars
no flags Details

  None (edit)
Description Bart Baars 2008-05-27 07:33:12 EDT
After installing autofs, I configure it to mount homedirs when the user logs on.
Info is stored in an OpenLDAP directory server.

After a reboot all looks good and autofs is up and running. But when the user
logs in, an error is being displayed that the user has no homedir. Restarting
autofs solves the problem.

Workaound:
Editted /etc/rc.d/rc.local with:
wait 10
/sbin/service autofs restart

"wait 10" is required; without this autofs is beging restarted, but still
doesn't work.

The exact same setup is working in FC8
Comment 1 Jeff Moyer 2008-05-27 09:20:19 EDT
That's strange.  The wait 10 makes me wonder if the network is actually up when
autofs is started.  Can you please provide a debug log?  You can find
instructions on generating one at:  http://people.redhat.com/jmoyer/

Thanks!
Comment 2 Bart Baars 2008-05-27 09:37:47 EDT
Will generate the debuglog!

But the user trying to login is also stored in OpenLDAP. Authentication works,
so it's likely network is up.

I haven't installed/configured the caching daemon btw.
Comment 3 Ian Kent 2008-05-27 10:30:38 EDT
(In reply to comment #2)
> Will generate the debuglog!
> 
> But the user trying to login is also stored in OpenLDAP. Authentication works,
> so it's likely network is up.
> 
> I haven't installed/configured the caching daemon btw.

Are you using NetworkManager?
Comment 4 Bart Baars 2008-05-27 12:00:57 EDT
> 
> Are you using NetworkManager?
> 

Yes, I am.

(some) Debugging output: I removed a lot of comments ;)

------------------------------------
[root@localhost ~]# rpm -q autofs
autofs-5.0.3-13.x86_64
[root@localhost ~]# uname -r
2.6.25.3-18.fc9.x86_64
[root@localhost ~]# cat /etc/sysconfig/autofs

DEFAULT_TIMEOUT=300
DEFAULT_BROWSE_MODE="no"

DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"

[root@localhost ~]# cat /etc/nsswitch.conf

passwd:     files ldap
shadow:     files ldap
group:      files ldap

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


bootparams: nisplus [NOTFOUND=return] files

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

netgroup:   files ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus
------------------------------------

Not sure howto get debug info from autofs itself when using ldap?
Comment 5 Jeff Moyer 2008-05-27 12:28:56 EDT
You can use ldapsearch to dump the maps.  But really, what I want is a debug log
from automount.  Take a look at the aforementioned web page and follow the steps
to produce the debug output via syslog.  Then, attach the logs here and we'll
take a look.  Since I'm guessing your auto.master is in LDAP, you'll probably
want to modify /etc/sysconfig/autofs to set DEFAULT_LOGGING="debug".

Thanks!
Comment 6 Bart Baars 2008-05-27 12:58:11 EDT
Created attachment 306799 [details]
dump of relevant part of ldap
Comment 7 Bart Baars 2008-05-27 13:00:31 EDT
Created attachment 306800 [details]
debug log
Comment 8 Bart Baars 2008-05-27 13:01:49 EDT
Steps taken:

- dumped the directory (see attachment)
- Modified /etc/sysconfig/autofs.conf as suggested
- editted /etc/rsyslog.conf
- rebooted the system

Comment 9 Jeff Moyer 2008-05-27 13:10:38 EDT
Thanks for the debug log!  If you take a look, you can see that automount is not
the only daemon that can't communicate with the LDAP server;  ntpd is also
having troubles.  Then, a little later in the logs, you'll see that
NetworkManager finally decides to bring up eth0.  After that, everything works
out fine.

Ian, I can't remember, but did you put the code in to keep retrying after failed
lookups?  In other words, should this just work without a restart once the
network is up?
Comment 10 Ian Kent 2008-05-27 22:51:32 EDT
(In reply to comment #9)
> Thanks for the debug log!  If you take a look, you can see that automount is not
> the only daemon that can't communicate with the LDAP server;  ntpd is also
> having troubles.  Then, a little later in the logs, you'll see that
> NetworkManager finally decides to bring up eth0.  After that, everything works
> out fine.
> 
> Ian, I can't remember, but did you put the code in to keep retrying after failed
> lookups?  In other words, should this just work without a restart once the
> network is up?

Not so much to retry as to re-connect if the connection goes
away.

With the configuration here, master map in a file, autofs
should start to work OK after the network becomes available.

Could we get a debug log of what happens when a mount is
attempted after NetworkManager brings up eth0, without
restarting it please.

Ian
Comment 11 Bart Baars 2008-05-28 17:52:27 EDT
Created attachment 306994 [details]
Debug log without autofs being restarted

As requested. User "beurdy" tries to logon, but it's homedir is not being
mounted.
Comment 12 Ian Kent 2008-05-28 23:06:04 EDT
(In reply to comment #11)
> Created an attachment (id=306994) [edit]
> Debug log without autofs being restarted
> 
> As requested. User "beurdy" tries to logon, but it's homedir is not being
> mounted.

Thanks for posting the log.
So very often it is exactly what we need to work out what's going
on and too often the thing we don't get soon enough.

This is happening because the /home automount hasn't been mounted
as the map wasn't found in any nss source when autofs started.

This raises an interesting question.

Part of the initialization of an automount involves locating the
map associated with it. All the given nss sources are checked,
but if they all fail the map is considered to not exist which
is classed as a failure.

That may not be the best way to handle this. I'll need to check
the implications of ignoring this failure and mounting the
automount anyway. There's also the question of how to handle
automounts that use the "browse" option since the map clearly
can't be read at this point.

Ian
Comment 13 Jeff Moyer 2008-06-11 12:27:19 EDT
(In reply to comment #12)
> This is happening because the /home automount hasn't been mounted
> as the map wasn't found in any nss source when autofs started.
> 
> This raises an interesting question.
> 
> Part of the initialization of an automount involves locating the
> map associated with it. All the given nss sources are checked,
> but if they all fail the map is considered to not exist which
> is classed as a failure.

In the case of the master map, there's certainly nothing we can do about that!

> That may not be the best way to handle this. I'll need to check
> the implications of ignoring this failure and mounting the
> automount anyway. There's also the question of how to handle
> automounts that use the "browse" option since the map clearly
> can't be read at this point.

I think that this is a corner case that may not be worth the amount of code
required to work around it!  I'm not sure, though.  It may be enough to just
check to see if the network was up at startup.  If it wasn't, then either
register for the network up event via dbus, or poll for networking to become
available.  At that point, re-do the initialization.

Really, the right way is to use dbus and wait for the network up event, I think.
Comment 14 Jeff Moyer 2008-06-11 12:28:24 EDT
As an aside, I think it's asinine that we can't be sure the network is up before
we are started.  This is something that has been relied upon for decades.  But I
digress...
Comment 15 Bug Zapper 2008-11-25 21:20:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bart Baars 2008-12-04 14:42:44 EST
I can confirm this. Same work around still works..
Comment 17 Edgar Hoch 2009-02-12 13:22:55 EST
I want to notice that /etc/init.d/autofs of autofs-5.0.3-36 don't have a LSB-delimited ’INIT INFO’ section. May it help if there will be a line in this section like this which requires network?

Required-Start: $local_fs $network $syslog

But it may be that it will only help for static network configuration with service network, not with NetworkManager?

Feature request: I think that a LSB-delimited ’INIT INFO’ section should be added for some of the next releases, as Fedora 10 is using upscript.
Comment 18 W. Michael Petullo 2009-02-18 18:50:31 EST
See also https://bugzilla.redhat.com/show_bug.cgi?id=480407.
Comment 19 Thomas J. Baker 2009-04-10 09:25:41 EDT
I saw this with F10, autofs, and NIS. It continues with F11Beta. Reboot, autofs doesn't wait long enough and doesn't get NIS maps. Even with NETWORKWAIT=yes in /etc/sysconfig/network. Just running service autofs reload fixes it.
Comment 20 Kevin Constantine 2009-04-24 22:08:11 EDT
I'm running into this as well.  Is there any further word on a fix for this?
Comment 21 Ian Kent 2009-05-04 03:15:54 EDT
I've had a go at adding an LSB block to the autofs init script
in F-10.

Can we give the build at
http://kojipkgs.fedoraproject.org/packages/autofs/5.0.3/43
a try please.
Comment 22 Kevin Constantine 2009-05-04 12:57:22 EDT
Installed 5.0.3-43.x86_64 this morning and rebooted.  Autofs still wasn't able to contact the ldap serves to pick up the maps because eth0 still wasn't available.  

Here's the messages log:
May  4 09:38:38 beaver pcscd: pcscdaemon.c:498:main() pcsc-lite 1.4.102 daemon ready.
May  4 09:38:38 beaver acpid: client connected from 2418[68:68]
May  4 09:38:38 beaver NetworkManager: <info>  starting...
May  4 09:38:38 beaver NetworkManager: <WARN>  nm_generic_enable_loopback(): error -17 returned from rtnl_addr_add():#012Sucess#012
May  4 09:38:38 beaver NetworkManager: <info>  (eth0): new Ethernet device (driver: 'tg3')
May  4 09:38:38 beaver NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_17_08_2a_53_f7
May  4 09:38:38 beaver NetworkManager: <info>  (ttyS0): ignoring due to lack of mobile broadband capabilties
May  4 09:38:38 beaver NetworkManager: <info>  Trying to start the supplicant...
May  4 09:38:38 beaver NetworkManager: <info>  Trying to start the system settings daemon...
May  4 09:38:38 beaver pam_console_apply: nss_ldap: failed to bind to LDAP server ldap://faldap.foo.org: Can't contact LDAP server
May  4 09:38:38 beaver pam_console_apply: nss_ldap: failed to bind to LDAP server ldap://faldap.foo.org: Can't contact LDAP server
May  4 09:38:38 beaver pam_console_apply: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
May  4 09:38:38 beaver pam_console_apply: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
May  4 09:38:39 beaver nm-system-settings: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
May  4 09:38:39 beaver nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...
May  4 09:38:39 beaver nm-system-settings:    ifcfg-rh:     read connection 'System eth0'
May  4 09:38:39 beaver nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
May  4 09:38:39 beaver automount[2450]: Starting automounter version 5.0.3-43, master map auto_master
May  4 09:38:39 beaver automount[2450]: using kernel protocol version 5.00
May  4 09:38:39 beaver automount[2450]: lookup(ldap): Unable to bind to the LDAP server: ldap://faldap, error Can't contact LDAP server
May  4 09:38:39 beaver automount[2450]: lookup(ldap): couldn't connect to server ldap://faldap
May  4 09:38:39 beaver automount[2450]: lookup_init: lookup(ldap): failed to find available server
May  4 09:38:39 beaver automount[2450]: lookup(file): failed to read included master map auto_master
May  4 09:38:39 beaver automount[2450]: mounted indirect mount for /misc with timeout 300, freq 75 seconds
May  4 09:38:39 beaver automount[2450]: ghosting enabled
May  4 09:38:39 beaver automount[2450]: mounted indirect mount for /net with timeout 300, freq 75 seconds
May  4 09:38:39 beaver automount[2450]: ghosting enabled
May  4 09:38:39 beaver nscd: 2473 Access Vector Cache (AVC) started
May  4 09:38:40 beaver bluetoothd[2498]: Bluetooth daemon
May  4 09:38:40 beaver kernel: Bluetooth: Core ver 2.13
May  4 09:38:40 beaver kernel: NET: Registered protocol family 31
May  4 09:38:40 beaver kernel: Bluetooth: HCI device and connection manager initialized
May  4 09:38:40 beaver kernel: Bluetooth: HCI socket layer initialized
May  4 09:38:40 beaver bluetoothd[2498]: Starting SDP server
May  4 09:38:40 beaver kernel: Bluetooth: L2CAP ver 2.11
May  4 09:38:40 beaver kernel: Bluetooth: L2CAP socket layer initialized
May  4 09:38:40 beaver bluetoothd[2498]: Registered interface org.bluez.Service on path /org/bluez/2498/any
May  4 09:38:40 beaver bluetoothd[2498]: Parsing /etc/bluetooth/network.conf failed: No such file or directory
May  4 09:38:40 beaver kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
May  4 09:38:40 beaver kernel: Bluetooth: BNEP filters: protocol multicast
May  4 09:38:40 beaver kernel: Bridge firewalling registered
May  4 09:38:40 beaver bluetoothd[2498]: bridge pan0 created
May  4 09:38:40 beaver bluetoothd[2498]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory
May  4 09:38:40 beaver kernel: Bluetooth: SCO (Voice Link) ver 0.6
May  4 09:38:40 beaver kernel: Bluetooth: SCO socket layer initialized
May  4 09:38:40 beaver bluetoothd[2498]: Parsing /etc/bluetooth/input.conf failed: No such file or directory
May  4 09:38:40 beaver /usr/sbin/gpm[2592]: *** info [daemon/startup.c(136)]:
May  4 09:38:40 beaver /usr/sbin/gpm[2592]: Started gpm successfully. Entered daemon mode.
May  4 09:38:40 beaver avahi-daemon[2632]: Found user 'avahi' (UID 496) and group 'avahi' (GID 491).
May  4 09:38:40 beaver avahi-daemon[2632]: Successfully dropped root privileges.
May  4 09:38:40 beaver avahi-daemon[2632]: avahi-daemon 0.6.22 starting up.
May  4 09:38:40 beaver avahi-daemon[2632]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
May  4 09:38:40 beaver avahi-daemon[2632]: Successfully called chroot().
May  4 09:38:40 beaver avahi-daemon[2632]: Successfully dropped remaining capabilities.
May  4 09:38:40 beaver avahi-daemon[2632]: Loading service file /services/ssh.service.
May  4 09:38:40 beaver avahi-daemon[2632]: Network interface enumeration completed.
May  4 09:38:40 beaver avahi-daemon[2632]: Registering HINFO record with values 'X86_64'/'LINUX'.
May  4 09:38:40 beaver avahi-daemon[2632]: Server startup complete. Host name is beaver.local. Local service cookie is 3428602724.
May  4 09:38:40 beaver avahi-daemon[2632]: Service "beaver" (/services/ssh.service) successfully established.
May  4 09:38:41 beaver kernel: virbr0: starting userspace STP failed, starting kernel STP
May  4 09:38:41 beaver avahi-daemon[2632]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
May  4 09:38:41 beaver avahi-daemon[2632]: New relevant interface virbr0.IPv4 for mDNS.
May  4 09:38:41 beaver avahi-daemon[2632]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
May  4 09:38:41 beaver dnsmasq[2692]: started, version 2.45 cachesize 150
May  4 09:38:41 beaver dnsmasq[2692]: compile time options: IPv6 GNU-getopt no-ISC-leasefile DBus no-I18N TFTP
May  4 09:38:41 beaver dnsmasq[2692]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
May  4 09:38:41 beaver dnsmasq[2692]: no servers found in /etc/resolv.conf, will retry
May  4 09:38:41 beaver dnsmasq[2692]: read /etc/hosts - 3 addresses
May  4 09:38:41 beaver kernel: Not cloning cgroup for unused subsystem ns
May  4 09:38:41 beaver Synergy 1.3.1: WARNING: synergyc.cpp,337: cannot open secondary screen: unable to open screen
May  4 09:38:42 beaver avahi-daemon[2632]: Registering new address record for fe80::4c63:c2ff:feab:22a8 on virbr0.*.
May  4 09:38:42 beaver setroubleshoot: SELinux prevented kde4-config from writing ./.kde. For complete SELinux messages. run sealert -l 35f2f0a5-fdba-42fa-8edf-439f9a668ea6
May  4 09:38:42 beaver acpid: client connected from 2801[0:0]
May  4 09:38:43 beaver NetworkManager: <info>  (eth0): device state change: 1 -> 2
May  4 09:38:43 beaver NetworkManager: <info>  (eth0): bringing up device.
May  4 09:38:43 beaver kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
May  4 09:38:43 beaver NetworkManager: <info>  (eth0): preparing device.
May  4 09:38:43 beaver NetworkManager: <info>  (eth0): deactivating device (reason: 2).
May  4 09:38:44 beaver acpid: client connected from 2801[0:0]
May  4 09:38:46 beaver kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
May  4 09:38:46 beaver kernel: tg3: eth0: Flow control is on for TX and on for RX.
May  4 09:38:46 beaver kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May  4 09:38:46 beaver NetworkManager: <info>  (eth0): carrier now ON (device state 2)
May  4 09:38:46 beaver NetworkManager: <info>  (eth0): device state change: 2 -> 3
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) starting connection 'System eth0'
May  4 09:38:46 beaver NetworkManager: <info>  (eth0): device state change: 3 -> 4
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
May  4 09:38:46 beaver NetworkManager: <info>  (eth0): device state change: 4 -> 5
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) successful.
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
May  4 09:38:46 beaver NetworkManager: <info>  (eth0): device state change: 5 -> 7
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Beginning DHCP transaction.
May  4 09:38:46 beaver NetworkManager: <info>  dhclient started with pid 2816
May  4 09:38:46 beaver NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
May  4 09:38:46 beaver dhclient: Internet Systems Consortium DHCP Client 4.0.0
May  4 09:38:46 beaver dhclient: Copyright 2004-2007 Internet Systems Consortium.
May  4 09:38:46 beaver dhclient: All rights reserved.
May  4 09:38:46 beaver dhclient: For info, please visit http://www.isc.org/sw/dhcp/
May  4 09:38:46 beaver dhclient:
May  4 09:38:46 beaver NetworkManager: <info>  DHCP: device eth0 state changed (null) -> preinit
May  4 09:38:46 beaver dhclient: Listening on LPF/eth0/00:17:08:2a:53:f7
May  4 09:38:46 beaver dhclient: Sending on   LPF/eth0/00:17:08:2a:53:f7
May  4 09:38:46 beaver dhclient: Sending on   Socket/fallback
May  4 09:38:46 beaver pam_console_apply: nss_ldap: failed to bind to LDAP server ldap://faldap.foo.org: Can't contact LDAP server
May  4 09:38:46 beaver pam_console_apply: nss_ldap: failed to bind to LDAP server ldap://faldap.foo.org: Can't contact LDAP server
May  4 09:38:46 beaver pam_console_apply: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
May  4 09:38:46 beaver pam_console_apply: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
May  4 09:38:47 beaver dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
May  4 09:38:47 beaver dhclient: DHCPOFFER from 172.30.163.253
May  4 09:38:47 beaver dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May  4 09:38:47 beaver dhclient: DHCPACK from 172.30.163.253
May  4 09:38:47 beaver NetworkManager: <info>  DHCP: device eth0 state changed preinit -> bound
May  4 09:38:47 beaver NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) scheduled...
May  4 09:38:47 beaver NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) started...
May  4 09:38:47 beaver NetworkManager: <info>    address 172.30.160.222
May  4 09:38:47 beaver NetworkManager: <info>    prefix 22 (255.255.252.0)
May  4 09:38:47 beaver NetworkManager: <info>    gateway 172.30.163.254
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.11'
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.21'
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.22'
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.23'
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.25'
May  4 09:38:47 beaver NetworkManager: <info>    nameserver '172.30.192.247'
May  4 09:38:47 beaver NetworkManager: <info>    domain name 'foo.org'
May  4 09:38:47 beaver NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
May  4 09:38:47 beaver NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) complete.
May  4 09:38:47 beaver NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
May  4 09:38:47 beaver avahi-daemon[2632]: Joining mDNS multicast group on interface eth0.IPv4 with address 172.30.160.222.
May  4 09:38:47 beaver avahi-daemon[2632]: New relevant interface eth0.IPv4 for mDNS.
May  4 09:38:47 beaver avahi-daemon[2632]: Registering new address record for 172.30.160.222 on eth0.IPv4.
May  4 09:38:47 beaver dhclient: bound to 172.30.160.222 -- renewal in 37566 seconds.
May  4 09:38:47 beaver avahi-daemon[2632]: Registering new address record for fe80::217:8ff:fe2a:53f7 on eth0.*.
May  4 09:38:48 beaver nscd: 2965 Access Vector Cache (AVC) started
May  4 09:38:48 beaver NetworkManager: <info>  (eth0): device state change: 7 -> 8
May  4 09:38:48 beaver nscd: 2986 Access Vector Cache (AVC) started
May  4 09:38:48 beaver NetworkManager: <info>  Policy set 'System eth0' (eth0) as default for routing and DNS.
May  4 09:38:48 beaver NetworkManager: <info>  Activation (eth0) successful, device activated.
May  4 09:38:48 beaver NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
May  4 09:38:48 beaver setroubleshoot: SELinux is preventing Default (xdm_t) "search" to ./share (automount_tmp_t). For complete SELinux messages. run sealert -l 9385365e-24a3-4e45-9079-2ab2f368a0e1
May  4 09:38:49 beaver gdm-simple-greeter[3059]: WARNING: Unable to query filesystem type for /home/fahome: Error getting filesystem info: No such file or directory
May  4 09:38:49 beaver gdm-simple-greeter[3059]: WARNING: Unable to query filesystem type for /home/fahome/kconstan: Error getting filesystem info: No such file or directory
May  4 09:38:49 beaver gdm-simple-greeter[3059]: WARNING: Unable to query filesystem type for /tmp/localuser: Error getting filesystem info: No such file or directory
May  4 09:38:50 beaver dnsmasq[2692]: reading /etc/resolv.conf
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.247#53
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.25#53
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.23#53
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.22#53
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.21#53
May  4 09:38:50 beaver dnsmasq[2692]: using nameserver 172.30.192.11#53
May  4 09:39:03 beaver pam_console_apply: nss_ldap: reconnected to LDAP server ldap://faldap.foo.org after 4 attempts
May  4 09:39:03 beaver pam_console_apply: nss_ldap: reconnected to LDAP server ldap://faldap.foo.org after 4 attempts

-kevin
Comment 23 Ian Kent 2009-05-04 21:55:08 EDT
(In reply to comment #22)
> Installed 5.0.3-43.x86_64 this morning and rebooted.  Autofs still wasn't able
> to contact the ldap serves to pick up the maps because eth0 still wasn't
> available.  

Oh, right, I got confused by recent discussions about the lack
of an LSB section in the init script, which of course, makes no
difference in this case.

I don't know anything about the dbus event interface so working
out what to do here is going to be difficult. I'm also not sure
whether using NetworkManager is sensible in this case. Since, in
theory, the network may be re-configured at any time when using
it so any application or library would need to check network
interface status before "every" access and it would need to do
that without knowing which interface the request would ultimately
be sent out on. We see this in the log as nss_ldap is assuming
the network is available also.

One partial solution would be that, at start, NetworkManager
should bring up any "System" configured interfaces before
returning.
Comment 24 Kevin Constantine 2009-07-07 20:00:51 EDT
For others who might be hitting this bug, I'm working around it by adding the following to /etc/sysconfig/network

NETWORKWAIT=yes

This causes the boot process to wait for the network to come up before attempting other processes further up the stack.
Comment 25 Orion Poplawski 2009-09-30 17:52:56 EDT
I've posted another solution to bug 506533 (possible dupe), using a NetworkManager dispatcher script.
Comment 26 Bug Zapper 2009-11-18 05:12:44 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 27 Bug Zapper 2010-03-15 08:00:50 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Fedora Admin XMLRPC Client 2010-12-06 10:13:28 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 29 Orion Poplawski 2011-02-16 18:07:06 EST
Changing to rawhide.  Probably should set Tracking or FutureFeature or some such.  May be able to use systemd features for this now.  Or perhaps automount just needs to periodically retry connecting to the ldap server.  Probably the most robust.
Comment 30 Trond H. Amundsen 2011-06-07 06:04:37 EDT
Hi Ian (and others),

This exact bug has hit us in RHEL6. For now, I have applied the "sleep a few seconds and restart autofs" workaround on all clients, but adding 10 seconds boot time is not a lasting solution. This bug was reported more than 3 years ago, is there an end in sight?

-trond
Comment 31 Ian Kent 2011-06-07 08:33:05 EDT
(In reply to comment #30)
> Hi Ian (and others),
> 
> This exact bug has hit us in RHEL6. For now, I have applied the "sleep a few
> seconds and restart autofs" workaround on all clients, but adding 10 seconds
> boot time is not a lasting solution. This bug was reported more than 3 years
> ago, is there an end in sight?

Most recently it's been NetworkManager not waiting for the
network interface to come up causing this.

I think the appropriate solution is for NetworkManager to
wait until the network comes up by default, but that's just
my opinion. That can be done by putting NETWORKWAIT=yes in
/etc/sysconfig/network. If that isn't enough (it should be)
then you can also put NETWORKDELAY=20 in the same configuration
file to make it wait a little longer.
Comment 32 Ian Kent 2011-06-07 08:34:41 EDT
(In reply to comment #31)
> I think the appropriate solution is for NetworkManager to
> wait until the network comes up by default, but that's just
> my opinion. That can be done by putting NETWORKWAIT=yes in
> /etc/sysconfig/network. If that isn't enough (it should be)
> then you can also put NETWORKDELAY=20 in the same configuration
> file to make it wait a little longer.

Well, 20 is just a number, of course, use what's best for your
site.
Comment 33 Johan Godfried 2011-07-29 15:27:45 EDT
I can confirm this problem also exists in FC15 (Lovelock) with autofs-5.0.5-38.fc15.x86_64

I use autofs with LDAP on a laptop that connects to my network via Wifi. The Wifi connection is a global connection managed by NetworkManager.

At boot time, autofs starts before the wireless connection is established.

In FC14, this setup worked fine. But since I upgraded to FC15, no automounts are created until after I restart the autofs service manually.
Comment 34 Ciaran Wills 2011-11-17 19:15:01 EST
Per bug 709637 this worked for me on FC16:

systemctl enable NetworkManager-wait-online.service
Comment 35 Fedora End Of Life 2013-04-03 16:04:22 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 36 Fedora End Of Life 2015-01-09 16:36:48 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 37 Fedora End Of Life 2015-02-18 06:57:15 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.