Hmmm - so what did you do to fix? Tracing processes is a little beyond my level.
I understand the concept, but haven't done this on this on any *nix. I did check that there were no limits for the courier user though... set a shell for the user and ran ulimit - it returns "unlimited" - also checked the login.conf - no limits in effect that I can see. Even if I could find that a process was asking for too much memory though (which doesn't make sense at present given the lack of limits) not sure what I'd do about it. Could it be a file handle limit? What would I check there? Any more tips? Thanks again. m/ -----Original Message----- From: Gordon Messmer [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 5:46 PM To: Mitch (WebCob) Cc: Courier Users Subject: Re: [courier-users] gdbm fatal: couldn't init cache -- any idea of the source? Mitch (WebCob) wrote: > > I've got a few hundred MB free, 100% processor idle, lots of disk space in > all partitions... > > What kind of resource? The kinds that are sometimes limited by ulimit(), or other artificial limitations. > Any suggestion what to do about it? No. I never figured out what was causing the failure. For some reason, gdbm can't allocate memory for its bucket cache. You could trace the process and find out which malloc is failing (returning NULL), and how much memory was requested. You'll need to attach to the smtpd process before the HELO command, and trace the child submit process. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
