Hi, I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4. I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments. The current state is available in git, but I've also uploaded a tarball to: http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111022+0801.tar.gz These patches were applied since 3.2.4: 4f27ef33af4d84a31f237469e493ddd3834404fe nvtable: implement proper limitation on NVTable size b6136da08fb3421239a1c2dc40b582a5a7a2e78b gprocess: Implement stricter CAP_SYSLOG checking. 7e1a3903c0635a9a5070a6998ebc3f4e1282f33e syslogformat: handle AIX style message forwards properly 304539186bab96254d683b3026a00d5404903252 cfg_persist_config_add_entry(): call destroy notify if persist config is empty 409304c6fdcabbd1c321d57e2bbbd3d412a43cf2 cfg-lexer.c: don't include hidden files when including a directory 7ca0e8d65048b65fe3c0015ffc7ac8d73a234833 timezone format: handle half hours in the negative range properly e9dfe15a804610def3186f104853cc5626adbf53 Copyright fixups 320e4d065df521a61ff000e848f1e6a7a787c616 program-override(): disable the effect of store-legacy-msghdr flag ef4a0ff535f2860036d8901b290b204aca7568fa persist-state: fixed a memory small leak fc91010594fe80ba111020f1bb4e23ef41acfdc6 cfg-lexer: closed a memory leak in token blocks handling 9f2153fdb3d9b9cdc120af85db5e87f93cbcec0b PCRE matcher: free the pointer returned by pcre_study() to close a memory leak 2884c8fa188ec1ab8e09799b9c6d497cf8aa423f blocks: propagate include problems as parser errors c2669ffeeae0825c9de637c04794dcfa3965b3de logmatcher: fixed a possible crash in case a regexp match is applied to a read-only macro a2fdfc9ee73c1def081eed0c554c592fd6bea572 [SCL] set empty default parameter to block ce2d45f63b9b2ee7b3b486e517b92662158c321d logproto: fixed an inbalanced get_state()/put_state() pair 3e9be2596c298e31a3b3478c430d517f5bfe42c9 [lex-rules.am]: rules use $(EGREP) instead of grep -E.(EGREP is -E compliant grep implementati b00fde64d08642eb06e1cc342f1c762a7dde6767 afsocket: Fixed a wrong cast in afsocket_dd_set_keep_alive(). 5490cf73b95a597c8695407c875cf55d23679bb9 [plugin] on AIX syslog-ng try to load .a archive modules e98032d07cdcb3a51fe1a7ddda3d3d24b0985a92 zone_info_parser: move variable declaration to the beginning of the function 88596d2b069bcdc46e207487be398ef31aa0aad9 tlscontext: fixed a possible segfault in certificate validation 160e7ebe5e6bd2ef1b0c0e79563d617c3f6f0065 [SDATA] Allow store sdata section without name or value 8bcab2e198863847036809c765b5415371d34760 afprog: automatically close pipes to child programs when executing external programs cd47492eb7733c443bccac4891efc398ab393a62 [syslog-ng-ctl] Added GLIB check version 81e350e410344e3eb1b79464359aa838507bf56a func_test: improve SQL autodetection e138c672b11eee0b30f5036872f0866dbaa6e255 system(): Bail out on unknown systems, and use a clean environment to generate config. 32650278fb35fb6f82522df54014c8d57f1705aa [persist]: only check the buffer size if no encoding is specified 2dc66883f722709b50e30875f8bb64daf24536ca LogProtoBufferedServer: fixed error handling in case the persist-state cannot be restored a4ff6764e06d7ae9eeaab8b9a89336680362ebb1 gprocess: fixed compilation error on old glibc versions f69ded4f05ddb1afcdf0ffbf3e16f1fbe3d6b53a func_test: make it possible to check whether it makes sense to run a testcase ae0ff59d9a761c2fda8a19b0c05e0e05c59bae57 Use CAP_SYSLOG instead of CAP_SYS_ADMIN, if available. f54686441496ded775877e33ad2c3e0310861b7b logreader flags: fixed segfault on unknown flags e2961e1c738c8b02ca6057ac34415536830dd0e9 add support for installing systemd unit files 2db971fc37471e39f6a8b34595ca23833166831e fixed chain-hostnames() processing 2f214c4f87d944aa28d53e331a67b1fd88d9840f systemd: make sure the acquired fd is in non-blocking mode I intend to wait a couple of days to do the actual release, but I'll proceed in a week or so without feedback too. -- Bazsi
Balazs Scheidler, On 2011-10-22 07:10, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments.
The current state is available in git, but I've also uploaded a tarball to:
http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111022+0801.tar.gz
A couple of systemd packaging notes: * the tarball includes two identical syslog-ng.service files 1) contrib/systemd/syslog-ng.service 2) examples/syslog-ng.service The second one can be dropped as the first is the one thats gets installed (--withsystemdsystemunitdir) * the syslog-ng.service file in the 3.2 branch is different from the one in the 3.3 git tree: ---------- --- syslog-ng-3.2.git/contrib/systemd/syslog-ng.service ... +++ syslog-ng-3.3.git/contrib/systemd/syslog-ng.service ... @@ -6,6 +6,7 @@ ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service ExecStart=/usr/sbin/syslog-ng -F ExecReload=/bin/kill -HUP $MAINPID +StandardOutput=null [Install] WantedBy=multi-user.target ---------- * we have been experiencing very strange systemd/syslog-ng problems in Fedora 15 (and Fedora 16 Beta): some systems become completely unusable if we change the Sockets option in the syslog-ng.service file from syslog-ng.socket to syslog.socket as suggested by the systemd author. At the same time the line "StandardOutput=null" was also added to the syslog-ng.service file but it doesn't appears to be the source of the problem. Any help tracking this one will be appreciated ... The change that appears to be causing the problems: -Sockets=syslog-ng.socket +Sockets=syslog.socket More details: https://bugzilla.redhat.com/show_bug.cgi?id=742624 Regards, jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
Hi, Thanks for reporting these. On Sun, 2011-10-23 at 00:00 +0100, Jose Pedro Oliveira wrote:
Balazs Scheidler,
On 2011-10-22 07:10, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments.
The current state is available in git, but I've also uploaded a tarball to:
http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111022+0801.tar.gz
A couple of systemd packaging notes:
* the tarball includes two identical syslog-ng.service files
1) contrib/systemd/syslog-ng.service 2) examples/syslog-ng.service
The second one can be dropped as the first is the one thats gets installed (--withsystemdsystemunitdir)
Right, the files in doc/examples were removed in 3.3, removed them from 3.2 too. Thanks for noticing, I've commited a fix.
* the syslog-ng.service file in the 3.2 branch is different from the one in the 3.3 git tree: ---------- --- syslog-ng-3.2.git/contrib/systemd/syslog-ng.service ... +++ syslog-ng-3.3.git/contrib/systemd/syslog-ng.service ... @@ -6,6 +6,7 @@ ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service ExecStart=/usr/sbin/syslog-ng -F ExecReload=/bin/kill -HUP $MAINPID +StandardOutput=null
[Install] WantedBy=multi-user.target ----------
backported too.
* we have been experiencing very strange systemd/syslog-ng problems in Fedora 15 (and Fedora 16 Beta): some systems become completely unusable if we change the Sockets option in the syslog-ng.service file from syslog-ng.socket to syslog.socket as suggested by the systemd author. At the same time the line "StandardOutput=null" was also added to the syslog-ng.service file but it doesn't appears to be the source of the problem. Any help tracking this one will be appreciated ...
The change that appears to be causing the problems: -Sockets=syslog-ng.socket +Sockets=syslog.socket
More details: https://bugzilla.redhat.com/show_bug.cgi?id=742624
hmm... I seem to remember having a problem with systemd acquired sockets to remain in blocking mode. This was fixed after 3.2.4 was released in this patch: commit 2f214c4f87d944aa28d53e331a67b1fd88d9840f Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Jun 22 12:50:53 2011 +0200 systemd: make sure the acquired fd is in non-blocking mode The fd acquired from systemd is in blocking mode, and syslog-ng didn't explicitly set it to non-blocking, causing syslog-ng to stall. This patch changes that, explicitly enables O_NONBLOCK and O_CLOEXEC on systemd acquired fds. Reported-By: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Bazsi
On Sun, 2011-10-23 at 08:55 +0200, Balazs Scheidler wrote:
Hi,
Thanks for reporting these.
I've uploaded another snapshot to my people.balabit.hu page: http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111023+0856.tar.gz Can you perhaps build a new package out of this, so we can be sure that nothing is messed up? Thanks. PS: anyone else carrying 3.2.x packages with feedback? -- Bazsi
Balazs Scheidler, On 2011-10-23 07:59, Balazs Scheidler wrote:
On Sun, 2011-10-23 at 08:55 +0200, Balazs Scheidler wrote:
Hi,
Thanks for reporting these.
I've uploaded another snapshot to my people.balabit.hu page:
http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111023+0856.tar.gz
Can you perhaps build a new package out of this, so we can be sure that nothing is messed up?
Would be possible to re-create and upload the tarball? I'm getting errors unpacking it: ---------- $ tar xf ../syslog-ng-3.2.4+20111023+0856.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now ---------- Note: tarball is almost 330 KiB smaller than the previous one. jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
Hi, Sorry for not responding sooner. I've now reuploaded the same tarball, downloaded and extracted it without problems. On Sun, 2011-10-23 at 09:06 +0100, Jose Pedro Oliveira wrote:
Balazs Scheidler, On 2011-10-23 07:59, Balazs Scheidler wrote:
On Sun, 2011-10-23 at 08:55 +0200, Balazs Scheidler wrote:
Hi,
Thanks for reporting these.
I've uploaded another snapshot to my people.balabit.hu page:
http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111023+0856.tar.gz
Can you perhaps build a new package out of this, so we can be sure that nothing is messed up?
Would be possible to re-create and upload the tarball? I'm getting errors unpacking it: ---------- $ tar xf ../syslog-ng-3.2.4+20111023+0856.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now ----------
Note: tarball is almost 330 KiB smaller than the previous one.
jpo
-- Bazsi
On 2011-10-25 16:06, Balazs Scheidler wrote:
Hi,
Sorry for not responding sooner. I've now reuploaded the same tarball, downloaded and extracted it without problems.
New SRPM for Fedora >= 15 in http://koji.fedoraproject.org/koji/buildinfo?buildID=270588 jpo
On Sun, 2011-10-23 at 09:06 +0100, Jose Pedro Oliveira wrote:
Balazs Scheidler, On 2011-10-23 07:59, Balazs Scheidler wrote:
On Sun, 2011-10-23 at 08:55 +0200, Balazs Scheidler wrote:
Hi,
Thanks for reporting these.
I've uploaded another snapshot to my people.balabit.hu page:
http://people.balabit.hu/bazsi/syslog-ng-3.2.4+20111023+0856.tar.gz
Can you perhaps build a new package out of this, so we can be sure that nothing is messed up?
Would be possible to re-create and upload the tarball? I'm getting errors unpacking it: ---------- $ tar xf ../syslog-ng-3.2.4+20111023+0856.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now ----------
Note: tarball is almost 330 KiB smaller than the previous one.
jpo
-- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On Tue, 2011-10-25 at 21:22 +0100, Jose Pedro Oliveira wrote:
On 2011-10-25 16:06, Balazs Scheidler wrote:
Hi,
Sorry for not responding sooner. I've now reuploaded the same tarball, downloaded and extracted it without problems.
New SRPM for Fedora >= 15 in http://koji.fedoraproject.org/koji/buildinfo?buildID=270588
Thanks. -- Bazsi
On 2011-10-23 07:55, Balazs Scheidler wrote: ---[snip]---
* we have been experiencing very strange systemd/syslog-ng problems in Fedora 15 (and Fedora 16 Beta): some systems become completely unusable if we change the Sockets option in the syslog-ng.service file from syslog-ng.socket to syslog.socket as suggested by the systemd author. At the same time the line "StandardOutput=null" was also added to the syslog-ng.service file but it doesn't appears to be the source of the problem. Any help tracking this one will be appreciated ...
The change that appears to be causing the problems: -Sockets=syslog-ng.socket +Sockets=syslog.socket
More details: https://bugzilla.redhat.com/show_bug.cgi?id=742624
hmm... I seem to remember having a problem with systemd acquired sockets to remain in blocking mode. This was fixed after 3.2.4 was released in this patch:
commit 2f214c4f87d944aa28d53e331a67b1fd88d9840f Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Jun 22 12:50:53 2011 +0200
systemd: make sure the acquired fd is in non-blocking mode
The fd acquired from systemd is in blocking mode, and syslog-ng didn't explicitly set it to non-blocking, causing syslog-ng to stall. This patch changes that, explicitly enables O_NONBLOCK and O_CLOEXEC on systemd acquired fds.
Reported-By: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
We had already backported it to the 3.2.4 release without success: https://bugzilla.redhat.com/show_bug.cgi?id=742624#c14 jpo -- José Pedro Oliveira * mailto:jpo@di.uminho.pt *
On 10/22/2011 08:10 AM, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments. To compile on OS X, one patch should be added, which is available at the bottom of this homebrew script: https://raw.github.com/mxcl/homebrew/master/Library/Formula/syslog-ng.rb Bye,
-- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
Hi, that patch is not suitable for inclusion as that would break support for other platforms. I've committed this instead: commit 13abb05aeeab5e56f73cf83352d0b83df6597faa Author: Balazs Scheidler <bazsi@balabit.hu> Date: Mon Oct 31 17:06:14 2011 +0100 detect if "environ" variable is present MacOSX doesn't have an "environ" global, compile the setproctitle code conditionally. We could use _NSGetEnviron(), but the whole point of setting the proctitle is not that important, and I'm not completely sure that it actually works. Changing the process title involves a lot of possibly unportable magic. Reported-By: Peter Czanik <czanik@balabit.hu> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> On Mon, 2011-10-31 at 09:40 +0100, Peter Czanik wrote:
On 10/22/2011 08:10 AM, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments. To compile on OS X, one patch should be added, which is available at the bottom of this homebrew script: https://raw.github.com/mxcl/homebrew/master/Library/Formula/syslog-ng.rb Bye,
-- Bazsi
By the way, I've been running 3.2.4 since you asked for feedback and it is stable with no memory leaks. On Mon, Oct 31, 2011 at 11:06 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
Hi,
that patch is not suitable for inclusion as that would break support for other platforms.
I've committed this instead:
commit 13abb05aeeab5e56f73cf83352d0b83df6597faa Author: Balazs Scheidler <bazsi@balabit.hu> Date: Mon Oct 31 17:06:14 2011 +0100
detect if "environ" variable is present
MacOSX doesn't have an "environ" global, compile the setproctitle code conditionally. We could use _NSGetEnviron(), but the whole point of setting the proctitle is not that important, and I'm not completely sure that it actually works.
Changing the process title involves a lot of possibly unportable magic.
Reported-By: Peter Czanik <czanik@balabit.hu> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
On Mon, 2011-10-31 at 09:40 +0100, Peter Czanik wrote:
On 10/22/2011 08:10 AM, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments. To compile on OS X, one patch should be added, which is available at the bottom of this homebrew script: https://raw.github.com/mxcl/homebrew/master/Library/Formula/syslog-ng.rb Bye,
-- Bazsi
______________________________________________________________________________ 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
Hello, Sorry for the slow reply. I just tested the latest git, and I still get: libtool: link: gcc -std=gnu99 -dynamiclib -o .libs/libsyslog-ng.0.dylib .libs/misc.o .libs/utils.o .libs/messages.o .libs/syslog-names.o .libs/cfg.o .libs/filter.o .libs/logmsg.o .libs/logstamp.o .libs/msg-format.o .libs/nvtable.o .libs/logpipe.o .libs/logsource.o .libs/driver.o .libs/sgroup.o .libs/dgroup.o .libs/center.o .libs/templates.o .libs/logreader.o .libs/logwriter.o .libs/afinter.o .libs/children.o .libs/stats.o .libs/gsockaddr.o .libs/gsocket.o .libs/logtransport.o .libs/logproto.o .libs/memtrace.o .libs/persist-state.o .libs/dnscache.o .libs/serialize.o .libs/apphook.o .libs/timeutils.o .libs/tags.o .libs/alarms.o .libs/logparser.o .libs/logprocess.o .libs/logmpx.o .libs/logrewrite.o .libs/logmatcher.o .libs/gprocess.o .libs/globals.o .libs/control.o .libs/compat.o .libs/logqueue.o .libs/cfg-lexer.o .libs/cfg-lex.o .libs/cfg-parser.o .libs/cfg-grammar.o .libs/plugin.o .libs/filter-expr-grammar.o .libs/filter-expr-parser.o .libs/block-ref-grammar.o .libs/block-ref-parser.o .libs/pragma-grammar.o .libs/pragma-parser.o .libs/parser-expr-grammar.o .libs/parser-expr-parser.o .libs/rewrite-expr-grammar.o .libs/rewrite-expr-parser.o -L/opt/local/lib /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc /opt/local/lib/libevtlog.dylib -lresolv /opt/local/lib/libpcre.dylib -ldl -O2 -framework Carbon -install_name /usr/local/lib/libsyslog-ng.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module Undefined symbols: "_environ", referenced from: _g_process_set_argv_space in gprocess.o _g_process_set_argv_space in gprocess.o _g_process_set_argv_space in gprocess.o _g_process_set_argv_space in gprocess.o ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [libsyslog-ng.la] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 bash-3.2# Looking at the generated config.h: /* Specifies whether the environ global variable exists */ #define HAVE_ENVIRON 1 When I deleted the above lines, it compiles and works fine. So configure seems to provide false information... Bye, CzP On 10/31/2011 05:06 PM, Balazs Scheidler wrote:
Hi,
that patch is not suitable for inclusion as that would break support for other platforms.
I've committed this instead:
commit 13abb05aeeab5e56f73cf83352d0b83df6597faa Author: Balazs Scheidler <bazsi@balabit.hu> Date: Mon Oct 31 17:06:14 2011 +0100
detect if "environ" variable is present
MacOSX doesn't have an "environ" global, compile the setproctitle code conditionally. We could use _NSGetEnviron(), but the whole point of setting the proctitle is not that important, and I'm not completely sure that it actually works.
Changing the process title involves a lot of possibly unportable magic.
Reported-By: Peter Czanik <czanik@balabit.hu> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
On Mon, 2011-10-31 at 09:40 +0100, Peter Czanik wrote:
On 10/22/2011 08:10 AM, Balazs Scheidler wrote:
Hi,
I wanted to publish a last maintenance release from the 3.2 branch before moving on to work on 3.4.
I've backported the relevant patches, tests have ran (both on my development computer and a separate build environment), but I'd like to ask anyone running 3.2.x to test it in more production-like environments. To compile on OS X, one patch should be added, which is available at the bottom of this homebrew script: https://raw.github.com/mxcl/homebrew/master/Library/Formula/syslog-ng.rb Bye,
-- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
participants (4)
-
Balazs Scheidler
-
Jose Pedro Oliveira
-
Martin Holste
-
Peter Czanik