Created attachment 335034 [details] syslog debug output Description of problem: autofs is broken in rawhide for me right now. I'm trying to do NFS mounts of home and project directories with intermittent success. Version-Release number of selected component (if applicable): autofs-5.0.4-17.i586 openldap-2.4.15-1.fc11.i586 python-ldap-2.3.5-5.fc11.i586 openldap-clients-2.4.15-1.fc11.i586 apr-util-ldap-1.3.4-3.fc11.i586 openldap-devel-2.4.15-1.fc11.i586 nss_ldap-264-2.fc11.i586 How reproducible: Almost always Steps to Reproduce: 1. Try to access directories that successfully mount in fedora 10 using the same configuration files (which I will attach later) Actual results: operations hang or return failure attempting to access automounted NFS directories Expected results: Successful access to those directories. Additional info:
Created attachment 335036 [details] nsswitch.conf
Created attachment 335037 [details] etc/sysconfig/autofs
Created attachment 335039 [details] auto.master #auto_home looks something like this: user1 manaan:/export/home/& user2 manaan:/export/home/& user3 manaan:/export/home/& user4 manaan:/export/home/& #... #it's a lot bigger, but I think our user list is considered proprietary
automount[3414]: do_bind: lookup(ldap): ldap anonymous bind returned 0 automount[3414]: get_query_dn: lookup(ldap): query failed for (&(objectclass=nisMap)(nisMapName=auto_home)): Operations error When you get this does the automount process disappear?
(In reply to comment #4) > automount[3414]: do_bind: lookup(ldap): ldap anonymous bind returned 0 > automount[3414]: get_query_dn: lookup(ldap): query failed for > (&(objectclass=nisMap)(nisMapName=auto_home)): Operations error > > When you get this does the automount process disappear? I'm guessing it does. Can you try this package and let me know if it resolves the issue. http://kojipkgs.fedoraproject.org/packages/autofs/5.0.4/19
(In reply to comment #5) > (In reply to comment #4) > > automount[3414]: do_bind: lookup(ldap): ldap anonymous bind returned 0 > > automount[3414]: get_query_dn: lookup(ldap): query failed for > > (&(objectclass=nisMap)(nisMapName=auto_home)): Operations error > > > > When you get this does the automount process disappear? > > I'm guessing it does. > Can you try this package and let me know if it resolves the > issue. > > http://kojipkgs.fedoraproject.org/packages/autofs/5.0.4/19 Before trying the new version, I wanted to make sure I could reproduce the problem. The next time I booted, autofs worked. What I found was that changing my eth0 to be NetworkManager controlled (using system-config-network) fixed the problem. I had previously manually started eth0 like this: /sbin/ifconfig eth0 192.168.117.25 netmask 255.255.252.0 After doing this, I could communicate with the NFS server and LDAP server, but autofs was not reliable. When it was in that state, stopping and starting autofs didn't help. I think there is something related to a startup sequence that is causing the problem (if eth0 isn't up at some time in the boot sequence, autofs has problems).
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > automount[3414]: do_bind: lookup(ldap): ldap anonymous bind returned 0 > > > automount[3414]: get_query_dn: lookup(ldap): query failed for > > > (&(objectclass=nisMap)(nisMapName=auto_home)): Operations error > > > > > > When you get this does the automount process disappear? > > > > I'm guessing it does. > > Can you try this package and let me know if it resolves the > > issue. > > > > http://kojipkgs.fedoraproject.org/packages/autofs/5.0.4/19 > > Before trying the new version, I wanted to make sure I could > reproduce the problem. The next time I booted, autofs worked. > What I found was that changing my eth0 to be NetworkManager > controlled (using system-config-network) fixed the problem. > I had previously manually started eth0 like this: > > /sbin/ifconfig eth0 192.168.117.25 netmask 255.255.252.0 > > After doing this, I could communicate with the NFS server > and LDAP server, but autofs was not reliable. When it was > in that state, stopping and starting autofs didn't help. > > I think there is something related to a startup sequence > that is causing the problem (if eth0 isn't up at some > time in the boot sequence, autofs has problems). This description isn't really useful. You need to provide debug logs along with a problem description. You need to not change too many things at once (ideally one thing at a time) as you test. We know there is a problem with startup ordering due to LSB changing the init script order. I added an LSB block in rev 20 but I'm not yet sure if that do what we need it to do. It would be worth using the later version.
Debug logs were already provided in an attachment as was a problem description.
(In reply to comment #8) > Debug logs were already provided in an attachment > as was a problem description. Those debug logs indicate a problem at a specific place in the code which I think I have fixed. If you observe a change in behaviour or change the way you test you need to collect and post the debug for that also. Given the information provided so far I don't have anything new to work with so I can't work out what may be going wrong in your case.
I backed out the change that masked the bug (disabled network manager control of eth0) and reproduced the failure. Then I updated to: http://kojipkgs.fedoraproject.org/packages/autofs/5.0.4/19 As far as I can tell, this did fix the problem. Thanks.