Re: Runaway Memory in ipop3d on Dual-Processor XEON.
I agree with you that it's a bug in your C library's implementation of getpwnam(), specifically in its NIS (a.k.a. Yellow Pages) routines (note the yp_??? function calls). The idea of those calls is to enable the #public and #shared namespaces if the users imappublic and imapshared respectively exist. Some UNIX systems don't like 10-character userids, but they shouldn't react by consuming 1GB of RAM! If you don't want to use the #public and #shared namespaces, the easiest way to defang this snake is to edit file imap-/src/osdep/unix/env_unix.c (yup, the file that everybody hacks... by design) and look for a line which reads: static short noautomaticsharedns = NIL; Change that line to be: static short noautomaticsharedns = T; Then rebuild. The real fix is to get your C library fixed. I hope that the only reason that the Mandrake people told you to ask here was to get a workaround in ipop3d/imapd from us, pending their being able to fix the C library and get that fix out to you. For future software support issues with UW imapd, you should send your mail to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] ipop3d and imapd are based upon the UW c-client API, and the c-client list is specifically for software issues with that software. The imap list is oriented towards the protocol. Another place to seek out help is the comp.mail.imap newsgroup. Thanks. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Runaway Memory in ipop3d on Dual-Processor XEON.
On Sun, 01 Feb 2004, at 20:27:38, Mark Crispin [EMAIL PROTECTED] wrote: MC The idea of those calls is to enable the MC #public and #shared namespaces if the users MC imappublic and imapshared respectively exist. MC Some UNIX systems don't like 10-character MC userids, but they shouldn't react by consuming MC 1GB of RAM! Ah, this looks like the problem. I did not consider the 10-character userids. I will recompile with noautomaticsharedns=T to workaround the problem. MC The real fix is to get your C library fixed. MC I hope that the only reason that the Mandrake MC people told you to ask here was to get a MC workaround in ipop3d/imapd from us, pending MC their being able to fix the C library and get MC that fix out to you. It was not somebody representing Mandrake Linux, it was another person on the Mandrake Expert list. As it initially presented itself, this bug is very puzzling. The other user suggested that I look for help from the imap group, but they were not suggesting that the ultimate source of the problem was with imap/ipop3d. Indeed, your insights have made the problem much, much clearer to me. Thank you. I agree that the ultimate problem is with the C library. I initially submitted the bug to the glibc mailing list, but have not received any responses. MC For future software support issues with UW MC imapd, you should send your mail to MC [EMAIL PROTECTED] My apologies. I was not sure, but wondered if I was using the correct list. I will redirect future problems to comp.mail.imap or c-client.
