I'm trying to configure a dual-processor, 2.4GHz
Xeon box as an email server, running Postfix et
al. under Mandrake 9.2
I'm having an odd problem with two applications,
ipop3d and imapd. During login negotiation, the
daemon starts allocating as much memory as it can,
until system limits are reached. Initially, there
were no limits, and ipop3d ran up over a gigabyte
of memory.
I tried running the ipop3d binary from Mandrake
9.1 with the same results. I also tried upgrading
to the Mandrake Cooker version of ipop3d, with no
improvement. This makes me think that the problem
is glibc related.
I was able to run ipop3d interactively under gdb.
When it started consuming memory, I killed the
process and got the following trace:
# gdb /usr/sbin/ipop3d
GNU gdb 5.3-25mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...(no debugging symbols
found)...
(gdb) r
Starting program: /usr/sbin/ipop3d
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
+OK POP3 lxsrv2.cccma.bc.ec.gc.ca v2003.83mdk server ready
user testuser
+OK User name accepted, password please
pass XXXXXXXX
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGTERM, Terminated.
0x4010a862 in socket () from /lib/i686/libc.so.6
(gdb) where
#0 0x4010a862 in socket () from /lib/i686/libc.so.6
#1 0x40129b6b in clntudp_bufcreate () from /lib/i686/libc.so.6
#2 0x40129c84 in clntudp_create () from /lib/i686/libc.so.6
#3 0x4017d865 in yp_update () from /lib/libnsl.so.1
#4 0x4017db15 in yp_update () from /lib/libnsl.so.1
#5 0x4017c96e in yp_match () from /lib/libnsl.so.1
#6 0x4001b896 in _nss_nis_getpwnam_r () from /lib/libnss_nis.so.2
#7 0x400d9195 in getpwnam_r () from /lib/i686/libc.so.6
#8 0x400d8bef in getpwnam () from /lib/i686/libc.so.6
#9 0x080518da in responder ()
#10 0x08051224 in responder ()
#11 0x0805100a in responder ()
#12 0x0804ce90 in trmint ()
#13 0x0804c2ea in strcpy ()
#14 0x40044c57 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
This indicates a problem in getpwnam and the NIS
routines. There other programs (e.g. ftpd) which
call getpwnam, but which are not affected by this
problem. However, I was able to replicate the bug
with the program useradd, so it does not seem to
be ipop3d specific.
After compiling ipop3d from scratch, I stepped
through the execution with gdb. The problem
occurs when ipop3d looks up two passwd entries:
/* #public namespace */
if (!publicHome
&& (pw = getpwnam ("imappublic")))
publicHome = cpystr (pw->pw_dir);
/* #shared namespace */
if (!anonymous
&& !sharedHome
&& (pw = getpwnam ("imapshared")))
sharedHome = cpystr (pw->pw_dir);
If either of these users does not exist, then
ipop3d goes into loop mode, and consumes all
available memory. If both users exist,
ipop3d functions correctly.
Interestingly, ipop3d also does not hang if the
two imap users exist, but the userid logging in
does not. You get the expected failed login, but
no wild consumption of system resources.
At this point, I don't know if the problem is with
ipop3d or glibc or something else.
I have posted this problem to the glibc bug list,
(which seems to mostly be full of SPAM - Sigh) and
the Mandrake Expert list, who said I should post
it on the imap list
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
