I have (had?) exactly the same problem. When I was using 0.57 my server (which is *very* busy) would run out of RAM/swap about once every three months or so resulting in a fairly nasty situation which was easiest to resolve by just pushing the reset button on the machine (couldn't ssh in, console barely responded, ect). After a few weeks of unattended operation, courier-authlib would be consuming 2Gb or so of virtual memory. I settled on a cron job to restart it weekly and have had zero problems since then.
I've since upgraded to 0.59 but I haven't disabled the cronjob. I'd rather just let it restart weekly than have a problem with the machine. My machine is CentOS 4.5 running on an Intel Xeon 2.0Ghz (Northwood) in a Dell 1600SC, 2GB physical memory. - Nick Bright > I have a fairly new install of netqmail-1.05-r8 / courier-imap-4.0.6-r2 / > vpopmail-5.4.16. The system has ran fine except for two instances of > memory > usage (leak?). This system is setup on a Gentoo server according to the > guide located at: > > http://www.gentoo.org/doc/en/qmail-howto.xml > > courier-imap is configured with the following authentication: > > authmodulelist="authvchkpw" (located in > /etc/courier/authlib/authdaemonrc) > > On both occasions the process list shows something similar to the > following > > top - 07:19:19 up 67 days, 5:59, 1 user, load average: 0.09, 0.10, 0.08 > Tasks: 111 total, 1 running, 110 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.8% us, 0.7% sy, 0.0% ni, 97.2% id, 0.3% wa, 0.0% hi, 0.0% > si > Mem: 1034092k total, 1007388k used, 26704k free, 11688k buffers > Swap: 1001464k total, 999832k used, 1632k free, 127600k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 5279 root 15 0 353m 140m 408 S 0 13.9 0:47.04 authdaemond > 5276 root 15 0 353m 139m 68 S 0 13.8 0:45.59 authdaemond > 5278 root 15 0 349m 135m 408 S 0 13.4 0:45.86 authdaemond > 5277 root 15 0 349m 135m 20 S 0 13.4 0:46.17 authdaemond > 5275 root 15 0 356m 132m 20 S 0 13.2 0:46.32 authdaemond > > > As seen above my main memory and swap was in bad shape with authdaemond > processes consuming the bulk of the memory. Review of the logs does not > show > any errors against authdaemond or authvchkpw. Memory usage appears to > shoot up > rapidly as this problem will manifest itself in less than a days time > (it is not > a gradual increase in memory usage). > > Any guidance on determining and/or fixing the root cause of the > authdaemond > memory issue would be welcome. The courier-imap mailing list directed me > here > stating that the authvchkpw module is the likely culprit. >
