Description of problem: When the system is started the automounter is started before the network is up. This causes the automount maps from the LDAP server not to be loaded, and the home directories not being available for login. The LDAP automount maps are read correctly after manually restarting the automounter when the system is finished booting, and the network is available. Version-Release number of selected component (if applicable): autofs-5.0.6-22.fc17.x86_64 How reproducible: Every reboot Steps to Reproduce: 1. Boot or reboot the machine 2. 3. Actual results: Automount maps from LDAP is not read, failures of network not ready logged from the automounter in the messages file. The LDAP automount maps are read correctly after manually restarting the automounter when the system is finished booting. Expected results: Automount maps should be available when the system is started. Additional info:
See bug 813160. If this is not the problem you are seeing then feel free to re-open this bug. *** This bug has been marked as a duplicate of bug 813160 ***
I don't have my Fedora system in front of me so I cannot test, however I expect that to fix the issue. I still believe this is a bug. Perhaps the automounter should make sure this service is enabled when LDAP maps is being utilized? So perhaps the autofs.service should depend on the NetworkManager-wait-online.service?
(In reply to comment #2) > I don't have my Fedora system in front of me so I cannot test, however I > expect that to fix the issue. I still believe this is a bug. > > Perhaps the automounter should make sure this service is enabled when LDAP > maps is being utilized? No, LDAP isn't the only map source. > > So perhaps the autofs.service should depend on the > NetworkManager-wait-online.service? Maybe, but that implies that NetworkManager-wait-online.service is enabled (by default) and it isn't and my request to do so was refused last time this came up. Ian
Applying the wait-online service does solve the issue, however I've seen this exact issue reported on several platforms, Fedora, Red Hat, Ubuntu, etc. And I've experienced the same issue on all these platforms myself too. What about having an option in automount for re-scanning for automount maps when a new network connection is detected? Somewhat similar to what ntpd does when a network interface is taken online or offline. Feb 23 10:32:07 mordor ntpd[1267]: new interface(s) found: waking up resolver Siggi
(In reply to comment #4) > Applying the wait-online service does solve the issue, however I've seen > this exact issue reported on several platforms, Fedora, Red Hat, Ubuntu, > etc. And I've experienced the same issue on all these platforms myself too. > > What about having an option in automount for re-scanning for automount maps > when a new network connection is detected? Somewhat similar to what ntpd > does when a network interface is taken online or offline. > > Feb 23 10:32:07 mordor ntpd[1267]: new interface(s) found: waking up resolver I don't think that's a good idea, particularly as there could be large map re-reads triggered every time an interface changes state. The actual problem is that the initial read of the master map fails so the automount managed mounts aren't setup. As long as the initial read of the master map succeeds then automount can continue to function with interfaces going up and down, as the case may be, with expected mount request failures of course. At one point I added a retry on master map read fail which worked for my testing but didn't work for the person who requested it. The person was unable to provide information that would have enabled me to resolve the problem with the implementation so the change was abandoned. Ian
I wouldn't mind testing the retry on master map. This could be a feature not enabled by default but enabled with a setting in /etc/sysconfig/autofs similar to how "BROWSE_MODE" is implemented. This would allow administrators to choose to opt in or opt out of using the feature. I see the reread on interface change also very useful in settings where one would use VPN to connect a laptop to the company network for later to access mounts via the automounter. Would it be possible to provide me with the version you made having this feature?
(In reply to comment #6) > I wouldn't mind testing the retry on master map. This could be a feature not > enabled by default but enabled with a setting in /etc/sysconfig/autofs > similar to how "BROWSE_MODE" is implemented. This would allow administrators > to choose to opt in or opt out of using the feature. I'd rather it be used all the time since, if the master map can't be read in its entirety at start then autofs shouldn't attempt to start automounts from the partial map it might have. > > I see the reread on interface change also very useful in settings where one > would use VPN to connect a laptop to the company network for later to access > mounts via the automounter. Perhaps, but that's quite a bit of work to do in itself, even without working out a way to prevent excessive map re-reads. > > Would it be possible to provide me with the version you made having this > feature? OK, its been a while since I did that so I'll need to see where it was at and probably re-work it a bit.
(In reply to comment #6) > I wouldn't mind testing the retry on master map. This could be a feature not > enabled by default but enabled with a setting in /etc/sysconfig/autofs > similar to how "BROWSE_MODE" is implemented. This would allow administrators > to choose to opt in or opt out of using the feature. > > I see the reread on interface change also very useful in settings where one > would use VPN to connect a laptop to the company network for later to access > mounts via the automounter. > > Would it be possible to provide me with the version you made having this > feature? You could give this a try: http://people.redhat.com/~ikent/autofs-5.0.6-25.fc17 It should wait for the master map to become available at startup. It adds a configuration entry and an automount(8) command line option. I'm pretty sure it needs for work but I'm not sure what that is.
I installed and tested. I'm starting manually: "automount -v -f -d" and it says: main:2293: autmount: failed to read master map, will retry! There is a line like this for every mount point I have: ignoring duplicate indirect mount /data And then it keeps looping like this. All maps are displayed corrcetly ff I do a "automount -m". I can send you the full log in private if you would like?
(In reply to comment #9) > I installed and tested. I'm starting manually: "automount -v -f -d" and it > says: > main:2293: autmount: failed to read master map, will retry! > > There is a line like this for every mount point I have: > ignoring duplicate indirect mount /data > > And then it keeps looping like this. Right, I think I get what's happening, I'll have a look and see what I can do. > > All maps are displayed corrcetly ff I do a "automount -m". The "all" is also interesting, .... > > I can send you the full log in private if you would like? Not just yet. Ian
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.
FYI, on my fedora19 with autofs-5.0.7-28.fc19.x86_64 and using sssd ldap automount maps, I had the same problem: ldap maps wouldn't load at system startup. A simple systemctl restart autofs.service corrected the pb, but this is not convinient . applying solution decribed in: https://bugzilla.redhat.com/show_bug.cgi?id=813160 that is enabling NetworkManager-wait-online.service seems to correct the problem. set it: /usr/bin/systemctl -q enable NetworkManager-wait-online.service check it: [root@b06-09 ~]# /usr/bin/systemctl is-enabled NetworkManager-wait-online.service enabled reboot before [root@b06-09 ~]# mount | grep auto | grep ldap returns nothing after [root@b06-09 ~]# mount | grep auto | grep ldap ldap:ou=direct,ou=automount,dc=int,dc=fr on /mci/TS1215 type autofs (rw,relatime,fd=19,pgrp=24621,timeout=300,minproto=5,maxproto=5,direct) ... thanks to cfengine3 automation, we can enable NetworkManager-wait-online on our hundred of fedora19 stations and correct globally that problem . perhaps it should be addressed withing the config file packages in autofs in order to assure that autofs start later/after network in the boot process !?
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.