May 2009 - syslog-ng - lists.balabit.hu

Logging with db-parser issue
by Nate Hausrath 14 May '09

14 May '09

Hey everyone, Sorry to ask what is probably an easy question. I'm attempting to use the new db-parser feature in syslog-ng to parse Windows events generated by Snare. What I've attempted to do is write a simple XML file that will match one simple rule. This way I can test that everything is functioning properly and I can move on from there. Unfortunately, it's not working, so I'm unsure as to whether it is my rule or my installation. So I have a few basic questions that will hopefully clear up my confusion! - I did not install syslog-ng from source. I downloaded the .deb for version 3.01 and used that. Does this even include db-parser? (I'm assuming yes because it does not cause an error from the config file alone.) - My installation is in /opt/syslog-ng, so I've put the example XML files (http://www.balabit.com/downloads/files/patterndb/) in /opt/syslog-ng/var. Is this the right location? Other than that, here is my syslog-ng.conf file: @version: 3.0 #Default configuration file for syslog-ng. # # For a description of syslog-ng configuration file directives, please read # the syslog-ng Administrator's guide at: # # http://www.balabit.com/dl/html/syslog-ng-admin-guide_en.html/bk01-toc.html # options { }; ###### # sources source s_local { # message generated by Syslog-NG internal(); # standard Linux log source (this is the default place for the syslog() # function to send logs to) unix-stream("/dev/log"); # messages from the kernel file("/proc/kmsg" program_override("kernel: ")); }; source s_net { udp(); tcp(); }; parser p_db { db-parser(); }; ###### # destinations destination d_messages { file("/var/log/messages"); }; destination d_parsed { file("/var/log/remote/parsed.log"); }; log { source(s_local); destination(d_messages); }; log { source(s_net); destination(d_parsed); parser(p_db); }; And here is my windows.xml file: <?xml version='1.0' encoding='UTF-8'?> <patterndb version='2' pub_date='2009-05-07'> <ruleset name='windows'> <pattern>MSWinEventLog</pattern> <rules> <rule provider='nate' id='1' class='system'> <patterns> <pattern>540</pattern> </patterns> <description>This is a terrible terrible message to receive. Game over man! Game over!</description> </rule> </rules> </ruleset> </patterndb> As you see, to test I just want to match on the number '540' and put that log message in /var/log/remote/parsed.log. I have verified that messages that should match this are arriving at the machine when I send them. If i turn off the db-parser, the messages appear in the parsed.log file. If there is any documentation that explains the basics of this, sorry that I missed it. I've only been able to find some of the other messages on this mailing list and the blog entries on balabit. Thanks for any help! Nate

4 10

Compile error on Ubuntu 8.04
by Nate Hausrath 12 May '09

12 May '09

Hello everyone, I'm attempting to compile and install the latest syslog-ng 3.0 from source (downloaded from the git repository). I believe I have installed all the dependencies (configure does not complain). However, I am receiving the following error when running make. /bin/bash ../ylwrap cfg-lex.l .c cfg-lex.c -- /bin/bash /home/nhausrath/packages/syslog-ng.git/missing --run flex make[2]: *** [cfg-lex.c] Error 1 make[2]: Leaving directory `/home/nhausrath/packages/syslog-ng.git/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/nhausrath/packages/syslog-ng.git' make: *** [all] Error 2 It seems the error is in cfg-lex.l, but I can't tell what exactly is causing the problem. Of course, it may be something completely different that I am not familiar with. Thanks for any help! -Nate

3 4

Re: [syslog-ng] PATCH: Fix some small memory leaks and a SEGV
by mark tomlinson 10 May '09

10 May '09

On Fri, 2009-05-08 at 15:16 +0200, Balazs Scheidler wrote: > Hi, > > Thanks for your contribution. Although some of these might be genuine > leaks, they mostly occur of you use the same option multiple times in > the configuration file. > ... deletions ... > > > > diff --git a/src/dgroup.c b/src/dgroup.c > > index 7919a54..be02899 100644 > > --- a/src/dgroup.c > > +++ b/src/dgroup.c > > @@ -76,6 +76,16 @@ log_dest_group_deinit(LogPipe *s) > > NULL); > > success = FALSE; > > } > > + if (p->group) > > + { > > + g_free(p->group); > > + p->group = NULL; > > + } > > + if (p->id) > > + { > > + g_free(p->id); > > + p->id = NULL; > > + } > > } > > return success; > > } > > these should be freed when the driver in question gets freed in the > log_drv_free() function > This was a definite leak with our configuration and use. I believed the problem to be due to log_dest_group_deinit() being called, and then log_dest_group_init() being called, without log_drv_free() ever being called inbetween. I will have a look at our configuration files. We do change configuration between logging to a file and logging to/from network on the fly (and while many log messages are being generated). > > diff --git a/src/logsource.c b/src/logsource.c > > index 311e61f..93a8747 100644 > > --- a/src/logsource.c > > +++ b/src/logsource.c > > @@ -181,6 +181,10 @@ log_source_set_options(LogSource *self, LogSourceOptions *options, gint stats_le > > g_atomic_counter_set(&self->options->window_size, current_window); > > self->stats_level = stats_level; > > self->stats_source = stats_source; > > + if (self->stats_id) > > + g_free(self->stats_id); > > + if (self->stats_instance) > > + g_free(self->stats_instance); > > self->stats_id = stats_id ? g_strdup(stats_id) : NULL; > > self->stats_instance = stats_instance ? g_strdup(stats_instance): NULL; > > } > > > > > diff --git a/src/logwriter.c b/src/logwriter.c > > index 4c895cc..1d1e00e 100644 > > --- a/src/logwriter.c > > +++ b/src/logwriter.c > > @@ -792,6 +792,10 @@ log_writer_set_options(LogWriter *self, LogPipe *control, LogWriterOptions *opti > > > > self->stats_level = stats_level; > > self->stats_source = stats_source; > > + if (self->stats_id) > > + g_free(self->stats_id); > > + if (self->stats_instance) > > + g_free(self->stats_instance); > > self->stats_id = stats_id ? g_strdup(stats_id) : NULL; > > self->stats_instance = stats_instance ? g_strdup(stats_instance) : NULL; > > these again should only be called once, but better if the function is > idempotent. Again, I was seeing deinit()/init() happening, without any calls to free the driver from af_socket_dd. > > > > > diff --git a/src/sgroup.c b/src/sgroup.c > > index 904237c..0fdf8fb 100644 > > --- a/src/sgroup.c > > +++ b/src/sgroup.c > > @@ -79,7 +79,18 @@ log_source_group_deinit(LogPipe *s) > > evt_tag_str("id", p->id), > > NULL); > > success = FALSE; > > - } > > + } > > + if (p->group) > > + { > > + g_free(p->group); > > + p->group = NULL; > > + } > > + if (p->id) > > + { > > + g_free(p->id); > > + p->id = NULL; > > + } > > + log_pipe_append(&p->super, NULL); > > > hmm... can you show me the backtrace of the crash that this is supposed > to fix? when the configuration is deinitialized the old LogSource > instances should never be referenced again, thus this dangling pointer > will never be referenced again. > > Also, group/id is freed whenever the driver instance is freed, thus no > need to open code it. I see the possibility of a leak if syslog-ng falls > back to the old configuration as we coulnd't initialize the new one (in > which case log_sgroup_init is called multiple times on the same config), > but otherwise it should not be a leak. > The memory leaks again occured due to seeing deinit/init pairs being called. The fix for the crash is the log_pipe_append(), which prevents the driver using the sgroup again after it has been freed. I don't know the full reason for this happening, only that it did (with HUPs, changing configs, and lots of log messages all at the same time...) The stack trace was as follows: Thread Backtraces: Thread 1 (process 862): #0 log_source_group_queue (s=0x100795d8, msg=0x100aa598, path_options=0x7fa70ba4) at sgroup.c:98 #1 0x1000a238 in log_pipe_forward_msg (self=<value optimized out>, msg=0x1, path_options=0x3025134c) at logpipe.h:121 #2 0x1000a238 in log_pipe_forward_msg (self=<value optimized out>, msg=0x1, path_options=0x3025134c) at logpipe.h:121 #3 0x10026148 in log_source_queue (s=0x100bacf0, msg=0x100aa598, path_options=<value optimized out>) at logpipe.h:121 #4 0x1001b43c in log_reader_fd_dispatch (source=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at logpipe.h:121 #5 0x30070f9c in IA__g_main_context_dispatch (context=0x100507f0) at gmain.c:1916 #6 0x300732c4 in g_main_context_iterate (context=0x0, block=0, dispatch=1, self=<value optimized out>) at gmain.c:2547 #7 0x300733c8 in IA__g_main_context_iteration (context=0x0, may_block=268765168) at gmain.c:2606 #8 0x10005324 in main_loop_run (cfg=0x0) at main.c:175 #9 0x1000584c in main (argc=1, argv=0x7fa70de4) at main.c:428 The point it crashed at (sgroup.c:98) was the line: (*self->processed_messages)++; in log_source_group_queue(). But self has already been freed, so the memory address it was incrementing was bogus, causing the SEGV. The fix above means that the log_pipe_forward_msg() call will drop the message in this case.

2 1

syslog-ng 3.0.2 has been released
by devel＠balabit.hu 08 May '09

08 May '09

------------------------------------------------------------------------------ PACKAGE : syslog-ng VERSION : 3.0.2 SUMMARY : new stable release DATE : May 8, 2009 ------------------------------------------------------------------------------ DESCRIPTION: A new stable version of syslog-ng Open Source Edition (3.0.2) has been released. For latest fixes in the 3.0.x branch you are recommended to upgrade to this version. CHANGES: 3.0.2 Thu, 07 May 2009 08:30:06 +0200 Highlights: * This release is the first to feature binary packages, installation packages for various platforms. Bugfixes: * Only assume that a source logfile was rotated if the new log file has a non-zero size. This fix solves a minor race which might cause some messages to be lost from the end of the old logfile. * Fixed the processing of the -u and -g command line options to set the user/group of the syslog-ng process. Previously all usernames were rejected as non-existant. * Resolve usernames before chrooting, to avoid the need to have an /etc/passwd & /etc/group inside the chroot. * Fixed the read rate of regular files, with the change in this release it is now possible to fully saturate a destination pipe by using plain text files. * Fixed a synchronization problem in the SQL destination on AIX causing random crashes when the SQL destination is used. * Make the "syslog" reserved word usable as a facility name, previously syslog-ng indicated a syntax error if syslog as a facility was not enclosed in quotation marks. * Don't write the pidfile in case only a syntax check was requested. * Fixed compilation problems if SSL support is not enabled. * Set the default fd limit to 256 on cygwin as that platform does not support the current default of 4096 used on all other platforms. * Fixed template expansion for non-inline templates defined using the template statement. * Fixed the handling of zero-sized packets in the udp() source. * Fixed the storing of regexp/db-parser() matches on big-endian, 32 bit CPUs. * Fixed character conversion in case one chunk of data has an incomplete sequence at the end. * Don't let the character conversion eat up unlimited memory to avoid an easy DoS condition. * Fixed SSL certificate validation, added X.509 policy check, fixed required-untrusted verify-mode and added basicConstraints validation. * Fixed /dev/klog handling on FreeBSD, syslog-ng attempted to open this device multiple times which is not permitted. * Fixed $TZOFS expansion in templates in case the target does not specify a conversion timezone (which is the default and is true in most cases). * Fixed the use of multiple SQL destinations, previously due to an initialization problem only the first SQL destination would ever start writing messages to the target database. * If you elected to use a host-file only name resolution, the check to see if the hosts file was changed was performed for each DNS resolution, causing a major performance drop. This was fixed. * Due to a typo in the configuration file parser, using SSL destinations always resulted in a segmentation fault. This was fixed. * Fixed counting the number of concurrent connections in the SSL enabled tcp() source, previously failing handshakes were counted, thus it is quite easy to reach the max-connection limit. * Clarified logging about connection rejected by /etc/hosts.deny & /etc/hosts.allow * HP-UX 11v3 compilation fixes * Fixed SOURCEIP expansion for IPv6 addresses. * Fixed match(type(string)) not to match the message in case only a prefix match was found. * Fixed capability setup code around file opens. Other changes: * Implemented 'store-legacy-msghdr' source flag which keeps the original value of MSGHDR intact, instead of parsing/rebuilding it at the cost of some performance penalty. * Implemented 'empty-lines' source flag to avoid dropping empty log messages which is the default behaviour. * Added support for file includes in the configuration file. * Allow follow_freq() to be a floating point number. * Cygwin packaging fixes. * Make it possible to create named pipes automatically in the pipe() destination. * Allow the use of macros in the filename of pipe() destinations. * Added support for setting the default priority/facility value for each source that get applied to messages that lack one. * Recognize "mssql" as an alias for "freetds" in the SQL destination. * Added the "greedy" flags to the csv-parser(): it makes the last column eat the complete end of the line without caring about column separation characters * Added the "drop-invalid" flag to the csv-parser() which makes the parser drop anything that has less columns than it expects to have. * Make it possible to use fractions of a second even in non-ISO timestamps. * The default values for SQL columns is being deprecated, please supply SQL schema information explicitly in your SQL destinations. A warning message was added in case you don't have a full schema and rely on the default values. * The SQL destination got a null() option that specifies a 'special' value for a column which get replaced by an SQL NULL. * Added local_timezone() option to file/sql destinations that control the timezone used when expanding the filename/tablename templates. It defaults to the local timezone. Configure changes: * This section lists changes that might affect distribution packages, please make sure that these changes do not break the syslog-ng packages in any way. * Changed the default value of pidfiledir to ${localstatedir} to match GNU conventions, you can specify it explicitly with a --with-pidfile-dir configure option. * Changed the default linking mode to "dynamic" to make it easier to compile syslog-ng, as most distributions prefer dynamic libraries over static ones. This means that syslog-ng might not be able to start up if /usr is on NFS. On platforms where syslog-ng is used as a system logger, the previous setting of --enable-mixed-linking is preferred. Loggen changes: * the sequence number and timestamping of generated messages were erroneously commented out, these were reverted. * do not allow message sizes that are larger than the predefined message buffer size. * in addition to reporting the number of messages/sec, also report the effective bandwidth used during testing. Test suite changes: * A lot of enhancements to the functional test program to cover more of the syslog-ng code, like SSL sources & SQL destinations. DOWNLOAD: You can download the latest binaries from: http://www.balabit.com/network-security/syslog-ng/opensource-logging-system… The latest versions of syslog-ng in source format can be found at: http://www.balabit.com/downloads/files/syslog-ng/open-source-edition/

2 1

Question on '$PRIORITY' and '$LEVEL'
by Arnold Wang 08 May '09

08 May '09

I have a question regarding how syslog-ng treats "priority" and "level" value from the logs. According to RFC, "priority" is different than "level". However, it appears to me that syslog-ng use "level" value for "priority" as well. My questions are: 1. Is that true that syslog-ng use "level" value for "priority" as well? 2. Is there a reason behind this behavior? 3. Is there a plan to change/fix this? Thanks.

2 2

PATCH: Fix some small memory leaks and a SEGV
by mark tomlinson 08 May '09

08 May '09

Fix various memory leaks caused by strings not being freed. Also, in log_source_group_deinit(), ensure no drivers are still pointing to this possibly soon-to-be-freed structure. Without this a SIGSEGV was possible when a SIGHUP occured while syslog was busy. diff --git a/src/afinet.c b/src/afinet.c index 28b9d50..144a08a 100644 --- a/src/afinet.c +++ b/src/afinet.c @@ -191,6 +191,8 @@ afinet_sd_set_transport(LogDriver *s, const gchar *transport) { AFInetSourceDriver *self = (AFInetSourceDriver *) s; + if (self->super.transport) + g_free(self->super.transport); self->super.transport = g_strdup(transport); if (strcasecmp(transport, "udp") == 0) { diff --git a/src/afstreams.c b/src/afstreams.c index df4e758..35d4812 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -104,6 +104,8 @@ afstreams_sd_set_sundoor(LogDriver *s, gchar *filename) { AFStreamsSourceDriver *self = (AFStreamsSourceDriver *) s; + if (self->door_filename) + g_string_free(self->door_filename, TRUE); self->door_filename = g_string_new(filename); } diff --git a/src/dgroup.c b/src/dgroup.c index 7919a54..be02899 100644 --- a/src/dgroup.c +++ b/src/dgroup.c @@ -76,6 +76,16 @@ log_dest_group_deinit(LogPipe *s) NULL); success = FALSE; } + if (p->group) + { + g_free(p->group); + p->group = NULL; + } + if (p->id) + { + g_free(p->id); + p->id = NULL; + } } return success; } diff --git a/src/logsource.c b/src/logsource.c index 311e61f..93a8747 100644 --- a/src/logsource.c +++ b/src/logsource.c @@ -181,6 +181,10 @@ log_source_set_options(LogSource *self, LogSourceOptions *options, gint stats_le g_atomic_counter_set(&self->options->window_size, current_window); self->stats_level = stats_level; self->stats_source = stats_source; + if (self->stats_id) + g_free(self->stats_id); + if (self->stats_instance) + g_free(self->stats_instance); self->stats_id = stats_id ? g_strdup(stats_id) : NULL; self->stats_instance = stats_instance ? g_strdup(stats_instance): NULL; } diff --git a/src/logwriter.c b/src/logwriter.c index 4c895cc..1d1e00e 100644 --- a/src/logwriter.c +++ b/src/logwriter.c @@ -792,6 +792,10 @@ log_writer_set_options(LogWriter *self, LogPipe *control, LogWriterOptions *opti self->stats_level = stats_level; self->stats_source = stats_source; + if (self->stats_id) + g_free(self->stats_id); + if (self->stats_instance) + g_free(self->stats_instance); self->stats_id = stats_id ? g_strdup(stats_id) : NULL; self->stats_instance = stats_instance ? g_strdup(stats_instance) : NULL; diff --git a/src/sgroup.c b/src/sgroup.c index 904237c..0fdf8fb 100644 --- a/src/sgroup.c +++ b/src/sgroup.c @@ -79,7 +79,18 @@ log_source_group_deinit(LogPipe *s) evt_tag_str("id", p->id), NULL); success = FALSE; - } + } + if (p->group) + { + g_free(p->group); + p->group = NULL; + } + if (p->id) + { + g_free(p->id); + p->id = NULL; + } + log_pipe_append(&p->super, NULL); } return success; }

3 2

suppressing pidfile and control socket for syslog-ng 3.0
by Denis Laplante 08 May '09

08 May '09

To clarify my question about suppressing PID and control socket in syslog-ng version 3.0: I don't want the error message to be suppressed by having the file successfully created in syslog-ng's favourite location, I want to suppress opening the 2 files . I might want multiple syslog-ng processes running simultaneously, for example a test instance to run without interfering with production instances. In the case of PID file, I could perhaps specify "--pidfile /dev/null" ; is there a chance that the target file might get deleted or have permissions changed? A couple of minor complaints for this option: Option --pidfile does not handle relative directories (unlike syslog-ng.conf) . Option -P responds with "Error parsing command line arguments: Unknown option -P". > Message: 3 Date: Mon, 4 May 2009 10:51:20 +0200 (CEST) > From: bugzilla(a)bugzilla.balabit.com > Subject: [syslog-ng] [Bug 43] syslog-ng 2.1.4 consumes all CPU when processing "source file" > Comment #4 from Balazs Scheidler <bazsi(a)balabit.hu> 2009-05-04 10:51:21 > [...] >>> > > can you try 3.0 if it fixes your problem? >> > Yes, 3.0.1 on Solaris-8 fixes this problem. > [...] > > How do I suppress pidfile and/or control socket? >> > > Error opening control socket, bind() failed; error='Permission denied (13)', socket='/local/var/run/syslog-ng.ctl' > This is a different issue, you should probably create /local/var/run/ directory with appropriate permissions.

3 2

[Bug 46] New: Syslog-ng can go into and endless loop, consume all memory, and crash
by bugzilla＠bugzilla.balabit.com 07 May '09

07 May '09

https://bugzilla.balabit.com/show_bug.cgi?id=46 Summary: Syslog-ng can go into and endless loop, consume all memory, and crash Product: syslog-ng Version: 2.0.x Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: support(a)sikkerhed.org Type of the Report: bug Estimated Hours: 0.0 I've discovered a scenario where syslog-ng will eat all memory, and then either crash or get OOM-killed. I'm using the following config: {{{ options { chain_hostnames(0); time_reopen(10); time_reap(360); log_fifo_size(2048); create_dirs(yes); owner(root); group(adm); perm(0640); dir_owner(root); dir_group(adm); dir_perm(0755); use_dns(yes); use_fqdn(yes); stats_freq(3600); }; source s_all { internal(); unix-stream("/dev/log"); file("/proc/kmsg" log_prefix("kernel: ")); }; destination du_all { usertty("*"); }; destination df_logs { file("/var/log/$FACILITY/log-$YEAR-$MONTH-$DAY"); file("/var/log/$FACILITY/current"); }; destination df_everything { file("/var/log/everything/log-$YEAR-$MONTH-$DAY"); file("/var/log/everything/current"); }; filter f_messages { level(info,notice,warn) and not facility(auth,authpriv); }; filter f_emerg { level(emerg); }; log { source(s_all); destination(df_logs); }; log { source(s_all); filter(f_messages); destination(df_everything); }; log { source(s_all); filter(f_emerg); destination(du_all); }; }}} The problem is the "/var/log/$FACILITY/current" output. I had some old output left over from the earlier logger, which meant that /var/log/syslog was a file. When syslog-ng expects this node to be a directory, not a file, it tries to mkdir() it, and fails. This fail generates a syslog message, which needs to get logged to /var/log/syslog/current... which doesn't exist, is mkdir()'ed, fails, is syslogged, etc. In other words, it never starts up, and doesn't log anything useful about what is going on. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

Having syslog-ng send to a central server via local6
by Patrick Topping 06 May '09

06 May '09

I am setting up syslog-ng to tail a database query log and have it sent to a central server for analysis / archiving. I have it partially working. I am able to send the UDP packets to the central server but I cannot get them to be sent to central server @ local6. Below is my source, destination, & log lines: *source s_general_db_log { file ("/var/lib/mysql/mysql/general_log.CSV" flags(no-parse) follow_freq(1) program_override("vchat3dev-db002_mysql_db_log:") ); }; destination d_central { udp( "10.0.4.162" port(514) ); }; log { source(s_general_db_log); destination(d_central); }; *I have tried adding in a facility option to the destination but it does not work. Any help with what I am missing would be greatly appreciated. Thanks in advance. -Patrick

4 4

[Bug 43] New: syslog-ng 2.1.4 consumes all CPU when processing "source file "
by bugzilla＠bugzilla.balabit.com 05 May '09

05 May '09

https://bugzilla.balabit.com/show_bug.cgi?id=43 Summary: syslog-ng 2.1.4 consumes all CPU when processing "source file" Product: syslog-ng Version: 2.1.x Platform: Macintosh OS/Version: Mac OS Status: NEW Severity: major Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: denis.laplante(a)ubc.ca Type of the Report: bug Estimated Hours: 0.0 Summary: syslog-ng version 2.1.4 consumes all CPU when processing "source file" This happens with MacOsX-10.5 (via MacPorts compilation environment), and SunOS-5.8 (manual compilation). Version 2.0.9 on another MacOsX-10.5 compiled earlier behaves normally: lines are copied to destination file, and CPU usage remains low. Test Sequence: rm testlog.txt syslog-ng -f ./syslog-ng.conf -d -F [start without daemonizing] [ 2 lines appended to syslogng.log : ] > Apr 15 09:31:16 s_syslogng@greygum syslog-ng[28695]: Follow-mode file source not found, deferring open; filename='.../testlog.txt' > Apr 15 09:31:16 s_syslogng@greygum syslog-ng[28695]: syslog-ng starting up; version='2.1.4' touch testlog.txt [file gets opened, CPU is quiet] echo "hello" > testlog.txt [CPU immediately jumps to max, but no lines copied to destination] [ While CPU at max, process unkillable except "kill -9" ] [ While CPU at max, use GUI "Activity Monitor" option "Sample", results below: ] > Sampling process 28695 for 3 seconds with 1 millisecond of run time between samples > Sampling completed, processing symbols... > Analysis of sampling syslog-ng (pid 28695) every 1 millisecond > Call graph: > 1373 Thread_2503 > 1373 start > 1373 main > 1373 main_loop_run > 1373 g_main_context_iteration > 1373 g_main_context_iterate > 1373 g_main_context_dispatch > 1373 log_reader_fd_dispatch > 1301 fd_do_read > 1287 read$UNIX2003 > 1287 read$UNIX2003 > 13 fd_do_read > 1 dyld_stub_read$UNIX2003 > 1 dyld_stub_read$UNIX2003 > 58 log_reader_iterate_buf > 48 log_reader_iterate_buf > 8 __memcpy > 8 __memcpy > 1 log_reader_find_eom > 1 log_reader_find_eom > 1 memmove > 1 memmove > 13 log_reader_fd_dispatch > 1 g_sockaddr_unref > 1 g_sockaddr_unref [ number probably counts when program counter was found in routine ] On SunOs, truss showed very fast cycling between alarm() and read(). [ syslog-ng.conf ] source s_testfile{ file(".../testlog.txt" follow_freq(10) flags(no-parse)); }; destination d_test_local{ file(".../testlog-copy.txt" perm(0644) ); }; log{ source(s_testfile); destination(d_test_local); }; source s_syslogng { internal(); }; # Messages internal to syslog-ng destination d_syslogng { file(".../syslogng.log" perm(0644) ); }; log{ source(s_syslogng); destination(d_syslogng); }; -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7