I have a fairly new install of courier-imap. Since installation the system
has ran flawlessly (67 days) until last night. This system is setup on a
gentoo server according to the guide located at:
http://www.gentoo.org/doc/en/qmail-howto.xml
The state of the system this morning (before repair) showed 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. The high memory usage caused oom-killer to
run several times (abbreviated log messages)
Aug 9 05:04:16 [EMAIL PROTECTED] init invoked oom-killer: gfp_mask=0x201d2,
order=0, oomkilladj=0
Aug 9 05:04:16 [EMAIL PROTECTED] syslog-ng invoked oom-killer:
gfp_mask=0x201d2,
order=0, oomkilladj=0
Aug 9 05:04:16 [EMAIL PROTECTED] resolver invoked oom-killer: gfp_mask=0x201d2,
order=0, oomkilladj=0
Aug 9 05:04:16 [EMAIL PROTECTED] init invoked oom-killer: gfp_mask=0x201d2,
order=0, oomkilladj=0
...
20 more of these
This resulted in the following actions as well
Aug 9 05:13:02 [EMAIL PROTECTED] Killed process 12227 (mysqld)
Aug 9 05:13:02 [EMAIL PROTECTED] Killed process 12117 (apache2)
Somehow apache2 restarted but mysql was down for good. To repair everything
I was able to do:
/etc/init.d/courier-authlib restart
and then restart mysql as well. For good measure I restarted the
courier-imapd-ssl and courier-pop3d-ssl processes.
Now the system looks like this (with 6 authdaemond processes now, instead of
5)
top - 09:09:16 up 67 days, 7:49, 1 user, load average: 0.05, 0.05, 0.06
Tasks: 121 total, 2 running, 119 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.5% us, 0.2% sy, 0.0% ni, 98.3% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1034092k total, 797056k used, 237036k free, 51864k buffers
Swap: 1001464k total, 14004k used, 987460k free, 447288k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17662 root 18 0 4856 1156 872 S 0 0.1 0:00.00 authdaemond
17666 root 15 0 5920 2300 928 S 0 0.2 0:00.09 authdaemond
17667 root 16 0 6044 2316 928 S 0 0.2 0:00.06 authdaemond
17668 root 16 0 5528 1900 932 S 0 0.2 0:00.06 authdaemond
17669 root 16 0 6292 2592 928 S 0 0.3 0:00.15 authdaemond
17670 root 16 0 5792 2136 928 S 0 0.2 0:00.09 authdaemond
software versions
2.6.20-gentoo-r6
courier-authlib-0.58
courier-imap-4.0.6-r2
Any guidance on determining and/or fixing the root cause of the authdaemond
memory issue would be welcome.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
