Dear syslog-ng users, The download location for syslog-ng sources is being changed due to internal web reorganization. In the future, syslog-ng sources will be available from: http://www.balabit.com/products/syslog-ng/sources/ instead of the old download location. The location of the upgrade summary page will not be changed, and will remain: http://www.balabit.com/products/syslog-ng/opensource/upgrades/ Sorry, for the possible inconvinience. -- Balazs Scheidler <bazsi@balabit.hu>
cool thanks. On Thu, 2007-05-24 at 14:39 +0200, Balazs Scheidler wrote:
Dear syslog-ng users,
The download location for syslog-ng sources is being changed due to internal web reorganization. In the future, syslog-ng sources will be available from:
http://www.balabit.com/products/syslog-ng/sources/
instead of the old download location.
The location of the upgrade summary page will not be changed, and will remain:
http://www.balabit.com/products/syslog-ng/opensource/upgrades/
Sorry, for the possible inconvinience.
-- Hiren Patel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail and its contents are subject to the Telkom SA Limited e-mail legal notice available at http://www.telkom.co.za/TelkomEMailLegalNotice.PDF ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Thu, May 24, 2007 at 02:39:58PM +0200, Balazs Scheidler wrote:
Dear syslog-ng users,
The download location for syslog-ng sources is being changed due to internal web reorganization. In the future, syslog-ng sources will be available from:
I get a 404 at that URL. Should the FAQ just link to http://www.balabit.com/products/syslog-ng/ ? -- Nate "E-mail - When it absolutely, positively has to get lost at the speed of light." - Jerry Vuoso.
On Thu, 2007-05-24 at 07:13 -0700, Nate Campi wrote:
On Thu, May 24, 2007 at 02:39:58PM +0200, Balazs Scheidler wrote:
Dear syslog-ng users,
The download location for syslog-ng sources is being changed due to internal web reorganization. In the future, syslog-ng sources will be available from:
I completely messed up, sorry. The correct URL: http://www.balabit.com/downloads/files/syslog-ng/sources/ I copy/pasted this URL from my browser this time.
I get a 404 at that URL. Should the FAQ just link to http://www.balabit.com/products/syslog-ng/ ?
Yes, that should be the main entry point for syslog-ng. -- Bazsi
I've noticed a small memory leak when syslog-ng handles a SIGHUP. A bit of valgrind-ing gave me the following result for syslog-ng without any SIGHUPs 1,004 (652 direct, 352 indirect) bytes in 7 blocks are definitely lost in loss record 9 of 16 ==11308== at 0x402C9C0: calloc (in /opt/4/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) ==11308== by 0x40B9CF4: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1101.0) ==11308== by 0x1000C73C: affile_dd_new (affile.c:607) ==11308== by 0x10007A80: yyparse (cfg-grammar.y:478) ==11308== by 0x1000528C: cfg_new (cfg.c:284) ==11308== by 0x100042D0: main (main.c:424) ==11308== By inspection I see that the call tree from cfg_new (cfg.c:284) upwards applies when a SIGHUP is handled so I'm guessing this may be the cause. I don't know how to send a SIGHUP to an app that is running under valgrind, so I haven't confirmed this. The interesting thing is that the size of the leak I'm seeing is a lot smaller (4-8bytes) than the amount I would expect if the chunk allocated in affile_dd_new is getting lost. I'm running a snapshot from 2.0.0 - 2.0.0+20061212. I check the release note for 2.0.4 but didn't see any mention of memory leak fixes. Can anyone help please? Regards Anthony
On Fri, 2007-07-06 at 17:18 +1200, anthony lineham wrote:
I've noticed a small memory leak when syslog-ng handles a SIGHUP.
A bit of valgrind-ing gave me the following result for syslog-ng without any SIGHUPs 1,004 (652 direct, 352 indirect) bytes in 7 blocks are definitely lost in loss record 9 of 16 ==11308== at 0x402C9C0: calloc (in /opt/4/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) ==11308== by 0x40B9CF4: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1101.0) ==11308== by 0x1000C73C: affile_dd_new (affile.c:607) ==11308== by 0x10007A80: yyparse (cfg-grammar.y:478) ==11308== by 0x1000528C: cfg_new (cfg.c:284) ==11308== by 0x100042D0: main (main.c:424) ==11308==
By inspection I see that the call tree from cfg_new (cfg.c:284) upwards applies when a SIGHUP is handled so I'm guessing this may be the cause. I don't know how to send a SIGHUP to an app that is running under valgrind, so I haven't confirmed this.
The interesting thing is that the size of the leak I'm seeing is a lot smaller (4-8bytes) than the amount I would expect if the chunk allocated in affile_dd_new is getting lost.
I'm running a snapshot from 2.0.0 - 2.0.0+20061212.
I check the release note for 2.0.4 but didn't see any mention of memory leak fixes.
You only seek leaks when SIGHUP is sent, or also during normal operation? -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> 07/06/07 11:54 PM >>> On Fri, 2007- 07- 06 at 17:18 +1200, anthony lineham wrote: I've noticed a small memory leak when syslog- ng handles a SIGHUP.
A bit of valgrind- ing gave me the following result for syslog- ng without any SIGHUPs 1,004 (652 direct, 352 indirect) bytes in 7 blocks are definitely lost in loss record 9 of 16 ==11308== at 0x402C9C0: calloc (in /opt/4/lib/valgrind/ppc32- linux/vgpreload_memcheck.so) ==11308== by 0x40B9CF4: g_malloc0 (in /usr/lib/libglib- 2.0.so.0.1101.0) ==11308== by 0x1000C73C: affile_dd_new (affile.c:607) ==11308== by 0x10007A80: yyparse (cfg- grammar.y:478) ==11308== by 0x1000528C: cfg_new (cfg.c:284) ==11308== by 0x100042D0: main (main.c:424) ==11308==
By inspection I see that the call tree from cfg_new (cfg.c:284) upwards applies when a SIGHUP is handled so I'm guessing this may be the cause. I don't know how to send a SIGHUP to an app that is running under valgrind, so I haven't confirmed this.
The interesting thing is that the size of the leak I'm seeing is a lot smaller (4- 8bytes) than the amount I would expect if the chunk allocated in affile_dd_new is getting lost.
I'm running a snapshot from 2.0.0 - 2.0.0+20061212.
I check the release note for 2.0.4 but didn't see any mention of memory leak fixes.
You only seek leaks when SIGHUP is sent, or also during normal operation?
I'm only seeing the leak when SIGHUP is sent. I haven't noticed anything associated with normal operation.
Hi Bazsi, I've finally found the memory leak I noticed when syslog-ng handles a SIGHUP. It turned out that there were 3 leaks. They are not very big so perhaps not significant for most users but in my system there is limited memory and frequent use of SIGHUP. I've attached a patch that I believe resolves the leaks. Valgrind seems to like it. However please let me know if there are any problems with it. This is the first time I've really gotten into the code so I'm sure I may have overlooked something. Please note that my original fix was made and tested on 2.0.0+20061212, but the attached patch is for 2.0.4. I didn't notice any differences that would seem to impact the fix, but I may have missed something. Here's a description of the changes: cfg-grammar.y cfg-grammar.c - The template reference counter gets incremented in the template lookup function, so remove the second increment here. Otherwise the counter never gets back to 0 and the template won't be able to be deleted. affile.c affile_dd_deinit: + Unreference the writer after de-initing it. The unreference will cause the writer to be deleted, which causes it to unreference this destination driver (a circular reference). When the call to affile_dd_free is made via cfg_free() the ref counter will be 1, allowing a final decrement and hence the removal of the destination diver. Previously the counter was 2 due to the writer reference, which prevented the destination driver from being removed. templates.c + When freeing a template also deallocate the memory used by a compiled template. regards Anthony
"anthony lineham" <anthony.lineham@alliedtelesis.co.nz> 07/09/07 8:56 AM >>>
Balazs Scheidler <bazsi@balabit.hu> 07/06/07 11:54 PM >>> On Fri, 2007- 07- 06 at 17:18 +1200, anthony lineham wrote: I've noticed a small memory leak when syslog- ng handles a SIGHUP.
A bit of valgrind- ing gave me the following result for syslog- ng without any SIGHUPs 1,004 (652 direct, 352 indirect) bytes in 7 blocks are definitely lost in loss record 9 of 16 ==11308== at 0x402C9C0: calloc (in /opt/4/lib/valgrind/ppc32- linux/vgpreload_memcheck.so) ==11308== by 0x40B9CF4: g_malloc0 (in /usr/lib/libglib- 2.0.so.0.1101.0) ==11308== by 0x1000C73C: affile_dd_new (affile.c:607) ==11308== by 0x10007A80: yyparse (cfg- grammar.y:478) ==11308== by 0x1000528C: cfg_new (cfg.c:284) ==11308== by 0x100042D0: main (main.c:424) ==11308==
By inspection I see that the call tree from cfg_new (cfg.c:284) upwards applies when a SIGHUP is handled so I'm guessing this may be the cause. I don't know how to send a SIGHUP to an app that is running under valgrind, so I haven't confirmed this.
The interesting thing is that the size of the leak I'm seeing is a lot smaller (4- 8bytes) than the amount I would expect if the chunk allocated in affile_dd_new is getting lost.
I'm running a snapshot from 2.0.0 - 2.0.0+20061212.
I check the release note for 2.0.4 but didn't see any mention of memory leak fixes.
You only seek leaks when SIGHUP is sent, or also during normal operation?
I'm only seeing the leak when SIGHUP is sent. I haven't noticed anything associated with normal operation. _______________________________________________ syslog- ng maillist - syslog- ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog- ng Frequently asked questions at http://www.campin.net/syslog- ng/faq.html
Thanks for your contribution. Can you please sign and fax a copy of our contribution license agreement at http://www.balabit.com/dl/CLA_patch.pdf to +36 1 208 08 75 This allows us to include your contribution. Thanks. On Fri, 2007-07-13 at 09:51 +1200, anthony lineham wrote:
anthony lineham <anthony.lineham@alliedtelesis.co.nz> -- Bazsi
Hi Bazsi, I have just faxed through a signed copy of the contribution license agreement. It is in the name of my employer, Allied Telesis Labs. Please confirm that have received it. Best regards, Anthony Lineham
Balazs Scheidler <bazsi@balabit.hu> 07/14/07 5:54 AM >>> Thanks for your contribution. Can you please sign and fax a copy of our contribution license agreement at
http://www.balabit.com/dl/CLA_patch.pdf to +36 1 208 08 75 This allows us to include your contribution. Thanks. On Fri, 2007- 07- 13 at 09:51 +1200, anthony lineham wrote:
anthony lineham <anthony.lineham@alliedtelesis.co.nz> -- Bazsi
_______________________________________________ syslog- ng maillist - syslog- ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog- ng Frequently asked questions at http://www.campin.net/syslog- ng/faq.html
When syslog-ng has been configured to use a program destination, is seems that the program is launched prior to syslog-ng "deamonizing" itself. Normally the code for deamons is something like fork if I am parent process then exit continue code as child process with parent now init (1) Syslog-ng seems to be doing this; start program destinations fork if I am parent process then exit continue code as child process with parent now init (1) when it should be doing fork if I am parent process then exit continue code as child process with parent now init (1) start program destinations If I reload syslog-ng then the program destination has the parent process of syslong-ng which is correct. Evan.
On Wed, 2007-07-18 at 22:04 -0700, Evan Rempel wrote:
When syslog-ng has been configured to use a program destination, is seems that the program is launched prior to syslog-ng "deamonizing" itself.
Normally the code for deamons is something like
This is true. syslog-ng wants to return a status code to the calling shell, whether initializing the configuration was successful or not. Therefore the parent only exits once this information is available. Hmm.hmm. now as I think of it, I could borrow some code from Zorp, that uses a pipe to communicate exit status, but otherwise it is the child that initializes the configuration. Continuing thinking somewhat, syslog-ng 1.6 had somewhat similar code, checking it out.... Yes, you are right. syslog-ng 1.6 did the same trick as Zorp, it communicated the exit status to the parent process via a pipe, but the complete initialization stuff was performed by the child. I'll write a ticket about this to myself. -- Bazsi
On Thu, 2007-07-19 at 16:58 +1200, anthony lineham wrote:
Hi Bazsi,
I have just faxed through a signed copy of the contribution license agreement. It is in the name of my employer, Allied Telesis Labs.
Please confirm that have received it.
We did. Thanks very much. I'm going to integrate your patch as soon as possible. -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> 07/14/07 5:54 AM >>> Thanks for your contribution. Can you please sign and fax a copy of our contribution license agreement at
http://www.balabit.com/dl/CLA_patch.pdf to +36 1 208 08 75 This allows us to include your contribution. Thanks. On Fri, 2007- 07- 13 at 09:51 +1200, anthony lineham wrote:
anthony lineham <anthony.lineham@alliedtelesis.co.nz> -- Bazsi
_______________________________________________ syslog- ng maillist - syslog- ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog- ng Frequently asked questions at http://www.campin.net/syslog- ng/faq.html
On Fri, 2007-07-13 at 09:51 +1200, anthony lineham wrote:
Hi Bazsi,
I've finally found the memory leak I noticed when syslog-ng handles a SIGHUP. It turned out that there were 3 leaks. They are not very big so perhaps not significant for most users but in my system there is limited memory and frequent use of SIGHUP.
I've attached a patch that I believe resolves the leaks. Valgrind seems to like it. However please let me know if there are any problems with it. This is the first time I've really gotten into the code so I'm sure I may have overlooked something.
Please note that my original fix was made and tested on 2.0.0+20061212, but the attached patch is for 2.0.4. I didn't notice any differences that would seem to impact the fix, but I may have missed something.
Here's a description of the changes: cfg-grammar.y cfg-grammar.c - The template reference counter gets incremented in the template lookup function, so remove the second increment here. Otherwise the counter never gets back to 0 and the template won't be able to be deleted.
This was correct, I applied the fix unchanged.
affile.c affile_dd_deinit: + Unreference the writer after de-initing it. The unreference will cause the writer to be deleted, which causes it to unreference this destination driver (a circular reference). When the call to affile_dd_free is made via cfg_free() the ref counter will be 1, allowing a final decrement and hence the removal of the destination diver. Previously the counter was 2 due to the writer reference, which prevented the destination driver from being removed.
I did not apply this one yet. I started working on an issue reported by Evan Rempel in the same area, and I want to finish that first. I will try to cover this leak in that work too.
templates.c + When freeing a template also deallocate the memory used by a compiled template.
I changed this slightly, but also applied. Thanks for the thourough analysis of the leaks, and the fixes. I've pushed the git archive to my public repository, so it should be available there, or in tomorrow's snapshot. -- Bazsi
participants (5)
-
anthony lineham
-
Balazs Scheidler
-
Evan Rempel
-
Hiren Patel
-
Nate Campi