- syslog-ng - lists.balabit.hu

Error when starting syslog-ng
by Kai Wang 30 Jul '01

30 Jul '01

I have been running syslog-ng on aix 4.3.3 maintenance level 6 for monthes. I cloned our log server and found syslog-ng could not start on the new machine. I haven't changed a thing. # syslog-ng -v binding fd 3, unixaddr: /dev/log binding fd 4, inetaddr: 0.0.0.0, port: 514 Error creating AF_INET socket (Error 0) Error initializing configuration, exiting. Kai

1 0

syslog-ng forwarding logs over TCP.
by Ramji Chandramouli 27 Jul '01

27 Jul '01

Hi, I'm new to using syslog-ng as well as this mailing list. I'm particularly interested in the syslog-ng feature of forwarding logs over TCP. I think the version of syslog-ng I'm using is 1.4.10. The following is a scenario in which I'm having a log-forwarding problem. I have set up syslog-ng to forward logs over TCP to a server syslog-ng on a remote machine. Sometime during the log-forwarding, if the server syslog-ng dies for some unexpected reason, I find that the client syslog-ng does not recognize right away that the connection has been dropped. In fact, if there is a message, message #1, to be forwarded after the server syslog-ng has died, the client syslog-ng forwards message #1 and does not recognize that the connection is not alive. It is only when a second message, message #2, is to be forwarded that the client syslog-ng recognizes the error and I see a "io.c: do_write: write() failed". The problem is that when the server syslog-ng is brought back up, only message #2 is sent to the server syslog-ng. message #1 never gets to the server syslog-ng. Has this problem been already addressed in the subsequent versions ? Thanks.

1 0

TCP Wrapping Syslog
by Brian E. Seppanen 26 Jul '01

26 Jul '01

Hi: Does syslog-ng support tcp wrappers such that I could use hosts.allow to specify the hosts allowed to write syslog messages to a specific hosts? Does anyone no if legally syslog messages are null and void if an outside hosts write to a syslog server? If syslog-ng does support tcp wrappers what is the specific syntax would I refer to it as syslog: syslog-ng: or syslogd: thanks, Brian Seppanen seppy(a)chartermi.net 906-228-4226 ext 23

2 1

syslog-ng's memory footprint growing constantly
by Craig J Constantine 26 Jul '01

26 Jul '01

Hi, Basically, the memory size of the process simply grows and grows: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 13899 0.1 19.3 25412 24764 ? S Jul24 2:05 syslog-ng That was snapped after about 4 hours of run time. If I let it run for days... well, it once got to 90000 VSZ before the box choked for lack of RAM. For gauging how heavily worked syslog-ng is, the line counts for all the files it writes (this is one day of logs) are: 0 UNCAUGHT.messages 180 facility.auth 68 facility.authpriv 1 facility.cron 15651 facility.daemon 1 facility.ftp 0 facility.kern 196 facility.local0 48 facility.local1 1 facility.local2 1 facility.local3 1532 facility.local4 1 facility.local5 1 facility.local6 31 facility.local7 1 facility.lpr 793 facility.mail 1 facility.news 16 facility.syslog 2 facility.user 1 facility.uucp 8818 service.mail 20395 service.popd 4083 service.radiusd 51822 total and total only about 6Mb in size. Is there something with internal buffers or garbage collection that I'm oblivious to? LARTs or terse FAQ pointers welcome... :) syslog-ng 1.4.11 on Linux (RedHat 6) on Intel with 128M mostly unused. Configuration is (sorry it's so long): ----------start config----------- options { chain_hostnames(no); use_fqdn(yes); create_dirs(yes); dir_perm(0755); sync(0); owner(root); group(web); perm(0644); }; source s_l { unix-stream("/dev/log"); internal(); }; source s_r { udp(ip( REAL_IP_HERE ) port(514)); }; destination local_kern { file("/var/log/syslog-ng/current/localhost.kern"); }; destination svc_radiusd { file("/var/log/syslog-ng/current/service.radiusd"); }; destination svc_popd { file("/var/log/syslog-ng/current/service.popd"); }; destination svc_mail { file("/var/log/syslog-ng/current/service.mail"); }; destination fac_auth { file("/var/log/syslog-ng/current/facility.auth"); }; destination fac_authpriv { file("/var/log/syslog-ng/current/facility.authpriv"); }; destination fac_cron { file("/var/log/syslog-ng/current/facility.cron"); }; destination fac_daemon { file("/var/log/syslog-ng/current/facility.daemon"); }; destination fac_ftp { file("/var/log/syslog-ng/current/facility.ftp"); }; destination fac_kern { file("/var/log/syslog-ng/current/facility.kern"); }; destination fac_lpr { file("/var/log/syslog-ng/current/facility.lpr"); }; destination fac_mail { file("/var/log/syslog-ng/current/facility.mail"); }; destination fac_news { file("/var/log/syslog-ng/current/facility.news"); }; destination fac_syslog { file("/var/log/syslog-ng/current/facility.syslog"); }; destination fac_user { file("/var/log/syslog-ng/current/facility.user"); }; destination fac_uucp { file("/var/log/syslog-ng/current/facility.uucp"); }; destination fac_local0 { file("/var/log/syslog-ng/current/facility.local0"); }; destination fac_local1 { file("/var/log/syslog-ng/current/facility.local1"); }; destination fac_local2 { file("/var/log/syslog-ng/current/facility.local2"); }; destination fac_local3 { file("/var/log/syslog-ng/current/facility.local3"); }; destination fac_local4 { file("/var/log/syslog-ng/current/facility.local4"); }; destination fac_local5 { file("/var/log/syslog-ng/current/facility.local5"); }; destination fac_local6 { file("/var/log/syslog-ng/current/facility.local6"); }; destination fac_local7 { file("/var/log/syslog-ng/current/facility.local7"); }; destination uncaught { file("/var/log/syslog-ng/current/UNCAUGHT.messages"); }; filter f_auth { facility(auth); }; filter f_authpriv { facility(authpriv); }; filter f_cron { facility(cron); }; filter f_daemon { facility(daemon); }; filter f_ftp { facility(ftp); }; filter f_kern { facility(kern); }; filter f_lpr { facility(lpr); }; filter f_mail { facility(mail); }; filter f_news { facility(news); }; filter f_syslog { facility(syslog); }; filter f_user { facility(user); }; filter f_uucp { facility(uucp); }; filter f_local0 { facility(local0); }; filter f_local1 { facility(local1); }; filter f_local2 { facility(local2); }; filter f_local3 { facility(local3); }; filter f_local4 { facility(local4); }; filter f_local5 { facility(local5); }; filter f_local6 { facility(local6); }; filter f_local7 { facility(local7); }; filter f_pri-gte-notice { priority(notice) or priority(emerg) or priority(alert) or priority(crit) or priority(err) or priority(warning); }; filter f_pri-gte-warning { priority(emerg) or priority(alert) or priority(crit) or priority(err) or priority(warning); }; filter f_pri-gte-err { priority(emerg) or priority(alert) or priority(crit) or priority(err); }; filter f_radiusd { program("radiusd"); }; filter f_popd { program("popd"); }; # A file for kern facility messages from this host only. log { source(s_l); filter(f_kern); destination(local_kern); }; # Log paths organizing all entries by facility. log { source(s_l); source(s_r); filter(f_auth); destination(fac_auth); }; log { source(s_l); source(s_r); filter(f_authpriv); destination(fac_authpriv); }; log { source(s_l); source(s_r); filter(f_cron); destination(fac_cron); }; log { source(s_l); source(s_r); filter(f_daemon); destination(fac_daemon); }; log { source(s_l); source(s_r); filter(f_ftp); destination(fac_ftp); }; log { source(s_l); source(s_r); filter(f_kern); destination(fac_kern); }; log { source(s_l); source(s_r); filter(f_lpr); destination(fac_lpr); }; log { source(s_l); source(s_r); filter(f_mail); filter(f_pri-gte-notice); destination(fac_mail); }; log { source(s_l); source(s_r); filter(f_mail); destination(svc_mail); }; log { source(s_l); source(s_r); filter(f_news); destination(fac_news); }; log { source(s_l); source(s_r); filter(f_syslog); destination(fac_syslog); }; log { source(s_l); source(s_r); filter(f_user); destination(fac_user); }; log { source(s_l); source(s_r); filter(f_uucp); destination(fac_uucp); }; # LOCAL0 facility is primarily used for POPD information. log { source(s_l); source(s_r); filter(f_local0); filter(f_pri-gte-notice); destination(fac_local0); }; log { source(s_l); source(s_r); filter(f_local0); filter(f_popd); destination(svc_popd); }; log { source(s_l); source(s_r); filter(f_local1); destination(fac_local1); }; log { source(s_l); source(s_r); filter(f_local2); destination(fac_local2); }; log { source(s_l); source(s_r); filter(f_local3); destination(fac_local3); }; log { source(s_l); source(s_r); filter(f_local4); destination(fac_local4); }; # LOCAL5 facility is primarily used for RADIUS information. log { source(s_l); source(s_r); filter(f_local5); filter(f_pri-gte-notice); destination(fac_local5); }; log { source(s_l); source(s_r); filter(f_local5); filter(f_radiusd); destination(svc_radiusd); }; log { source(s_l); source(s_r); filter(f_local6); destination(fac_local6); }; log { source(s_l); source(s_r); filter(f_local7); destination(fac_local7); }; # Catchall. If anything appears in here, we have something misconfigured. log { source(s_l); source(s_r); filter(DEFAULT); destination(uncaught); }; ----------stop config------------ -Craig

2 1

RE: [syslog-ng]Eliminating certain keyword from the "all" directi ve?
by Hamilton, Andrew Mr RAYTHEON 5 SIG CMD 25 Jul '01

25 Jul '01

Stephen, Oh, then set up a filter: filter f_all_others { not facility(mail); }; Is this what you are looking for? This will get everything except the mail facility. Then you set whatever destinations you like. Regards, Drew -----Original Message----- From: Stephen C Burns [mailto:sburns@farpointer.net] Sent: Wednesday, July 25, 2001 7:24 AM To: syslog-ng(a)lists.balabit.hu Subject: RE: [syslog-ng]Eliminating certain keyword from the "all" directive? Thank you Drew, I already have something similar set up. I was not descriptive enough in my question. I have the default filter set. I have each one of my services logging to their own .log file. All messages to these individual .log files also go to the "all" destination which is a different file than the file for the default filter. And all that is fine - however, I would like for the mail messages to go to their own separate .log file only - and have no entry in the "all" file. I don't want to set them to /dev/null because I do want them, I just don't want them in the "all" file. :-) (They are not currently being logged to the "default" file) Thank you! -----Original Message----- From: syslog-ng-admin(a)lists.balabit.hu [mailto:syslog-ng-admin@lists.balabit.hu] On Behalf Of Hamilton, Andrew Mr RAYTHEON 5 SIG CMD Sent: Tuesday, July 24, 2001 11:55 PM To: 'syslog-ng(a)lists.balabit.hu' Subject: RE: [syslog-ng]Eliminating certain keyword from the "all" directive? Stephen, Sure there's a way. Syslog-ng is a full service application after all. You want to set up a destination and a filter: destination mail { file("/var/adm/maillogs"); }; filter f_mail { facility(mail); }; log { source(src); filter(f_mail); destination(mail); }; log { source(src); filter(DEFAULT); destination(all); }; The DEFAULT is a macro that will basically log everything that hasn't already been logged. If you just didn't want your mail logs just set the file to /dev/null or something. There are probably other ways to do this but this seems the most straight forward to me. Regards, DRew -----Original Message----- From: Stephen C Burns [mailto:sburns@farpointer.net] Sent: Tuesday, July 24, 2001 9:42 PM To: syslog-ng(a)lists.balabit.hu Subject: [syslog-ng]Eliminating certain keyword from the "all" directive? Hi all, I have a question regarding the redirection of certain log messages to files. I currently have the "all" directive sending every syslog message into /var/log/messages, via: destination all { file("/var/log/messages"); }; And that is great, except I don't want my mail messages getting sent into the messages file as well as this takes up a lot of space. So I basically need some way to say "send all messages except for mail messages into /var/log/messages" Is there such a way? Thank you for any help!! _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng

3 2

couple bugs in syslog-ng-1.5.8
by Jay Soffian 25 Jul '01

25 Jul '01

Couple bugs in syslog-ng-1.5.8, patch included. j. ---------------------------------------------------------------------- diff -r -u syslog-ng-1.5.8.orig/configure syslog-ng-1.5.8/configure --- syslog-ng-1.5.8.orig/configure Wed Jul 11 07:11:01 2001 +++ syslog-ng-1.5.8/configure Wed Jul 25 01:56:01 2001 @@ -837,7 +837,7 @@ fi -sysconfdir="${sysconfdir}/syslog-ng" +sysconfdir="${sysconfdir}/syslog-ng/" echo $ac_n "checking whether build environment is sane""... $ac_c" 1>&6 echo "configure:844: checking whether build environment is sane" >&5 diff -r -u syslog-ng-1.5.8.orig/src/affile.c syslog-ng-1.5.8/src/affile.c --- syslog-ng-1.5.8.orig/src/affile.c Wed Jul 11 07:10:16 2001 +++ syslog-ng-1.5.8/src/affile.c Wed Jul 25 01:56:48 2001 @@ -520,6 +520,7 @@ } case M_FULLDATE: case M_ISODATE: + case M_DATE: case M_WEEKDAY: case M_YEAR: case M_MONTH: ----------------------------------------------------------------------

2 1

RE: [syslog-ng]Eliminating certain keyword from the "all" directi ve?
by Hamilton, Andrew Mr RAYTHEON 5 SIG CMD 25 Jul '01

25 Jul '01

Stephen, Sure there's a way. Syslog-ng is a full service application after all. You want to set up a destination and a filter: destination mail { file("/var/adm/maillogs"); }; filter f_mail { facility(mail); }; log { source(src); filter(f_mail); destination(mail); }; log { source(src); filter(DEFAULT); destination(all); }; The DEFAULT is a macro that will basically log everything that hasn't already been logged. If you just didn't want your mail logs just set the file to /dev/null or something. There are probably other ways to do this but this seems the most straight forward to me. Regards, DRew -----Original Message----- From: Stephen C Burns [mailto:sburns@farpointer.net] Sent: Tuesday, July 24, 2001 9:42 PM To: syslog-ng(a)lists.balabit.hu Subject: [syslog-ng]Eliminating certain keyword from the "all" directive? Hi all, I have a question regarding the redirection of certain log messages to files. I currently have the "all" directive sending every syslog message into /var/log/messages, via: destination all { file("/var/log/messages"); }; And that is great, except I don't want my mail messages getting sent into the messages file as well as this takes up a lot of space. So I basically need some way to say "send all messages except for mail messages into /var/log/messages" Is there such a way? Thank you for any help!! _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng

2 1

Eliminating certain keyword from the "all" directive?
by Stephen C Burns 24 Jul '01

24 Jul '01

Hi all, I have a question regarding the redirection of certain log messages to files. I currently have the "all" directive sending every syslog message into /var/log/messages, via: destination all { file("/var/log/messages"); }; And that is great, except I don't want my mail messages getting sent into the messages file as well as this takes up a lot of space. So I basically need some way to say "send all messages except for mail messages into /var/log/messages" Is there such a way? Thank you for any help!!

1 0

conflict with redhat init scripts
by Michael Stenner 24 Jul '01

24 Jul '01

I'm using syslog-ng 1.4.11 on a redhat 7.1 machine and have discovered a conflict involving the way syslog-ng forks and exits, and the way redhat starts its daemons. I don't think either end is really doing anything wrong here, but I think some things could be tidied up a bit. Basically, I think it comes from the fact that when syslog-ng forks, the parent waits for the child to send it a SIGTERM, and then dies with exit code 0. Unfortunately, I think that initlog (the redhat tool for starting daemons and logging the results) is thinking that the daemon was sent an uncaught SIGTERM and is dying. Let me give you some examples of what I mean. When you use bash to start syslog-ng and then print the "exit status", $?, bash reports 143. From the bash manpage: When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status. 143 - 128 = 15 = SIGTERM When you use initlog to start syslog-ng, initlog returns 15 directly. It also logs (via syslog-ng, humorously) that syslog-ng failed to start. Consequently, the init script reports failure. I'm still confused about a couple of things. 1) I've trolled through the syslog-ng source, and It's clear that the TERM signal _should_ be caught, so why are bash and initlog detecting this? 2) I've trolled through the initlog source, and I can't find where initlog tries to detect the type of signal a program received, or even that it cares. As far as I can tell, it just looks for the exit value of the program. As you can see, I'm already hip-deep in both programs, so I'm certainly willing to try and help "fix" this. I'm just wondering about these last two points, and which end it would be best to fix it on. (the fact that bash reports as it does leads me to lean toward changing this behavior in syslog-ng) Thanks, Michael P.S. If anyone is interesting in doing the same source-diving that I've been doing, you can get the same things I've been using from: http://mirror.dulug.duke.edu/ mirror/dulug/dulug-7.1/SRPMS/dulug/syslog-ng-1.4.11-3.src.rpm http://mirror.dulug.duke.edu/ mirror/redhat/redhat-7.1/en/os/i386/SRPMS/initscripts-5.83-1.src.rpm source rpms can be unpacked to an arbitrary tmpdir with the following commands: SRCDIR=$HOME/tmp mkdir -p $SRCDIR/usr/src/redhat rpm --root $SRCDIR --install syslog-ng-1.4.11-3.src.rpm cd $SRCDIR/usr/src/redhat/SOURCES/ The rest should be obvious. -- Michael Stenner Office Phone: 919-660-2513 Duke University, Dept. of Physics mstenner(a)phy.duke.edu Box 90305, Durham N.C. 27708-0305

4 7

Problem with libol-0.2.23 syslog-ng 1.4.12
by James Eborall 20 Jul '01

20 Jul '01

Thanks for the patch to afstreams.c Now it works but I cannot use the 'door' source (this is Solaris 2.7). If I add source s_door { door ("/etc/.syslog_door"); }; to my syslog-ng.conf then I get a parse error, but door support is compiled in so is there something else I should check?. Thanks james

1 0