syslog-ng 3.3.7 RC1 (3.3.6.90) released
Hi! As promised earlier, I prepared a release candidate for the upcoming syslog-ng 3.3.7 release (due october 31), with the most pressing bugs already fixed. Testing this release candidate and reporting any and all issues found with it - be those regressions or anything else - would be greatly appreciated! The current state of the NEWS file is included below, and if anyone wants to track how the release is progressing and what needs to be fixed still before the final release, see the 3.3.7 target milestone on bugzilla: https://bugzilla.balabit.com/buglist.cgi?query_format=advanced&target_milest... The release is available from the following sources: GitHub ------ The release is tagged as v3.3.6.90 on the official repository at git://github.com/balabit/syslog-ng-3.3.git Tarball ------- A make dist tarball built from the same tag is available from my package repository: http://packages.madhouse-project.org/syslog-ng/3.3/3.3.6.90/syslog-ng-3.3.6.... And finally, the NEWS file from the release: 3.3.6.90 (3.3.7 RC1) Thu, 06 Sep 2012 14:00:00 +0200 Bugfixes ======== * The bundled ivykis has been updated to fix two bugs found after the 3.3.6 release was tagged: * Fixed a Solaris-specific issue relating to TCP sources [#190] * Fixed a spinlock issue, triggered on at least FreeBSD [#193] * The glob-based configuration file inclusion was fixed to behave similarly to including a whole directory, to include files alphabetically. [#191] * Fixed a crash when trying to display the available modules in debug mode. [#189] * Fixed the building of afsocket-notls, so that it is correctly built without TLS support. [#188] * Fix compilation without spoof-source. [#192] Credits ======= syslog-ng is developed as a community project, and as such it relies on volunteers to do the work necessarily to produce syslog-ng. Reporting bugs, testing changes, writing code or simply providing feedback are all important contributions, so please if you are a user of syslog-ng, contribute. These people have helped in this release: Balazs Scheidler <bazsi@balabit.hu> Cy Schubert <cy@FreeBSD.org> Dave Reisner <dreisner@archlinux.org> Gergely Nagy <algernon@balabit.hu> Jose Pedro Oliveira <jpo@di.uminho.pt> Lennert Buytenhek <buytenh@wantstofly.org> Marvin Nipper <marvin.nipper@stream.com> Peter Czanik <czanik@balabit.hu> Tamas Pal <folti@balabit.hu> -- |8]
As positive feedback and FYI: I have this running on Solaris 10 x86, and compiled with these options: --enable-spoof-source --enable-dynamic-linking --enable-tcp-wrapper=no --localstatedir=/usr/local/syslog-ng --enable-debug (i.e. not using any back-end databases, or anything like that) And, this compiled fine, and appears to be running fine at this point. -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Gergely Nagy Sent: Thursday, September 06, 2012 5:48 AM To: Syslog-ng users' and developers' mailing list Subject: [syslog-ng] syslog-ng 3.3.7 RC1 (3.3.6.90) released Hi! As promised earlier, I prepared a release candidate for the upcoming syslog-ng 3.3.7 release (due october 31), with the most pressing bugs already fixed. Testing this release candidate and reporting any and all issues found with it - be those regressions or anything else - would be greatly appreciated! The current state of the NEWS file is included below, and if anyone wants to track how the release is progressing and what needs to be fixed still before the final release, see the 3.3.7 target milestone on bugzilla: https://bugzilla.balabit.com/buglist.cgi?query_format=advanced&target_milest... The release is available from the following sources: GitHub ------ The release is tagged as v3.3.6.90 on the official repository at git://github.com/balabit/syslog-ng-3.3.git Tarball ------- A make dist tarball built from the same tag is available from my package repository: http://packages.madhouse-project.org/syslog-ng/3.3/3.3.6.90/syslog-ng-3.3.6.... And finally, the NEWS file from the release: 3.3.6.90 (3.3.7 RC1) Thu, 06 Sep 2012 14:00:00 +0200 Bugfixes ======== * The bundled ivykis has been updated to fix two bugs found after the 3.3.6 release was tagged: * Fixed a Solaris-specific issue relating to TCP sources [#190] * Fixed a spinlock issue, triggered on at least FreeBSD [#193] * The glob-based configuration file inclusion was fixed to behave similarly to including a whole directory, to include files alphabetically. [#191] * Fixed a crash when trying to display the available modules in debug mode. [#189] * Fixed the building of afsocket-notls, so that it is correctly built without TLS support. [#188] * Fix compilation without spoof-source. [#192] Credits ======= syslog-ng is developed as a community project, and as such it relies on volunteers to do the work necessarily to produce syslog-ng. Reporting bugs, testing changes, writing code or simply providing feedback are all important contributions, so please if you are a user of syslog-ng, contribute. These people have helped in this release: Balazs Scheidler <bazsi@balabit.hu> Cy Schubert <cy@FreeBSD.org> Dave Reisner <dreisner@archlinux.org> Gergely Nagy <algernon@balabit.hu> Jose Pedro Oliveira <jpo@di.uminho.pt> Lennert Buytenhek <buytenh@wantstofly.org> Marvin Nipper <marvin.nipper@stream.com> Peter Czanik <czanik@balabit.hu> Tamas Pal <folti@balabit.hu> -- |8] ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
I would like to see a program style destination that uses macro expansion. I would like to have arguments to my program that can bake use of tags, dates, facilities etc. Examples of this are statistical type calculators. For example, I may want to count the messages for each 1 minute interval. Having a script that merely counts them, and calling it with an argument of the hour:min I could reuse the same program for every minute and I don't have to wast CPU in parsing the hour/minute again. Also, if messages arrive with slightly different time stamps, they would appear to be out of order with regards to the time stamp. Using syslog-ng to separate these streams and sending them to the program would save CPU. Currently program destinations are started and restarted even if there are no messages being delivered to them. Program destinations should follow the same reaping and starting rules as open files. Currently, getting the statistics via the syslog-ng-ctl program, program destinations do NOT have $var names expanded. This means that the static destination name looks like dst.program;d_statistics#0;/usr/local/sbin/syslog-ng-stats $SYSLOG_INSTANCE $SYSLOG_CONTROL;a;dropped;0 which is not very useful. I would propose a new destination type for this, perhaps "executable", but if you feel that the "program" destination should be augmented, I would suggest that the current use of $var for environment variables be changed to an escape, such as program("/my/path/to/program $macro \$env_var") Thanks for all of the good things in syslog-ng. We couldn't live without it, but I think there is still room for growth. Evan.
I thing it would be very useful to use the statistics to determine how close the buffering has gotten to the limit of the log_fifo_size before messages start being dropped. This information can be used to; - proactively change the configuration on a host. - calculate the rate of buffer consumption and predict how much time will elapse before dropping will start. Alerts to system operators can be created prior to messages being dropped. This information can be calculated from having the number of messages queued, and the log_fifo_size for the destination, or a percentage full could be used. I would prefer the log_fifo_size. I would also prefer to see all of the stats for a destination on a single line. Programaticaly it is easier to split the numbers up than it is the try to join them back together based on the first three fields of a stat line dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;dropped;0 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;processed;326 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;stored;0 Something like dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000,1347143526 where the 4 numbers are dropped, processed, stored, fifo_size and stamp or two different formats, one for source and one for destination src.file;local#2;/proc/kmsg;a;1549;1347143526 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000 where src has processed and stamp dst has dropped, processed, stored, fifo_size Possibly the source could also show the flow-control state as well, or even better, the flow control duration, so if a source has been blocked for x number of seconds I can alert an operations center about the condition. Thanks again for your consideration. Evan.
----- Original message -----
I thing it would be very useful to use the statistics to determine how close the buffering has gotten to the limit of the log_fifo_size before messages start being dropped. This information can be used to;
hmm. IIRC there's a stored counter that measures how much messages are stored in a queue. I'm unable to check the source right now, and this is only a vague recollection, or might be a pe feature I stumbled upon.
- proactively change the configuration on a host. - calculate the rate of buffer consumption and predict how much time will elapse before dropping will start. Alerts to system operators can be created prior to messages being dropped.
This information can be calculated from having the number of messages queued, and the log_fifo_size for the destination, or a percentage full could be used.
I would prefer the log_fifo_size.
I would also prefer to see all of the stats for a destination on a single line. Programaticaly it is easier to split the numbers up than it is the try to join them back together based on the first three fields of a stat line
dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;dropped;0 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;processed;326 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;stored;0
huh, this is the stored counter I was referring to above. so it definitely exists, the question remains if it gets updated properly.
Something like
dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000,1347143526
where the 4 numbers are dropped, processed, stored, fifo_size and stamp or two different formats, one for source and one for destination
src.file;local#2;/proc/kmsg;a;1549;1347143526 dst.file;d_var_syslog#0;/var/log/syslog.20120908.000000;a;0;326;0;5000
this could probably be done, although a little problematic to extend, and would break applications that relied on the current format. perhaps a separate stats switch could trigger this alternate format.
where src has processed and stamp dst has dropped, processed, stored, fifo_size
Possibly the source could also show the flow-control state as well, or even better, the flow control duration, so if a source has been blocked for x number of seconds I can alert an operations center about the condition.
like the longest 'blocking period' since the start of syslog-ng. this could be monitored easily.
Thanks again for your consideration.
good ideas in general, and shouldn't be difficult either. I'm somewhat overwhelmed these days.
On 09/06/2012 01:47 PM, Gergely Nagy wrote:
Hi!
As promised earlier, I prepared a release candidate for the upcoming syslog-ng 3.3.7 release (due october 31), with the most pressing bugs already fixed. Testing this release candidate and reporting any and all issues found with it - be those regressions or anything else - would be greatly appreciated! For FreeBSD users it's now as easy as using ports, there is no need for git & Co. any more. There is a new port, called sysutils/syslog-ng-rc For details, see http://czanik.blogs.balabit.com/2012/09/syslog-ng-rc/ I'm also planing to update my openSUSE repositories. Bye,
-- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
participants (5)
-
Balazs Scheidler
-
Evan Rempel
-
Gergely Nagy
-
Marvin Nipper
-
Peter Czanik