Package: fetchmail
Version: 6.3.18-2
/etc/fetchmailrc:
set daemon 30
set syslog
set no bouncemail
set no spambounce
set no softbounce
poll pop.myprovider.de proto pop3 user myusern...@mypublicdomain.de pass
MYSECRETPASS smtphost mail.myinternaldomain.lan smtpname
myusern...@myinternaldomain.lan fetchall
END OF /etc/fetchmailrc
the poll line above is repeated another 13 times with different usernames.
ps axuw|grep fetchmail
105 910 0.0 14.5 84756 74956 ? Ss Sep13 6:31
/usr/bin/fetchmail --bad-header accept -f /etc/fetchmailrc --pidfile
/var/run/fetchmail/fetchmail.pid --syslog
as can be seen, fetchmail is running as daemon. It has been manually
started on September 13, because the old instance was killed because of
kernel OOM (out of memory) kill. see:
Sep 12 07:03:50 mail kernel: [8986062.350113] fetchmail invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 12 07:03:50 mail kernel: [8986062.350117] fetchmail cpuset=/
mems_allowed=0
Sep 12 07:03:50 mail kernel: [8986062.350119] Pid: 1444, comm: fetchmail
Not tainted 2.6.32-5-686 #1
Sep 12 07:03:50 mail kernel: [8986062.350121] Call Trace:
Sep 12 07:03:50 mail kernel: [8986062.350127] [<c1089a78>] ?
oom_kill_process+0x60/0x201
Sep 12 07:03:50 mail kernel: [8986062.350130] [<c1089ff5>] ?
__out_of_memory+0xf4/0x107
Sep 12 07:03:50 mail kernel: [8986062.350132] [<c108a062>] ?
out_of_memory+0x5a/0x7c
Sep 12 07:03:50 mail kernel: [8986062.350135] [<c108c90d>] ?
__alloc_pages_nodemask+0x3ef/0x4d9
Sep 12 07:03:50 mail kernel: [8986062.350138] [<c108dced>] ?
__do_page_cache_readahead+0x98/0x16b
Sep 12 07:03:50 mail kernel: [8986062.350140] [<c108ddd4>] ?
ra_submit+0x14/0x18
Sep 12 07:03:50 mail kernel: [8986062.350142] [<c1088392>] ?
filemap_fault+0x16d/0x2e6
Sep 12 07:03:50 mail kernel: [8986062.350144] [<c109a0b2>] ?
__do_fault+0x47/0x3b1
Sep 12 07:03:50 mail kernel: [8986062.350147] [<c109c076>] ?
handle_mm_fault+0x48f/0x959
Sep 12 07:03:50 mail kernel: [8986062.350150] [<c126dfa6>] ?
schedule+0x78f/0x7dc
Sep 12 07:03:50 mail kernel: [8986062.350153] [<c1270d90>] ?
do_page_fault+0x2f1/0x307
Sep 12 07:03:50 mail kernel: [8986062.350155] [<c1270a9f>] ?
do_page_fault+0x0/0x307
Sep 12 07:03:50 mail kernel: [8986062.350157] [<c126f2f3>] ?
error_code+0x73/0x78
so I started a memory log:
2012-09-17 11,7% VIRT=63852 RES=60316 SHR=1888
2012-09-18 14,6% VIRT=84760 RES=74952 SHR=1884
so again it seems to run until oom death.
the machine is a virtual machine with 512MB ram + 1GB swap:
erik@mail:~$ free
total used free shared buffers cached
Mem: 514728 503600 11128 0 81100 237232
-/+ buffers/cache: 185268 329460
Swap: 1048568 2080 1046488
how can I further supply information on this issue? It is a production
machine, but maybe I can somehow help find the cause of the issue
anyway? Or is that memory leakage a known issue?
cya
Erik
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
