- syslog-ng - lists.balabit.hu

syslog-ng 2.0rc1 released
by Balazs Scheidler 15 Jul '06

15 Jul '06

Dear syslog-ng users, I'm proud to announce that syslog-ng 2.0rc1 has been released. The new release is based on a completely rewritten code base, and aims to be a drop-in replacement for syslog-ng 1.6.x. Highlights over 1.6.x: - Support for extended timestamps with year, timezone information and subsecond granularity. - Flow control support: enabling flow control end-to-end, on the whole message path leaves TCP connection breaks the only source of message loss. - Better performance: various data structures and algorithms have been optimized. - IPv6 and multicast support. - and more... This release has already been tested in production environment, with high performance demands. Here is a list of user-visible changes since 1.9.11: 2.0rc1 Sat, 08 Jul 2006 13:52:50 +0200 Some minor new features: * Added LEVEL_NUM and FACILITY_NUM macros. * Added optional() support for destination files to avoid flooding the log if a given destination cannot be opened. Bugfixes: * Fixed priority range filter evaluation. * Portability fixes for various OSs (Solaris, AIX and HP-UX) and architectures (64bit CPUs) * In the case of a broken connection don't reconnect immediately, but wait some time specified by time_reopen() to match 1.6.x behaviour. * Fixed a reproducible segmentation fault in UNIX domain socket destinations. * Fixed dir_group() handling. Other changes: * Documentation updates. -- Bazsi

1 0

Bug in syntax checking in 2.0-rc1
by Paul Krizak 14 Jul '06

14 Jul '06

I'm using 2.0-rc1 and found the following bug in syntax checking: $ syslog-ng -d -F -f /opt/mpd/vtec/etc/syslog-ng.conf Error in configuration, unresolved destination reference; filter='d_syslog_pipe' But running: $ syslog-ng -s -f /opt/mpd/vtec/etc/syslog-ng.conf ; echo $? 0 Returns 0, i.e. "syntax is OK!" This just caused me a great deal of headaches, because I use a script to generate my syslog-ng.conf and I couldn't figure out why syslog-ng refused to startup...the script checked the syntax at the end and it returned fine! I believe that the -s switch should mean "if it returns zero, then when you fire up syslog-ng, it *will* start up and begin functioning." -- Paul Krizak 5900 E. Ben White Blvd. MS 625 Advanced Micro Devices Austin, TX 78741 Linux/Unix Systems Engineering Phone: (512) 602-8775 Microprocessor Solutions Sector

3 3

RE: [syslog-ng] Syslog-ng dropped packets.
by Vaibhav Goel 14 Jul '06

14 Jul '06

The other thing I forgot to mention is that yes it is syslog-ng on the receving end that is dropping packets. We are logging a lot of web data on a loghost. We have no sending syslog-ng process. We have our application that connects directly to the syslog-ng port. It is a java application and uses log4j. We wrote a custom "TCP appender" to connect to port 514 and dump the log messages there. Now it is possible I guess that its dropping messages but unlikely. We can do more investigation in that. -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: July 14, 2006 8:27 AM To: Syslog-ng users' and developers' mailing list Subject: RE: [syslog-ng] Syslog-ng dropped packets. On Fri, 2006-07-14 at 06:21 -0700, Vaibhav Goel wrote: > Hi Bazsi > > We are still having issues with dropped packets under heavy load. We > increased the size of rmem_default and rmem_max drastically but we are > not seeing much of an improvement....Maybe about 50% or so. Currently, > the sizes are > > $ > cat /proc/sys/net/core/rmem_default > 786426 > $ > cat /proc/sys/net/core/rmem_max > 1572852 > > Do you have any other suggestions? We are running syslog-ng 1.6.11. > > All the logging is done over TCP (except 1 UDP source but that doesn't > generate a lot of logging data). It would be important to know whether it is syslog-ng itself that drops messages or something else in the system. Do you have STATS lines in your logs? That shows how many lines were dropped by syslog-ng itself. It is also possible that it is the sending syslog-ng process that drops messages (in the case of TCP), you can verify this by checking the STATS line of the sending syslog-ng process. You can improve this situation somewhat by increasing log_fifo_size on the sender. 1.6.x sends messages on its TCP destination without flow control, which means that if the bandwidth of a TCP channel is less than the messages received, it could intentionally drop messages, that's what is shown in the DROPPED line. 2.0 supports flow control, which means that syslog-ng is trying to slow its inputs down to the rate of its output pipes. This could slow down applications at the end, but this is the only way to avoid dropping messages. -- Bazsi _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

1 0

RE: [syslog-ng] Syslog-ng dropped packets.
by Vaibhav Goel 14 Jul '06

14 Jul '06

Yup... Below are some of the stats. As you can see, in peak hours, the rate of the dropped messages is huge. I have increased the log_fifo_size in the global options to 4096 (from 2000) options { sync (0); time_reopen (10); log_fifo_size (4096); long_hostnames (on); use_dns (yes); } Jul 13 15:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 9445 Jul 13 15:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 18944 Jul 13 15:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 10517 Jul 13 15:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 12071 Jul 13 16:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 17505 Jul 13 16:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 12226 Jul 13 16:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 8276 Jul 13 16:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 13717 Jul 13 16:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 14688 Jul 13 16:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 4136 Jul 13 17:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 5506 Jul 13 17:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 2328 Jul 13 17:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1754 Jul 13 17:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 3253 Jul 13 17:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 2449 Jul 13 17:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1023 Jul 13 18:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1868 Jul 13 18:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1541 Jul 13 18:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1863 Jul 13 18:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 380 Jul 13 18:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1340 Jul 13 18:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1241 Jul 13 19:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1693 Jul 13 19:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1858 Jul 13 19:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 13 19:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 651 Jul 13 19:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 739 Jul 13 19:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1894 Jul 13 20:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 294 Jul 13 20:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 13 20:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 586 Jul 13 20:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 996 Jul 13 20:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 203 Jul 13 20:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 594 Jul 13 21:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 2365 Jul 13 21:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1158 Jul 13 21:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 1065 Jul 13 21:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 949 Jul 13 21:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 2341 Jul 13 21:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 98 Jul 13 22:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 382 Jul 13 22:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 50 Jul 13 22:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 84 Jul 13 22:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 293 Jul 13 22:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 54 Jul 13 22:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 351 Jul 13 23:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 6 Jul 13 23:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 493 Jul 13 23:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 13 23:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 13 23:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 13 23:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 00:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 01:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 02:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 03:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 04:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 05:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 06:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 623 Jul 14 07:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 07:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 0 Jul 14 07:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 10755 Jul 14 07:39:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 6718 Jul 14 07:49:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 17484 Jul 14 07:59:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 30382 Jul 14 08:09:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 32052 Jul 14 08:19:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 47914 Jul 14 08:29:55 s_syslogng@clxp01ml syslog-ng[29324]: STATS: dropped 44719 Jul 14 08:41:31 s_syslogng@clxp01ml syslog-ng[8094]: STATS: dropped 37327 Jul 14 08:51:31 s_syslogng@clxp01ml syslog-ng[8094]: STATS: dropped 49299 -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: July 14, 2006 8:27 AM To: Syslog-ng users' and developers' mailing list Subject: RE: [syslog-ng] Syslog-ng dropped packets. On Fri, 2006-07-14 at 06:21 -0700, Vaibhav Goel wrote: > Hi Bazsi > > We are still having issues with dropped packets under heavy load. We > increased the size of rmem_default and rmem_max drastically but we are > not seeing much of an improvement....Maybe about 50% or so. Currently, > the sizes are > > $ > cat /proc/sys/net/core/rmem_default > 786426 > $ > cat /proc/sys/net/core/rmem_max > 1572852 > > Do you have any other suggestions? We are running syslog-ng 1.6.11. > > All the logging is done over TCP (except 1 UDP source but that doesn't > generate a lot of logging data). It would be important to know whether it is syslog-ng itself that drops messages or something else in the system. Do you have STATS lines in your logs? That shows how many lines were dropped by syslog-ng itself. It is also possible that it is the sending syslog-ng process that drops messages (in the case of TCP), you can verify this by checking the STATS line of the sending syslog-ng process. You can improve this situation somewhat by increasing log_fifo_size on the sender. 1.6.x sends messages on its TCP destination without flow control, which means that if the bandwidth of a TCP channel is less than the messages received, it could intentionally drop messages, that's what is shown in the DROPPED line. 2.0 supports flow control, which means that syslog-ng is trying to slow its inputs down to the rate of its output pipes. This could slow down applications at the end, but this is the only way to avoid dropping messages. -- Bazsi _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

1 0

log statistics messages
by Maurizio B 14 Jul '06

14 Jul '06

Hello, I've successfully replaced syslog on a Fedora5 box with syslog-ng 2.0rc1. My "newbie" concern is about the file /var/log/messages filling up with log statistics messages (every ten minutes) like these: Log statistics; processed='source(s_local)=19', processed='source(s_remote)=0', processed='destination(dsl_console)=0', processed='destination(dsl_maillog)=0', processed='destination(ds_emerg)=0', processed='destination(ds_alert)=0', processed='destination(df_uucp)=0', processed='destination(ds_err)=0', processed='destination(dfs_err)=0', processed='destination(dsl_messages)=16', processed='destination(dfs_crit)=0', How can I avoid such records to be recorded? Thanks Maurizio

1 0

filter on level don't work with kernel source
by Olleg Samoylov 14 Jul '06

14 Jul '06

$ syslog-ng --version syslog-ng 1.9.9 subj from syslog-ng.conf: source s_all { # message generated by Syslog-NG internal(); # function to send logs to) unix-stream("/dev/log"); # messages from the kernel file("/proc/kmsg" log_prefix("kernel: ")); }; filter f_at_least_crit { level(crit..emerg); }; log { source(s_all); filter(f_at_least_crit); destination(d_email2root); }; And I get emails like: Date: 2006-04-05T14:59:23+04:00 Facility: kern Level: debug Program: kernel ISO 9660 Extensions: Microsoft Joliet Level 3 Date: 2006-04-05T14:59:23+04:00 Facility: kern Level: debug Program: kernel ISO 9660 Extensions: Microsoft Joliet Level 3 -- Olleg Samoylov

2 2

RE: [syslog-ng] Syslog-ng dropped packets.
by Vaibhav Goel 14 Jul '06

14 Jul '06

Hi Bazsi We are still having issues with dropped packets under heavy load. We increased the size of rmem_default and rmem_max drastically but we are not seeing much of an improvement....Maybe about 50% or so. Currently, the sizes are $ > cat /proc/sys/net/core/rmem_default 786426 $ > cat /proc/sys/net/core/rmem_max 1572852 Do you have any other suggestions? We are running syslog-ng 1.6.11. All the logging is done over TCP (except 1 UDP source but that doesn't generate a lot of logging data). Thanks, -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: May 26, 2006 2:05 AM To: Syslog-ng users' and developers' mailing list Subject: RE: [syslog-ng] Syslog-ng dropped packets. On Thu, 2006-05-25 at 06:27 -0700, Vaibhav Goel wrote: > We are using 1.6.5 (soon to upgrade to 1.6.11) in a production > environment. Is 1.9.11 production ready? I recall a message from you > saying that you are looking to release 2.0.0 within a month. I will > install 1.9.11 on my QA server and start testing it once we deploy > 1.6.11 to prod. I am actually not using /dev/xconsole... I have 2 > production loghosts and one of them is more heavily used then the other. > I am seeing dropped packets on that one during peak hours. That leads > me to believe that syslog-ng. Is there a way to increase the incoming > buffer in another way? Are you using UDP or TCP transport? You could increase the socket receive buffer size. /proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max -- Bazsi _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

2 1

syslog-ng on IRIX?
by Andy G. 12 Jul '06

12 Jul '06

I'm trying to get syslog-ng to read from the log device /dev/log on IRIX, but it's not reading the messages. I tried these drivers: unix-stream: won't open /dev/log (io.c: bind_unix_socket(): /dev/log not a socket) unix-dgram: won't open /dev/log (io.c: bind_unix_socket(): /dev/log not a socket) file: opens, but no messages pipe: opens, but no messages I saw several similar posts asking how to get syslog-ng to work on IRIX, but no answers. Has anybody gotten this to work? Thanks, Andy

1 0

Problems compiling syslog-ng 1.6.11 on sparc running Solaris 10
by Stuart_Weaver＠ElementK.com 10 Jul '06

10 Jul '06

Hello. I am trying to build syslog-ng version 1.6.11 (I have also tried version 1.6.8 with the same results) on a sparc running Solaris 10 ( SunOS frylock 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V890 ). The output leads me to believe I may be missing a library. If anyone could help me out I would be very thankful. I am building with the following .... PATH=$PATH:/usr/elmk/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/ucb export PATH CC=/usr/elmk/bin/gcc export CC cd libol-0.3.18 && ./configure && gmake && cd .. && ./configure --prefix=/usr/local --with-libol=./libol-0.3.18 -with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld && gmake && gmake install The runtime linking environment looks as follows.... Default Library Path (ELF): /lib:/usr/lib:/usr/sfw/lib Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) The build stops while trying to compile syslog-ng with the following output.... /usr/elmk/bin/gcc -g -O2 -Wall -I/src/solaris10/syslog-ng/syslog-ng-1.6.8/libol-0.3.18/src -D_GNU_SOURCE -o syslog-ng main.o sources.o center.o filters.o destinations.o log.o cfgfile.o cfg-grammar.o cfg-lex.o affile.o afsocket.o afunix.o afinet.o afinter.o afuser.o afstreams.o afprogram.o afremctrl.o nscache.o utils.o syslog-names.o macros.o -lpthread -lnsl -lsocket -ldoor -lresolv /src/solaris10/syslog-ng/syslog-ng-1.6.8/libol-0.3.18/src/.libs/libol.a -lsocket -lnsl -lxnet -Wl,-Bstatic -ll -Wl,-Bdynamic ld: fatal: library -ll: not found ld: fatal: File processing errors. No output written to syslog-ng collect2: ld returned 1 exit status gmake[3]: *** [syslog-ng] Error 1 gmake[3]: Leaving directory `/src/solaris10/syslog-ng/syslog-ng-1.6.8/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/src/solaris10/syslog-ng/syslog-ng-1.6.8/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/src/solaris10/syslog-ng/syslog-ng-1.6.8/src' gmake: *** [all-recursive] Error 1 gcc version is ... Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ./configure --prefix=/usr/elmk -with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 4.1.1

2 2

segfaults with 1.9.x series syslog-ng and stream socket
by func tionate 30 Jun '06

30 Jun '06

I have written a sql stream socket daemon that for now is listening on /var/tmp/syslog-socket and passes inserts to child processes. Starting syslog-ng up with this socket as a destination on both the latest beta release and today's cvs of 1.9.x (2.0rc1) cause it to bomb out with a segfault. I have tested this both on an x86_64 linux gentoo amd64 box and a centos 4 i386 xeon box. I have used the same stream socket daemon with the latest 1.6 release and it has been reliable. I have configured syslog-ng and built it with stock ./configure. also, when i pull out the stream socket and associated config and start the daemon, everything works as expected. Below I've included the only deviations from the syslog-ng.conf RedHat config from the contrib directory (and the source definition for clarity), and an strace. Please let me know if there is any further info i can provide. (some cleansing of node names was done for obvious reasons) Regards, Chris source s_sys { file ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); }; destination syslog-stream { unix-stream("/var/tmp/syslog-socket" template("INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( '$HOST', '$FACILITY', '$PRIORITY', '$LEVEL','$TAG', '$YEAR-$MONTH-$DAY', '$HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n") template_escape(yes) ) ; }; log { source(s_sys); destination(syslog-stream); }; root@host-1 [/usr/local/sbin] # /usr/bin/strace syslog-ng execve("/usr/local/sbin/syslog-ng", ["syslog-ng"], [/* 20 vars */]) = 0 uname({sys="Linux", node="host-1.domain.com", ...}) = 0 brk(0) = 0x934f000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=50262, ...}) = 0 old_mmap(NULL, 50262, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff3000 close(3) = 0 open("/lib/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320dH\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=95148, ...}) = 0 old_mmap(0x483000, 88064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x483000 old_mmap(0x495000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x495000 old_mmap(0x497000, 6144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x497000 close(3) = 0 open("/lib/tls/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320P,\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=47671, ...}) = 0 old_mmap(0x2c3000, 81656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2c3000 old_mmap(0x2cb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x2cb000 old_mmap(0x2cd000, 40696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2cd000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20_\24"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1454546, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff2000 old_mmap(0x131000, 1219772, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x131000 old_mmap(0x255000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0x255000 old_mmap(0x259000, 7356, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x259000 close(3) = 0 open("/lib/tls/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\350)\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=93985, ...}) = 0 old_mmap(0x29a000, 70108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x29a000 old_mmap(0x2a8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x2a8000 old_mmap(0x2aa000, 4572, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2aa000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff1000 mprotect(0x255000, 4096, PROT_READ) = 0 mprotect(0x12d000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff16c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7ff3000, 50262) = 0 set_tid_address(0xb7ff1708) = 31245 rt_sigaction(SIGRTMIN, {0x29e380, [], SA_RESTORER|SA_SIGINFO, 0x2a5880}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x29e3f0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x2a5880}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 _sysctl({{CTL_KERN, KERN_VERSION, 0, 20d91, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 2, 0xbfe4743c, 34, (nil), 0}) = 0 brk(0) = 0x934f000 brk(0x9370000) = 0x9370000 open("/etc/localtime", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fff000 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267 close(3) = 0 munmap(0xb7fff000, 4096) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0 rt_sigaction(SIGHUP, {0x804a814, [], SA_RESTORER, 0x1588e8}, NULL, 8) = 0 rt_sigaction(SIGTERM, {0x804a824, [], SA_RESTORER, 0x1588e8}, NULL, 8) = 0 rt_sigaction(SIGINT, {0x804a824, [], SA_RESTORER, 0x1588e8}, NULL, 8) = 0 rt_sigaction(SIGCHLD, {0x804a84c, [], SA_RESTORER, 0x1588e8}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x804a834, [], SA_RESTORER|SA_ONESHOT, 0x1588e8}, NULL, 8) = 0 open("/etc/eventlog.conf", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/etc/syslog-ng.conf", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe473f8) = -1 ENOTTY (Inappropriate ioctl for device) fstat64(3, {st_mode=S_IFREG|0644, st_size=3080, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fff000 read(3, "# syslog-ng configuration file.\n"..., 8192) = 3080 read(3, "", 4096) = 0 read(3, "", 8192) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe46eb8) = -1 ENOTTY (Inappropriate ioctl for device) close(3) = 0 munmap(0xb7fff000, 4096) = 0 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 4 fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl64(4, F_GETFD) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 stat64("/dev/log", {st_mode=S_IFSOCK|0666, st_size=0, ...}) = 0 unlink("/dev/log") = 0 bind(4, {sa_family=AF_FILE, path="/dev/log"}, 11) = 0 listen(4, 255) = 0 chmod("/dev/log", 0666) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- kill(31245, SIGSEGV) = 0 sigreturn() = ? (mask now []) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 31245 detached root@host-1 [/usr/local/sbin] # ./syslog-ng --version syslog-ng 2.0rc1 root@host-1 [/usr/local/sbin] # uname -a Linux host-1.domain.com 2.6.9-11.ELsmp #1 SMP Wed Jun 8 17:54:20 CDT 2005 i686 i686 i386 GNU/Linux

3 4

Rick Daoust is out of the office - Rick Daoust est hors du bureau
by Rick.Daoust＠borealc.on.ca 28 Jun '06

28 Jun '06

I will be out of the office starting 26/06/2006 and will not return until 03/07/2006. Je serai hors du bureau à partir de lundi le 26 juin 2006 et retournerai que lundi le 3 juillet 2006!

1 0

using a logfile per host, with it's own name
by Jacco Rens 27 Jun '06

27 Jun '06

Hi List-members, I just started using syslog-ng, and I am still not confident with the technique to write the config files. What I basically want, is every host that send the udp syslog, to log in it's own file. Hereunder is what I have now, but that seems not to do the trick. Maybe there's an better technique for this? And I don't want the program, where '/var/log/HOSTS/$HOST/' is used. Best, Jacco options { use_dns(no); keep_hostname(yes); long_hostnames(off); sync(1); log_fifo_size(1024); create_dirs(yes); }; source src { udp(); }; # # ADSL logfiles # destination d_adsluitgeest { file("/var/log/routers/ adsluitgeest.log"); }; destination d_adslhaarlem { file("/var/log/routers/adslhaarlem.log"); }; destination d_adslbijenkorf { file("/var/log/routers/ adslbijenkorf.log"); }; destination d_adslcs { file("/var/log/routers/adslcs.log"); }; destination d_adslalkmaar { file("/var/log/routers/adslalkmaar.log"); }; # # ADSL filters # filter f_adsluitgeest { host(192.168.1.2); }; filter f_adslhaarlem { host(192.168.4.2); }; filter f_adslbijenkorf { host(192.168.3.2); }; filter f_adslcs { host(192.168.2.2); }; filter f_adslalkmaar { host(192.168.5.2); }; # # ADSL programs # log { source(src); filter(f_adsluitgeest); destination (d_adsluitgeest); }; log { source(src); filter(f_adslhaarlem); destination(d_adslhaarlem); }; log { source(src); filter(f_adslbijenkorf); destination (d_adslbijenkorf); }; log { source(src); filter(f_adslcs); destination(d_adslcs); }; log { source(src); filter(f_adslalkmaar); destination(d_adslalkmaar); };

1 0

facilities
by donjames 25 Jun '06

25 Jun '06

Hi, Where is the list of allowable facilities for use with syslog-ng? Sincerely, Don

2 1

global option dir_group() didn't take effect
by Wolfram Schlich 23 Jun '06

23 Jun '06

Syslog-NG (1.9.11) was configured with the global option dir_group(adm), but directories it created were root:root. Anyone else experiencing this? -- Regards, Wolfram Schlich <wschlich(a)gentoo.org> Gentoo Linux * http://dev.gentoo.org/~wschlich/

2 3

suppress repeated messages feature in 2.0 ?
by stucky 23 Jun '06

23 Jun '06

Balzi Sorry if this is redundant. I thought I read something about it but I can't find it anymore so I thought I ask again. It's a very simple question. Will syslog-ng-2.0 include the 'suppress repeated messages' feature that syslogd has ? That's the one thing I really miss since it causes email floods (5000 and more at one time). I know there is stuff like SEC and I am trying to look into it. However, I like the mechanism I have in place right now except it has no threshold feature. I honestly believe that this should be accomplished by the log daemon itself rather than a parser. Just something similar to syslogd where it prints a certain burst of 5 or 10 messages of the same kind that then adds one line saying "previous message repeated 1000 times" etc.. I know with SEC I can say if this message shows up x times within a certain window then alert me. However that's not really what I want. I want a logparser that says if one source logs the same message 1000 times in a row then alert me once and skip the other messages... Well I'm sure everyone knows what I'm talking about. Is anyone using SEC in conjunction with syslog-ng to achieve exactly that ? -- stucky

1 0

RE: [syslog-ng] Losing TAG information
by SOLIS, ALEX 22 Jun '06

22 Jun '06

I appreciate your sympathy but it does not help me with my TAG problem. :) Anyone else have any idea how to stop syslog-ng from purging the TAG information from an AIX syslogd message. I have successfully sniffed syslog traffic between the AIX servers and my LOGHOST. The TAG (Process Name info) is definitely intact on the wire. This confirms that syslog-ng is simply parsing the log message and removing the TAG info. I did some more tests on the Linux LOGHOST using the logger utility and I found that syslog-ng does not like spaces after the TAG information. For example: 1) Logger -p syslog.info -t "TEST_TAG" "TEST_MESSAGE" Generates the log: Jun 19 08:42:38 loghost TEST_TAG: TEST_MESSAGE 2) Logger -p syslog.info -t "TEST_TAG " "TEST_MESSAGE" Generates the log: Jun 19 08:44:08 loghost : TEST_MESSAGE Example two lost the TAG information because of the space after TEST_TAG. I have considered the possibility that the messages being sent from the AIX box do not conform to syslog formatting standards and therefore syslog-ng discards the field. But I would like to know if there is anything that can be done to stop this behavior. Thanks for all responses, even sympathetic ones. :) Alex -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, June 13, 2006 9:09 PM To: SOLIS, ALEX Subject: Re: [syslog-ng] Losing TAG information On Tue, 13 Jun 2006 10:07:33 CDT, "SOLIS, ALEX" said: (off-list reply) > I have about 20 or so AIX 4.3 servers that are sending syslog messages > to a Linux desktop running syslog-ng 1.6.5. You have my condolences. IBM dropped support for even AIX 4.3.3 several years ago - hopefully you're not having problems keeping the software running and secure... -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, June 13, 2006 9:09 PM To: SOLIS, ALEX Subject: Re: [syslog-ng] Losing TAG information On Tue, 13 Jun 2006 10:07:33 CDT, "SOLIS, ALEX" said: (off-list reply) > I have about 20 or so AIX 4.3 servers that are sending syslog messages > to a Linux desktop running syslog-ng 1.6.5. You have my condolences. IBM dropped support for even AIX 4.3.3 several years ago - hopefully you're not having problems keeping the software running and secure... This e-mail contains Omaha Public Power District's confidential and proprietary information and is for use only by the intended recipient. Unless explicitly stated otherwise, this e-mail is not a contract offer, amendment, nor acceptance. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

3 5

unattended-gui 0.3 released -> module syslog-ng
by Mario Gzuk 22 Jun '06

22 Jun '06

Hi, with the module syslog-ng you can manage several syslog-ng servers wich are logging into several databases and tables. Search is possible over all servers as a timeline or per table. Main content of this release: Support automatic installations of the following operating systems: * Windows Xp * Windows 2003 * SuSE Linux 10.1 * Red Hat Enterprise Linux 4 * Fedora Core 5 * CentOS 4.3 * Whit Box Enterprise Linux 4 * Scientific Linux 4.3 * Aurox 11.1 New modules: * php-ssh * usersettings * dhcp-ldap * samhain * syslog-ng * ldap-manager * cron Please have a look at the documentation: http://unattended.technikz.de/index.php/Documentation If there is something missing or if you need help feel free to use the forum here: http://sourceforge.net/forum/?group_id=127437 or the mailing list: http://sourceforge.net/mail/?group_id=127437 greetings mario gzuk

1 0

Syslog-NG and STunnel
by Wolfram Schlich 22 Jun '06

22 Jun '06

I'm currently trying out this setup: - logserver at home, connected via ADSL with a fixed IPv4 subnet - IP address: 192.168.0.1 - syslog-ng listening on 127.0.0.1:514 TCP - stunnel listening on 192.168.0.1:514 TCP and connecting to 127.0.0.1:514 TCP - logclient at a remote datacenter - IP address: 172.16.0.1 - syslog-ng delivering to 127.0.0.1:514 TCP - stunnel listening on 127.0.0.1:514 TCP and connecting to 192.168.0.1:514 TCP Here are the STunnel configs: --8<--[ stunnel.conf on logserver (excluding cert/key stuff) ]--8<-- [syslog-ng] client = no accept = 192.168.0.1:514 local = 127.0.0.1 connect = 127.0.0.1:514 --8<-- --8<--[ stunnel.conf on logclient (excluding cert/key stuff) ]--8<-- [syslog-ng] client = yes accept = 127.0.0.1:514 local = 172.16.0.1 connect = 192.168.0.1:514 --8<-- This works fine so far, logs are sent over the encrypted tunnel without problems. Except one situation: the STunnel or Syslog-NG itself on the logserver goes down. Then this happens on the logclient: --8<-- syslog-ng[30119]: EOF occurred while idle; fd='33' --8<-- There are *lots* of those messages, like 20 per second. Is it possible to prevent Syslog-NG of creating such messages? -- Wolfram Schlich

2 3

priority and facility gone when using template for remote logging
by Wolfram Schlich 22 Jun '06

22 Jun '06

On the logserver the priority.facility of all incoming log messages was "user.notice" instead of the original value. I used this on the logclient: template t_remote_s { template("${DATE} ${HOST} ${MSG}\n"); template_escape(no); }; destination d_remote { udp("syslog.mydomain.tld" port(514) template(t_remote_s)); }; log { source(s_local); source(s_kernel); destination(d_remote); }; When *not* using a template for the remote destination, everything works as expected, priority.facility is back with good values. Any idea why this happens? -- Wolfram Schlich

3 4

global option chain_hostnames() not explained
by Wolfram Schlich 21 Jun '06

21 Jun '06

Unfortunately the documentation leaves it unclear what exactly chain_hostnames() does. I just guess it does something like creating a chained hostname in the form "host1/host2/host3". What about use_fqdn() in that case? Will it be "host1.example.com/host2.example.com/host3.example.com"? Am I right when I think that use_fqdn() does only take effect for the hostname where syslog-ng is currently running on? Let's say use_fqdn() is on on host1 and host3 and off on host2. I guess it would look like this then: "host1.example.com/host2/host3.example.com" Can somebody clear it up? :-) -- Wolfram Schlich

2 1

Syslog-NG (1.9) documentation issues (lots of...)
by Wolfram Schlich 20 Jun '06

20 Jun '06

Referencing the current 2.0 online manual: http://www.balabit.com/products/syslog_ng/reference-2.0/syslog-ng.html/ - Table 3.13 - TZOFFSET: documented as '-0700', is effectively '-07:00'. - DATE: description is missing. Looks like "Jun 13 15:58:00". - FULLDATE: -"-. Looks like "2006 Jun 13 15:56:57". - ISODATE: -"-. Looks like "2006-06-13T15:56:51+02:00". - UNIXTIME: -"-. Standard UNIX timestamp. - FULLHOST, HOST_FROM, FULLHOST_FROM, SOURCEIP: -"- - 3.2: - fsync(), timezone() and ts_format() are undocumented (obviously, the ts_format() part just needs to be copied from 3.5) - 3.2.2.5 usertty(): - documented to support template(), but... ...this works (of course it does): destination d_admintty { usertty("root"); }; ...this makes 'syslog-ng -s' complain about a syntax error: destination d_admintty { usertty("root" template(t_admintty)); }; - 3.5 Options: - sync() and sync_freq() are marked as obsolete with flush_lines() as the successor, unfortunately flush_lines() itself is not documented in 3.5 (only in 3.2 with a reference to the global default which is just not present). - flush_timeout() is not documented in 3.5 (only in 3.2, just like flush_lines()) Yet more to come (no time right now :-() -- Regards, Wolfram Schlich <wschlich(a)gentoo.org> Gentoo Linux * http://dev.gentoo.org/~wschlich/

3 5

Re: [syslog-ng] plain stupid?
by Jacco Rens 20 Jun '06

20 Jun '06

On 20-jun-2006, at 21:37, Leonard Mills wrote: > Jacco wrote: > >> source s_1 { udp(ip(192.168.1.2) port(514)); >> source s_2 { udp(ip(192.168.2.2) port(514)); > > Those lines have mismatched {(...)} pairs. Plain stupid thus ;-) Thanks for all replies! - jacco

1 0

plain stupid?
by Jacco Rens 20 Jun '06

20 Jun '06

Hi list, I'm trying out syslog-ng for only an hour now, and got it logging all udp traffic to one file fine, but now I think I'm doing stupid, althoug this seemed logical to me: options { use_fqdn(yes); use_dns(yes); dns_cache(yes); keep_hostname(yes); long_hostnames(on); sync(1); log_fifo_size(1024); create_dirs(yes); }; source s_1 { udp(ip(192.168.1.2) port(514)); source s_2 { udp(ip(192.168.2.2) port(514)); destination d_1 { file("/var/log/1.log"); }; destination d_2 { file("/var/log/2.log"); }; log { source(s_1); destination(d_1); }; log { source(s_2); destination(d_2); }; It poops an error: ] mini:/var/log root# syntax error at 14 Parse error reading configuration file, exiting. (line 14) Thanks for your insight. - jacco

3 2

Future releases
by Anders.Backlund＠vattenfall.com 20 Jun '06

20 Jun '06

I was looking at the syslog-ng roadmap on the balabit webpage. I am aware of that you might not have made a final decision on the subject, but I am still curious For version 2.2 you state that you will have support for the BEEP protocol. By that do you mean RFC 3195? Do you have any plans for the upcoming syslog RFC (syslog-new, syslog-sign, syslog-tls)? Anders Backlund

1 0

RE: [syslog-ng] Losing TAG information
by SOLIS, ALEX 20 Jun '06

20 Jun '06

That is interesting. Thinking it is a version problem, I upgraded syslog-ng on another machine to 1.6.9. I attempted the same test below and got the same results. A space in the tag causes the TAG information to disappear. I am curious Evan, what are your syslog-ng options? I guess now it could be my LOGHOST environment. I am running syslog-ng 1.6.9 on a gentoo linux box running kernel 2.6-15. Here is another example of what this box does: # logger -t "alex" funny # logger -t "alex " funny Results: Jun 19 11:53:04 src@lookout alex: funny Jun 19 11:53:30 src@lookout : funny These results are on a totally separate box running a new version of syslog-ng. Since it worked in Evan's example below, syslog-ng might not be the one to blame. But what other factors could cause me to lose the TAG information of a local syslog message other than the process accepting, parsing, and storing the message itself; syslog-ng? Alex -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Evan Rempel Sent: Monday, June 19, 2006 12:50 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Losing TAG information In an AIX 5.2 machine % logger -t evan funny % logger -t "evan " funny results in Jun 19 10:47:17 casa.comp.uvic.ca casa: evan: funny Jun 19 10:47:25 casa.comp.uvic.ca casa: evan : funny In AIX 4.3.3 % logger -t evan funny % logger -t "evan " funny results in Jun 19 10:48:57 casual.uvic.ca casual: evan: funny Jun 19 10:49:03 casual.uvic.ca casual: evan : funny So, it would appear that the 1.6.8 syslog-ng does not suffer from the symptoms you describe. Evan. SOLIS, ALEX wrote: > Thank you for your reply Evan. > > So, if you attempt what I did in bullet two in the previous post below > do you get different results? If you do, then maybe I should consider > upgrading my version of syslog-ng. Thanks again. > > > Alex > > > -----Original Message----- > From: syslog-ng-bounces(a)lists.balabit.hu > [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Evan Rempel > Sent: Monday, June 19, 2006 10:38 AM > To: Syslog-ng users' and developers' mailing list > Subject: Re: [syslog-ng] Losing TAG information > > All I can really add is that we have a mix ov AIX 4.3.3 through 5.3 that > are logging to a linux syslog-ng 1.6.8 machine > and we are not experiencing the symptoms that you describe. I have a > couple of applications where the tag ends up being > "syslog" when it should be something else, but that is quite a bit > different than removing it entirely. > > Evan. > > SOLIS, ALEX wrote: >> I appreciate your sympathy but it does not help me with my TAG > problem. >> :) >> >> Anyone else have any idea how to stop syslog-ng from purging the TAG >> information from an AIX syslogd message. I have successfully sniffed >> syslog traffic between the AIX servers and my LOGHOST. The TAG > (Process >> Name info) is definitely intact on the wire. This confirms that >> syslog-ng is simply parsing the log message and removing the TAG info. >> >> I did some more tests on the Linux LOGHOST using the logger utility > and >> I found that syslog-ng does not like spaces after the TAG information. >> For example: >> >> 1) Logger -p syslog.info -t "TEST_TAG" "TEST_MESSAGE" >> >> Generates the log: >> >> Jun 19 08:42:38 loghost TEST_TAG: TEST_MESSAGE >> >> >> 2) Logger -p syslog.info -t "TEST_TAG " "TEST_MESSAGE" >> >> Generates the log: >> >> Jun 19 08:44:08 loghost : TEST_MESSAGE >> >> Example two lost the TAG information because of the space after >> TEST_TAG. I have considered the possibility that the messages being >> sent from the AIX box do not conform to syslog formatting standards > and >> therefore syslog-ng discards the field. But I would like to know if >> there is anything that can be done to stop this behavior. >> >> Thanks for all responses, even sympathetic ones. :) >> >> Alex >> >> >> -----Original Message----- >> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] >> Sent: Tuesday, June 13, 2006 9:09 PM >> To: SOLIS, ALEX >> Subject: Re: [syslog-ng] Losing TAG information >> >> On Tue, 13 Jun 2006 10:07:33 CDT, "SOLIS, ALEX" said: >> >> (off-list reply) >> >>> I have about 20 or so AIX 4.3 servers that are sending syslog > messages >>> to a Linux desktop running syslog-ng 1.6.5. >> You have my condolences. IBM dropped support for even AIX 4.3.3 > several >> years ago - hopefully you're not having problems keeping the software >> running and secure... >> -----Original Message----- >> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] >> Sent: Tuesday, June 13, 2006 9:09 PM >> To: SOLIS, ALEX >> Subject: Re: [syslog-ng] Losing TAG information >> >> On Tue, 13 Jun 2006 10:07:33 CDT, "SOLIS, ALEX" said: >> >> (off-list reply) >> >>> I have about 20 or so AIX 4.3 servers that are sending syslog > messages >>> to a Linux desktop running syslog-ng 1.6.5. >> You have my condolences. IBM dropped support for even AIX 4.3.3 > several >> years ago - hopefully you're not having problems keeping the software >> running and secure... >> >> This e-mail contains Omaha Public Power District's confidential and > proprietary information and is for use only by the intended recipient. > Unless explicitly stated otherwise, this e-mail is not a contract offer, > amendment, nor acceptance. If you are not the intended recipient you > are notified that disclosing, copying, distributing or taking any action > in reliance on the contents of this information is strictly prohibited. >> _______________________________________________ >> syslog-ng maillist - syslog-ng(a)lists.balabit.hu >> https://lists.balabit.hu/mailman/listinfo/syslog-ng >> Frequently asked questions at http://www.campin.net/syslog-ng/faq.html >> >> > > -- Evan Rempel erempel(a)uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html This e-mail contains Omaha Public Power District's confidential and proprietary information and is for use only by the intended recipient. Unless explicitly stated otherwise, this e-mail is not a contract offer, amendment, nor acceptance. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 1