Am 18.09.2012 12:53, schrieb Nico Golde: > Hi, > * Erik Thiele <erik.thi...@thiele-hydraulik.de> [2012-09-18 09:48]: > [...] >> 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? > > This is not known to me at least. Unfortunately the logs don't show that > fetchmail had memory issues. The kernel randomly starts killing processes > (depending on your policy) if no memory can be allocated anymore. > Could you log the virtual memory usage of specifically fetchmail?
at the end of my report you see daily logs of last two days of fetchmail memory consumption. i will continue to log that log to see if it further increases. actually the kernel killed many (174) processes until it finally killed fetchmail, then there where no more oom kills left. since fetchmail is the last to be killed, i suggest that fetchmail was the problem. i found that the system is running "sar" and after examining the data, i found out that the used memory kind of linearly increases over time, until the mega oom-killer burst mentioned above when suddenly all memory was free again. there was only one single kill of fetchmail. i am quite sure that fetchmail must be the process that used all system memory here. > Also, it may be interesting to see what running fetchmail with valgrind on > your end produces. Can you test that? does this mean take debian source package, recompile with debug flags, run under valgrind and terminate after two days with valgrind option show-reachable or so and send you that output then? or is there an easier way? Please consider it's a production system on a non-IT company which should just run... cya erik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
