autofs5-ldap regularly crashes after long periods of time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
autofs5 (Ubuntu) |
New
|
Medium
|
Unassigned |
Bug Description
Over the past few months we noticed our web server would no longer serve requests out of directories normally mounted by autofs, which is configured to be backed by LDAP. We knew a reboot would fix the problem temporarily but it would recur after several weeks. We just discovered the problem in the logs:
Jun 19 04:59:07 www1 kernel: [732120.739266] do_general_
Jun 19 04:59:07 www1 kernel: [732120.739272] automount[5810] general protection ip:7f9816a663b1 sp:7f9809fab760 error:0 in libc-2.
Jun 19 04:59:10 www1 kernel: [732123.235552] init: autofs main process (931) killed by SEGV signal
Jun 19 04:59:10 www1 kernel: [732123.235602] init: autofs main process ended, respawning
After the crash, autofs does not respond to restarts via the init scripts. It may after cleaning up the appropriate pid files and such, but I'm not sure what those are.
I examined the .crash file and from a backtrace I assume it must be something wrong with the LDAP portion of autofs:
$> apport-retrace -g automount.crash
GNU gdb (Ubuntu/Linaro 7.4-2012.
...<snip>...
Reading symbols from /usr/sbin/
[New LWP 5810]
...<snip>...
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
Core was generated by `/usr/sbin/
Program terminated with signal 11, Segmentation fault.
#0 0x00007f9816a663b1 in _IO_vfprintf_
1630 vfprintf.c: No such file or directory.
(gdb) bt
#0 0x00007f9816a663b1 in _IO_vfprintf_
#1 0x00007f9816a691a4 in buffered_vfprintf (s=0x7f9816dd5180, format=<optimized out>, args=<optimized out>) at vfprintf.c:2313
#2 0x00007f9816a63bde in _IO_vfprintf_
at vfprintf.c:1316
#3 0x00007f9816b24b08 in ___vfprintf_chk (fp=0x7f9816dd5180, flag=1, format=<optimized out>, ap=<optimized out>) at vfprintf_chk.c:35
#4 0x00007f9815af0996 in log_error () from /usr/lib/
#5 0x00007f9815ae6276 in ?? () from /usr/lib/
#6 0x00007f9815ae7141 in ?? () from /usr/lib/
#7 0x00007f9815ae73fe in ?? () from /usr/lib/
#8 0x00007f9815ae77eb in ?? () from /usr/lib/
#9 0x00007f9815aea641 in lookup_mount () from /usr/lib/
#10 0x00007f98177935f5 in lookup_nss_mount ()
#11 0x00007f9817789c8f in ?? ()
#12 0x00007f981713ee9a in start_thread (arg=0x7f9809fb
#13 0x00007f9816b0f3fd in clone () at ../sysdeps/
#14 0x0000000000000000 in ?? ()
I've attached the .crash file. I'll note that I added the "Package:" line myself to be able to use it with apport-retrace.
I'm still not sure what reproduces the bug if it's something in our LDAP database or not. I was hoping maybe it's some small problem in log_error() that maybe was meaning to tell me something that's wrong with LDAP.
Versions:
Ubuntu: 12.04
autofs5: 5.0.6-0ubuntu5.1
autofs5-ldap: 5.0.6-0ubuntu5.1
information type: | Public → Private Security |
information type: | Private Security → Public |
Changed in autofs5 (Ubuntu): | |
importance: | Undecided → Medium |
This started happening almost daily so we are looking for a fix.
I'm starting to wonder if this is actually a duplicate of Bug #593603
In any case I'm working on figuring out what in our site's LDAP database is causing the crash, if anything.