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
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!
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.
(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?
> > 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?
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!
Created attachment 306799 [details] dump of relevant part of ldap
Created attachment 306800 [details] debug log
Steps taken: - dumped the directory (see attachment) - Modified /etc/sysconfig/autofs.conf as suggested - editted /etc/rsyslog.conf - rebooted the system
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?
(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
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.
(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
(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.
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...
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
I can confirm this. Same work around still works..
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.
See also https://bugzilla.redhat.com/show_bug.cgi?id=480407.
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.
I'm running into this as well. Is there any further word on a fix for this?
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.
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
(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.
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.
I've posted another solution to bug 506533 (possible dupe), using a NetworkManager dispatcher script.
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
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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
(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.
(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.
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.
Per bug 709637 this worked for me on FC16: systemctl enable NetworkManager-wait-online.service
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
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.
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.