See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id=846852
FYI:
We discovered that after updating to EL 6.3 on our x86_64 server, autofs 5.0.5-54 broke our nightly backups that rely on automounting an NFS share hosted on another EL 6 machine on our local network. The machine hosting NFS server was configured to allow only TCP connections to the port specified by MOUNTD_PORT in "/etc/sysconfig/nfs"
Any attempts to access this share caused segmentation faults in the automount daemon.
EL 6.2 hosts that had not yet been updated had no problems accessing the same NFS shares.
While testing we found that opening the UDP MOUNTD_PORT on the NFS server firewall allowed successful access to the NFS shares from the EL 6.3 NFS client without segfault. Closing the port caused the EL 6.3 NFS client to return to the faulty behavior.
On another fully updated EL 6.3 i386 host, we were able to duplicate the same symptoms.
On one of the EL 6.2 hosts not yet updated we confirmed no issues with the previous autofs package, then upgraded only autofs. After the upgrade we confirmed symptoms identical to the fully updated 6.3 machines.
While filing the bug report I found 2 other, possibly related, bugs written against autofs 5.0.5-54 that did not describe our symptoms but may be relevant to other users on this list.
Bug 840025 - autofs 5.0.5-54 fails to mount share on IPv6 netapp https://bugzilla.redhat.com/show_bug.cgi?id=840025
Bug 834641 - autofs requires portmapper on server for NFSv4 mounts https://bugzilla.redhat.com/show_bug.cgi?id=834641
[Workaround]
For now, we are leaving the UDP NFS port open on the firewall of the NFS server. Our networks are completely isolated from the outside world so this doesn't pose a significant risk. However, this may not be acceptable for everyone's environment.
On Wed, 2012-08-08 at 18:37 -0400, Cal Webster wrote:
See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id=846852
FYI:
We discovered that after updating to EL 6.3 on our x86_64 server, autofs 5.0.5-54 broke our nightly backups that rely on automounting an NFS share hosted on another EL 6 machine on our local network. The machine hosting NFS server was configured to allow only TCP connections to the port specified by MOUNTD_PORT in "/etc/sysconfig/nfs"
Any attempts to access this share caused segmentation faults in the automount daemon.
EL 6.2 hosts that had not yet been updated had no problems accessing the same NFS shares.
While testing we found that opening the UDP MOUNTD_PORT on the NFS server firewall allowed successful access to the NFS shares from the EL 6.3 NFS client without segfault. Closing the port caused the EL 6.3 NFS client to return to the faulty behavior.
On another fully updated EL 6.3 i386 host, we were able to duplicate the same symptoms.
On one of the EL 6.2 hosts not yet updated we confirmed no issues with the previous autofs package, then upgraded only autofs. After the upgrade we confirmed symptoms identical to the fully updated 6.3 machines.
While filing the bug report I found 2 other, possibly related, bugs written against autofs 5.0.5-54 that did not describe our symptoms but may be relevant to other users on this list.
Bug 840025 - autofs 5.0.5-54 fails to mount share on IPv6 netapp https://bugzilla.redhat.com/show_bug.cgi?id=840025
Bug 834641 - autofs requires portmapper on server for NFSv4 mounts https://bugzilla.redhat.com/show_bug.cgi?id=834641
[Workaround]
For now, we are leaving the UDP NFS port open on the firewall of the NFS server. Our networks are completely isolated from the outside world so this doesn't pose a significant risk. However, this may not be acceptable for everyone's environment.
I forgot to mention that I did find what appeared to be an identical bug reported apparently as a private upstream support case #155523. I found it in a Google search but the link (https://access.redhat.com/knowledge/solutions/155523) raised a permission error, even though I was logged into the site. The text-only cached page from July 24 read like this:
------------------------------------------------------ Autofs process segfault on startup after upgrading to RHEL6.3 release. last modified by Shijoe Panjikkaran on 07/10/12 - 03:26 Issue
Autofs is getting segfaults after upgrading the autofs package to the 6.3 release Automount segfaults with the following message in logs,
automount[5195]: segfault at 28 ip 00007f0dfe22b862 sp 00007f0e01a7b960 error 4 in lookup_hosts.so[7f0dfe222000+1c000]
Environment
Red Hat Enterprise Linux(RHEL) 6.3 autofs-5.0.5-54.el6.x86_64 ------------------------------------------------------
This leads me to believe that upstream is aware of this issue and someone there is working on a fix.
./Cal
Environment
Red Hat Enterprise Linux(RHEL) 6.3 autofs-5.0.5-54.el6.x86_64
This leads me to believe that upstream is aware of this issue and someone there is working on a fix.
I was reading your posts with Joerg Schillings comments on Linux NFS (in the zfs/xfs/jfs thread) still in the back of my head, for some reason ;)
The changelog entries in upstream's autofs rpm go back thirteen years. One would expect some measure of maturity and stability here, yet autofs is a frequent source of problems. I remember another major problem we ran into somewhere around CentOS 5.2 or 5.3.
On Thu, 2012-08-09 at 10:35 +0100, Lars Hecking wrote:
Environment
Red Hat Enterprise Linux(RHEL) 6.3 autofs-5.0.5-54.el6.x86_64
This leads me to believe that upstream is aware of this issue and someone there is working on a fix.
I was reading your posts with Joerg Schillings comments on Linux NFS (in the zfs/xfs/jfs thread) still in the back of my head, for some reason ;)
The changelog entries in upstream's autofs rpm go back thirteen years. One would expect some measure of maturity and stability here, yet autofs is a frequent source of problems. I remember another major problem we ran into somewhere around CentOS 5.2 or 5.3.
I do see maturity and a great many improvement but I must agree that comparing the change log to bug reports seems to indicate a level of instability. There do seem to be a great many bugs that dump core but this may be the nature of the beast when interacting with the Linux kernel, a constantly moving target. I'm not one to criticize but if software in our organization repeatedly produced segfaults, I'd suggest that developers look closely at improving error traps and handling and/or analyze faults to see if patterns or trends emerge. Still, there are enough alternatives and security features in EL to mitigate most problems.
On Wed, 2012-08-08 at 19:25 -0400, Cal Webster wrote:
On Wed, 2012-08-08 at 18:37 -0400, Cal Webster wrote:
See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id=846852
This leads me to believe that upstream is aware of this issue and someone there is working on a fix.
Yes, and still they released an update that breaks. The same thing happened for sudo on 5.8 even though the selinux permission issue at that time was also known (https://bugzilla.redhat.com/show_bug.cgi?id=818585).
On a side node, if you check the new sudo bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=846631) you will see repeated (automated?) messages from PM telling they will not address this latest issue with sudo. Luckily the maintainers are aware of the issue and as I can only assume working on it.
But all this makes me believe that Red Hat has some serious internal communication issues where essential information is not shared between parties that should be aware of each other.
Regards, Leonard.
-
Cal Webster -
Calvin Webster
-
Lars Hecking -
Leonard den Ottolander