It just occurred to me that you may be seeing an anomaly in clib's malloc subsystem. I fought with this in early summer, but somehow have not mentioned it in the change log. The change itself was done on June, 22nd 2009. I have just checked, 4.4.2 does not have this code. I noticed that while there were some reports in the valgrind log, they were not large enough to explain what you saw.
The libc malloc issue was discussed on the mailing list, and this here is a link to a later wrap-up type of message: http://lists.adiscon.net/pipermail/rsyslog/2009-June/002372.html So my suggestion is to move to v4-stable and see if the problem persists there (obviously, contrary to what I said, v5 would have fixed it in that case as well - so never trust a dev... ;)). Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Rainer Gerhards > Sent: Tuesday, November 10, 2009 10:53 AM > To: rsyslog-users > Subject: Re: [rsyslog] 4.4.2 leaks: another log > > excellent! I also see some violations, what is a good thing. But I > notice I > unfortunately missed one thing: by default, the violations do not > include the > loadbale module addresses. Would it be possible that you create a > custom > build of rsyslog with the "--enable-valgrind" configure option? That > does not > cause any overhead, but permits to see the function names on exit (and > thus > is really useful). > > Thanks, > Rainer > > > -----Original Message----- > > From: Mr. Demeanour [mailto:[email protected]] > > Sent: Tuesday, November 10, 2009 10:49 AM > > To: Rainer Gerhards > > Subject: 4.4.2 leaks: another log > > > > Hi. > > > > Thanks for all your help. I didn't realise that -n suppressed > SIGKILL. > > I > > also didn't realise that it was taking up to five minutes with -n and > > valgrind, between the successful opening of a UDP listener on 514 and > a > > TCP listener appearing on 10514! That (and my misunderstanding of > > signal > > handling) is why I thought it had hung. > > > > So perhaps something is strange about my certificate. I'll see if I > can > > test it somehow. > > > > Anyway, here is a log apparently showing leakage; it represents about > > 400 TCP messages over 30 minutes. The command was: > > valgrind --leak-check=full /usr/sbin/rsyslogd -c4 -n >rsyslog.log > 2>&1 > > > > By the time I killed it, memory usage had climbed from about 70M to > > 100M. With a non-encrypting rsyslog (and without valgrind), usage is > > stable at around 70M. Here's a "free" while running a non-encrypting > > service: > > > > # free > > total used free shared buffers > > cached > > Mem: 774972 732564 42408 0 22544 > > 641436 > > -/+ buffers/cache: 68584 706388 > > Swap: 1951856 5640 1946216 > > > > The picture remains like that more-or-less indefinitely. > > > > Just before I killed the valgrind run corresponding to that log, it > > looked like this: > > # free > > total used free shared buffers > > cached > > Mem: 774972 766292 8680 0 22016 > > 643940 > > -/+ buffers/cache: 100336 674636 > > Swap: 1951856 5640 1946216 > > > > > > > > Now I know how to do this, I should be able to do it on demand. > Thanks > > again. > > > > -- > > Jack. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
