From rgerhards at hq.adiscon.com Thu Jul 1 08:27:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 01 Jul 2010 08:27:57 +0200 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: <1277965677.18305.13.camel@localhost> On Wed, 2010-06-30 at 17:00 -0400, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: > > > > Note that being an evolution, any currently existing rsyslog.conf would also > > be a valid new conf (via the *same* parser). I have not thought out the full > > semantics and thousand other things that need to be thought of -- this > > actually opened up a can of worms ;) However, I find the proposed format > > seems to be a good compromise between the need to preserve and the need to > > move on, and between the need for simplicity and the need for power. > > > > As such, before I invest even more time into that format, I'd like to get > > some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). Don't mistake "general programming language" via "config language for a specialised engine". Full ACK for "general programming language". > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints Don't think in terms of "constraints", but in terms of "options" and "levels of (programming) freedom". "Constraints" sounds like a bad thing from legacy. In fact, what I need is the ability to do some very special, high performance things ;) > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. OK, Lua again. I've now written up why I don't consider Lua (or any other general-purpose language) a vital alternative for use in rsyslog: http://blog.gerhards.net/2010/07/why-i-think-lua-is-no-solution-for.html Please look carefully at the arguments, especially the facts that a) I do like things like Lua, but not in this context b) Lua misses support for SIMD processing c) Lua does not permit to execute based in the inherent partial order of config statements > If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. Well, that's a primary difference: speed is on of the *prime* concerns in rsyslog. I have looked at your implementation. Of course, I could have saved myself roughly 3 to 4 years of work if I used the same approach -- and rsyslog would most probably not be the alternative to syslog-ng it currently is. Also, I question if the typical sysadmin will actually like the format that you promote. All of the examples really scared me away. I have quoted the replacement for a standard red hat syslog.conf after my signature so that the other list members can do their own judgment. Rainer Now the replacement for a standard Red Hat syslog.conf with syslogintr (taken from above-mentioned URL, file "readhat.lua" inside the offered tarball): -- *************************************************************** -- -- Copyright 2010 by Sean Conner. All Rights Reserved. -- -- This program is free software: you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation, either version 3 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program. If not, see . -- -- Comments, questions and criticisms can be sent to: sean at conman.org -- -- ****************************************************************** -- -- A file the duplicates a default install of RedHat and their syslog.conf -- file. All functions not labeled as "local" are called directly via the -- runtime engine. -- -- cleanup() - called when the daemon exits -- reload_signal() - called when the program recieves a SIGHUP -- log() - called each time the daemon receives a message -- -- This is provided as a means to replace syslogd with a drop in -- replacement, but with the ability to expand upon the functionality as -- required. -- -- ******************************************************************* function cleanup() messages:close() secure:close() maillog:close() cron:close() spooler:close() boot:close() end -- ********************************************************************* local function openfiles() messages = io.open("/var/log/messages","a") or io.stdout secure = io.open("/var/log/secure" ,"a") or io.stdout maillog = io.open("/var/log/maillog" ,"a") or io.stdout cron = io.open("/var/log/cron" ,"a") or io.stdout spooler = io.open("/var/log/spooler" ,"a") or io.stdout boot = io.open("/var/log/boot" ,"a") or io.stdout end openfiles() -- ********************************************************************* function reload_signal() cleanup() openfiles() end -- ********************************************************************* local function logfile(msg,file,flushp) local flushp = flushp or false if msg.remote == false then msg.host = "localhost" end file:write(string.format( "%s %s %s[%d]: %s\n", os.date("%b %d %H:%M:%S",msg.timestamp), msg.host, msg.program, msg.pid, msg.msg )) if flushp then file:flush() end end -- ****************************************************************** local function everybody(msg) local out = io.popen("/usr/bin/wall","w") logfile(msg,out) out:close() end -- ****************************************************************** function log(msg) if msg.level == 'info' or msg.level == 'notice' or msg.level == 'warn' or msg.level == 'err' or msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then if msg.facility ~= 'mail' and msg.facility ~= 'auth2' and msg.facility ~= 'cron' and msg.facility ~= 'local6' then logfile(msg,messages) end end if msg.facility == 'auth2' then logfile(msg,secure) end if msg.facility == 'mail' then logfile(msg,maillog,true) end if msg.facility == 'cron' then logfile(msg,cron) end if msg.level == 'emerg' then everybody(msg) end if msg.facility == 'uucp' or msg.facility == 'news' then if msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then logfile(msg,spooler) end end if msg.facility == 'local7' then logfile(msg,boot) end end -- ******************************************************************** From raja.rhel5 at gmail.com Thu Jul 1 10:10:31 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 13:40:31 +0530 Subject: [rsyslog] rsyslog Message-ID: hi, I have configured rsylog and mysql server..everything working fine. But i found after examining it for 1 week, all the logs are consuming lot of space.so i decided not to delete all the logs in database? how can i do it? how to redirect only important logs...kern,errors,warnings...? Thanks in advance. raja antony From tomasz.glowacki at pseinfo.pl Thu Jul 1 10:37:44 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 10:37:44 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 Message-ID: <8610433990.20100701103744@pseinfo.pl> Hi everyone, Web forum seems dead for a while, so I decided to post to mailing list. I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to a files based on facility and some simple forwarding using omudpspoof. That is all I have plus generic system logging. Default as much as it can be ;) rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while 5.5.0 seems to work quite normal but with CPU load for the process reaching 99%. This is simple Pentium III 833 machine. I did some sort of debuging. I disabled /dev/xconsole section, immark module as sugested. No change at all. Then, ran rsyslogd with -d and there were no errors at all, normal initialization and no further messages at all. After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of the files started to grow about 1-2 megabytes every few seconds with something like that: clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 this is tail from that rapidly growing file. How can I solve this? What kind of information should I provide to solve the problem? :) I'm open and ready for further debugging. Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with the same config besides that it doesn't support omudpspoof module, so forwarding of messages is quite useless.. -- Best regards, Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl From david at lang.hm Thu Jul 1 11:06:03 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:06:03 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: I ran into this same problem and finally discovered that it was because there were two sets of rsyslog modules, the old ubuntu defaults and the ones I compiled. the wrong ones were being found and problems resulted. you may find that you have files in /usr/lib/rsyslog and in /usr/local/lib/rsyslog delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. rsyslog needs to eventually gain the ability to version the modules and report when the wrong version module is loaded. But at the moment this is not available. David Lang On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Date: Thu, 1 Jul 2010 10:37:44 +0200 > From: utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi everyone, > > Web forum seems dead for a while, so I decided to post to mailing > list. > > I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under > Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to > a files based on facility and some simple forwarding using omudpspoof. > That is all I have plus generic system logging. Default as much as it > can be ;) > > rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while > 5.5.0 seems to work quite normal but with CPU load for the process > reaching 99%. This is simple Pentium III 833 machine. > > I did some sort of debuging. I disabled /dev/xconsole section, immark > module as sugested. No change at all. > > Then, ran rsyslogd with -d and there were no errors at all, normal > initialization and no further messages at all. > > After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of > the files started to grow about 1-2 megabytes every few seconds with > something like that: > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 > > this is tail from that rapidly growing file. > > How can I solve this? What kind of information should I provide to > solve the problem? :) I'm open and ready for further debugging. > > Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with > the same config besides that it doesn't support omudpspoof module, so > forwarding of messages is quite useless.. > > > > -- > Best regards, > Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 1 11:08:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:08:15 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: On Wed, 30 Jun 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). one key thing is that this language is not a script to be executed as logs come in, it's a config file that will get read in to configure rsyslog internals (compiiled into the rsyslog internal function calls effectivly) no off-the-shelf language is fast enough for the data rates that rsyslog is able to reach today. David Lang > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints and I've certainly seen (and worked) with worse configuration > files (sendmail.cf comes to mind). > > One last thing though, in looking over your proposed syntax for > RainerScript I see that's it already is awfully close to Lua: > > ruleset remote10515 { > if pri("mail.*") then { > action(type="omfile" file="/var/log/remote10514") > action(use="dynfile") > action(type="udpfwd" action.execonlyonce="5sec" > target="192.168.1.2" port="514") > } > action(type="udpfwd" target="192.168.1.3" > action.previousfailed="on") > action(type="omfile" file="/var/log/catchall") > if $severity == 'error' and $msg contains 'Link 2' then > action(type="ommail" server="192.168.1.3" > from="someone at example.net" > to="ops at example.net" > subject="###error \"detected\"###") > } > > could be translated into Lua as: > > function remote10515() > if pri("mail.*") then > action { type="omfile" , file="/var/log/remote10514" } > action { use="dynfile" } > action { > type = "udpfwd" , > action = { execonlyonce="5sec" }, > target = "192.168.1.2", > port = 514 > } > end > > action { > type="udpfwd" , > target="192.168.1.3" , > action = { previousfailed = true } > } > action { type="omfile" , file="/var/log/catchall" } > if severity == 'error' and string.find(msg,'Link 2') then > action { > type="ommail", > server="192.168.1.3", > from="someone at example.net", > to="ops at example.net", > subject=[[###error "detected"###]] > } > end > end > > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. > > -spc (which includes the processing of multiple thin logs into one fat > log) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From tomasz.glowacki at pseinfo.pl Thu Jul 1 11:57:33 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 11:57:33 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <6410167759.20100701115733@pseinfo.pl> Witam, Thursday, July 1, 2010, 11:06:03 AM, you wrote: > I ran into this same problem and finally discovered that it was because > there were two sets of rsyslog modules, the old ubuntu defaults and the > ones I compiled. the wrong ones were being found and problems resulted. > you may find that you have files in /usr/lib/rsyslog and in > /usr/local/lib/rsyslog > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. > rsyslog needs to eventually gain the ability to version the modules and > report when the wrong version module is loaded. But at the moment this is > not available. I don't think it is a good solution. If I compile 5.5.0 with --prefix=/my/directory and then make install is done to that directory rsyslogd should read libs from there (and in fact - is doing that because omudpspoof module is working). Not from /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. Why rsyslogd is searching for other libs elsewhere than in it's install directory? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Dzia? Sieci tel. (022) 3401597, (601) 672872 From rgerhards at hq.adiscon.com Thu Jul 1 13:55:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 13:55:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 11:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 11:06:03 AM, you wrote: > > > I ran into this same problem and finally discovered that it was > because > > there were two sets of rsyslog modules, the old ubuntu defaults and > the > > ones I compiled. the wrong ones were being found and problems > resulted. > > > you may find that you have files in /usr/lib/rsyslog and in > > /usr/local/lib/rsyslog > > > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > package. > > > rsyslog needs to eventually gain the ability to version the modules > and > > report when the wrong version module is loaded. But at the moment > this is > > not available. > > I don't think it is a good solution. > > If I compile 5.5.0 with --prefix=/my/directory and then make install > is done to that directory rsyslogd should read libs from there (and in > fact - is doing that because omudpspoof module is working). Not from > /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > > Why rsyslogd is searching for other libs elsewhere than in it's > install directory? It depends on how you configure the running system (not the build system). There is a command line switch as well as a config directive that tells form where to load modules. Distros usually set their defaults with these directives. To the root question: this may be caused by a bug. I suggest that you check out the current master branch, it may work (which would be an indication of a bug). I did some changes to the code, and I had the impression that what you report could actually something that happens with the older codebase (5.5.5 in this view being "older" ;)). HTH Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 14:51:43 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 14:51:43 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> Message-ID: <235067282.20100701145143@pseinfo.pl> Witam, Thursday, July 1, 2010, 1:55:58 PM, you wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) >> Sent: Thursday, July 01, 2010 11:58 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 >> >> Witam, >> >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: >> >> > I ran into this same problem and finally discovered that it was >> because >> > there were two sets of rsyslog modules, the old ubuntu defaults and >> the >> > ones I compiled. the wrong ones were being found and problems >> resulted. >> >> > you may find that you have files in /usr/lib/rsyslog and in >> > /usr/local/lib/rsyslog >> >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu >> package. >> >> > rsyslog needs to eventually gain the ability to version the modules >> and >> > report when the wrong version module is loaded. But at the moment >> this is >> > not available. >> >> I don't think it is a good solution. >> >> If I compile 5.5.0 with --prefix=/my/directory and then make install >> is done to that directory rsyslogd should read libs from there (and in >> fact - is doing that because omudpspoof module is working). Not from >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. >> >> Why rsyslogd is searching for other libs elsewhere than in it's >> install directory? > It depends on how you configure the running system (not the build system). > There is a command line switch as well as a config directive that tells form > where to load modules. Distros usually set their defaults with these > directives. Ok, which command line switch do you mean? And which config directive? :) I'll try to clarify: where from rsyslogd is getting it's libs by default? (as manual page says: " prefix/lib/rsyslog Default directory for rsyslogd modules. The prefix is specified during compilation (e.g. /usr/local)." I would like to know if rsyslogd is REALLY getting it's libs from prefix path. Just not to mess my system completly. > To the root question: this may be caused by a bug. I suggest that you check > out the current master branch, it may work (which would be an indication of a > bug). I did some changes to the code, and I had the impression that what you > report could actually something that happens with the older codebase (5.5.5 > in this view being "older" ;)). I'll try that but rather as my "last resort".... I would love to see 5.4.0 or 5.5.5 working properly here.... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 14:55:08 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 14:55:08 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 2:52 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 1:55:58 PM, you wrote: > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > >> Sent: Thursday, July 01, 2010 11:58 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > >> > >> Witam, > >> > >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: > >> > >> > I ran into this same problem and finally discovered that it was > >> because > >> > there were two sets of rsyslog modules, the old ubuntu defaults > and > >> the > >> > ones I compiled. the wrong ones were being found and problems > >> resulted. > >> > >> > you may find that you have files in /usr/lib/rsyslog and in > >> > /usr/local/lib/rsyslog > >> > >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > >> package. > >> > >> > rsyslog needs to eventually gain the ability to version the > modules > >> and > >> > report when the wrong version module is loaded. But at the moment > >> this is > >> > not available. > >> > >> I don't think it is a good solution. > >> > >> If I compile 5.5.0 with --prefix=/my/directory and then make install > >> is done to that directory rsyslogd should read libs from there (and > in > >> fact - is doing that because omudpspoof module is working). Not from > >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > >> > >> Why rsyslogd is searching for other libs elsewhere than in it's > >> install directory? > > > It depends on how you configure the running system (not the build > system). > > There is a command line switch as well as a config directive that > tells form > > where to load modules. Distros usually set their defaults with these > > directives. > > Ok, which command line switch do you mean? And which config directive? > :) I'll check the doc as soon as I have time to do so... Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:16:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:16:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> Message-ID: <1989837614.20100701151634@pseinfo.pl> Hi, Thursday, July 1, 2010, 2:55:08 PM, you wrote: > I'll check the doc as soon as I have time to do so... If you meant $ModDir that doesn't change much... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:18:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:18:35 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:17 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi, > > Thursday, July 1, 2010, 2:55:08 PM, you wrote: > > > > I'll check the doc as soon as I have time to do so... > > If you meant $ModDir that doesn't change much... Ah, yes, that's the name of it. The startup option is probably something like -m or -M. The simplest thing probably is to check your startup script (wherever that is located on your distro). Rainer From marc.schiffbauer at mightycare.de Thu Jul 1 15:04:04 2010 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 1 Jul 2010 15:04:04 +0200 Subject: [rsyslog] rsyslog In-Reply-To: References: Message-ID: <201007011504.04602.marc.schiffbauer@mightycare.de> Hi raja, read the docs on the homepage. you can select what to put into the database in the same way as you select what goes into which logfile. for deletin old log you will have to issue a SQL command uisng a mysql client (DELETE FROM WHERE <= ) -marc On Thursday 01 July 2010 10:10:31 Raja antony wrote: > hi, > > I have configured rsylog and mysql server..everything working fine. > > But i found after examining it for 1 week, all the logs are consuming lot > of space.so i decided not to delete all the logs in database? > > how can i do it? > > how to redirect only important logs...kern,errors,warnings...? > > Thanks in advance. > raja antony > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux :: Virtualization Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/impressum From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:24:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:24:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> Message-ID: <1987371782.20100701152434@pseinfo.pl> Witam, Thursday, July 1, 2010, 3:18:35 PM, you wrote: > Ah, yes, that's the name of it. The startup option is probably something like > -m or -M. The simplest thing probably is to check your startup script > (wherever that is located on your distro). Yep, -M. Tried that too. So, I could be sure that this is not version conflict. Forcing loading from exact path does the same as default - CPU hog on 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:26:21 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:26:21 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:25 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 3:18:35 PM, you wrote: > > > Ah, yes, that's the name of it. The startup option is probably > something like > > -m or -M. The simplest thing probably is to check your startup script > > (wherever that is located on your distro). > > Yep, -M. Tried that too. So, I could be sure that this is not version > conflict. Forcing loading from exact path does the same as default - > CPU hog on 99% That's what I suspected... So we need to see if it is already fixed or not (master branch). If not, we need to look at the debug log and try to find out what is going on. Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 16:33:58 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 16:33:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> Message-ID: <518726404.20100701163358@pseinfo.pl> Hi, Thursday, July 1, 2010, 3:26:21 PM, you wrote: > That's what I suspected... > So we need to see if it is already fixed or not (master branch). If not, we > need to look at the debug log and try to find out what is going on. Ok, that's my next try. But, I think I'm getting close to the goal. When I comment: $PrivDropToUser syslog $PrivDropToGroup adm and run the rsyslogd via sudo - it's running perfect with no CPU hog. It runs as root then. Uncommenting that gives CPU hog but running as user syslog. I've checked file priviledges and they're ok, same as directories, wherever rsyslogd needs to read/write. As I said, 4.2.0 running on the same config, same priviledge level works well. -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From james at linux-source.org Thu Jul 1 17:00:23 2010 From: james at linux-source.org (James Corteciano) Date: Thu, 1 Jul 2010 23:00:23 +0800 Subject: [rsyslog] PHP error logs In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F3E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> Message-ID: Hi Rainer, The following are my settings in remote php server. [/etc/rsyslog.conf] $ModLoad imfile $InputFileName /var/log/php/example.com/error_log $InputFileTag example.com.php.error: $InputFileStateFile stat-example.com $InputFileSeverity error $InputFileFacility local6 $InputRunFileMonitor $InputFilePollingInterval 1 local6.* @192.168.10.125 The problem is it takes 10 seconds to received the php error logs on central syslog server. How can I speed up the receiving of logs on syslog server? Do I need to add/modify on any settings? Thanks. Regards, James On Wed, Jun 30, 2010 at 8:22 PM, Rainer Gerhards wrote: > Hi James, > > well, after imfile reads the messages, they *are* already present in > rsyslog > and so they are in the syslog server. It is not a push model but rather a > pull model (the syslog server pulls the messages from the file instead of > them being pushed to it). > > If you mean how to forward them to a remote server: that's business as > usual, > so you can just do > > *.* @remote-server > > ..or use any other forwarding action. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > Sent: Wednesday, June 30, 2010 1:43 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] PHP error logs > > > > Hi Rainer, > > > > How to push the logs to syslog server? > > > > On Wed, Jun 30, 2010 at 4:49 PM, Rainer Gerhards > > wrote: > > > > > Hi James, > > > > > > if I understood you correctly, imfile may be your friend: > > > > > > http://www.rsyslog.com/doc-imfile.html > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > > > Sent: Wednesday, June 30, 2010 5:32 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] PHP error logs > > > > > > > > Hi All, > > > > > > > > I know this is out of topic here in mailing list but I couldn't get > > > > into php > > > > mailing list. > > > > > > > > Anyone have try to log php errors and forwarded it to centralized > > > > rsyslog > > > > server? I can received logs locally from /var/log/messages > > (specified > > > > from > > > > /etc/php.ini) but I want to forward it to centralized log. > > > > > > > > Thanks. > > > > > > > > Regards, > > > > James > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 1 19:02:36 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 10:02:36 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <518726404.20100701163358@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> <518726404.20100701163358@pseinfo.pl> Message-ID: On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Hi, > > Thursday, July 1, 2010, 3:26:21 PM, you wrote: > > >> That's what I suspected... > >> So we need to see if it is already fixed or not (master branch). If not, we >> need to look at the debug log and try to find out what is going on. > > Ok, that's my next try. But, I think I'm getting close to the > goal. > > When I comment: > $PrivDropToUser syslog > $PrivDropToGroup adm > > and run the rsyslogd via sudo - it's running perfect with no CPU hog. > It runs as root then. > > Uncommenting that gives CPU hog but running as user syslog. I've > checked file priviledges and they're ok, same as directories, wherever > rsyslogd needs to read/write. > > As I said, 4.2.0 running on the same config, same priviledge level works well. when I had this problem, logging *.* somewhere showed me 200,000 logs/sec being generated by an error message saying that rsyslog was not allowed to read something. do you have anything similar in your logs? David Lang From epiphani at gmail.com Thu Jul 1 19:14:12 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Thu, 1 Jul 2010 13:14:12 -0400 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: 2010/7/1 G?owacki, Tomasz (INFO) : > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 This looks like a bug. Can you provide a list of your environment variables on startup? This looks like debug logs are trying to be sent to stdout - which is failing because stdout is closed (as it should be for a daemonized application). Something somewhere has flipped debugging information on, and yet still forked the process off of the terminal. Configuring the app this way should be impossible - if its something in configuration... if not, its just a bug where debug is being properly activated after a fork. -Aaron From rgerhards at hq.adiscon.com Thu Jul 1 20:11:39 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 20:11:39 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> > This looks like debug logs are trying to be sent to stdout - which is > failing because stdout is closed (as it should be for a daemonized > application). Something somewhere has flipped debugging information > on, and yet still forked the process off of the terminal. Configuring > the app this way should be impossible - if its something in > configuration... if not, its just a bug where debug is being properly > activated after a fork. Good catch! I was so preoccupied with the known issue of action error not being properly acted on by the transaction processor, I did not notice the actual data. A full debug log should help to find out what is going on. Thanks! Rainer From raja.rhel5 at gmail.com Fri Jul 2 07:59:49 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 22:59:49 -0700 Subject: [rsyslog] Raja antony wants to chat Message-ID: ----------------------------------------------------------------------- Raja antony wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI You'll need to click this link to be able to chat with Raja antony. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with Raja antony, visit: http://mail.google.com/mail/a-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From tomasz.glowacki at pseinfo.pl Fri Jul 2 09:57:04 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 09:57:04 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <661878047.20100702095704@pseinfo.pl> Witam, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Is your list allowing attachments? Or pasting huge amount of debug here? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 14:00:55 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 14:00:55 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <1571565725.20100702140055@pseinfo.pl> Hi, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Here it is, debug: http://pastebin.com/RXQim1yh it ends just after dropping priviledges. No more messages appear. CPU is at 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 16:42:12 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 16:42:12 +0200 Subject: [rsyslog] [solved] - high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <1571565725.20100702140055@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> <1571565725.20100702140055@pseinfo.pl> Message-ID: <585116747.20100702164212@pseinfo.pl> Witam, Friday, July 2, 2010, 2:00:55 PM, you wrote: > Here it is, debug: > http://pastebin.com/RXQim1yh > it ends just after dropping priviledges. No more messages appear. CPU > is at 99% Ok, problem is gone now. If the config directive KLogPath was set to: $KLogPath /var/run/rsyslog/kmsg CPU has been hogged. Changing it to /proc/kmsg solved the problem completly. There were no file at /var/run/rsyslog/kmsg created during daemon start. Why? I dunno. The problem is described shortly at: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/401433 -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From P at draigBrady.com Tue Jul 6 14:52:44 2010 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Tue, 06 Jul 2010 13:52:44 +0100 Subject: [rsyslog] TCP connections not being closed Message-ID: <4C33271C.70805@draigBrady.com> I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 server on debian. Eventually the server exhausts it's connections as there are multiple connections from each client. Taking 1 client in particular: server# lsof -n -i at 10.132.8.1 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME rsyslogd 29775 root 325u IPv4 81017793 TCP 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) rsyslogd 29775 root 515u IPv4 81085917 TCP 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) rsyslogd 29775 root 531u IPv4 81187589 TCP 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) rsyslogd 29775 root 568u IPv4 81263960 TCP 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) rsyslogd 29775 root 570u IPv4 81275186 TCP 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) rsyslogd 29775 root 573u IPv4 81300023 TCP 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) rsyslogd 29775 root 574u IPv4 81412888 TCP 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) rsyslogd 29775 root 588u IPv4 81503100 TCP 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) rsyslogd 29775 root 591u IPv4 81559427 TCP 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) rsyslogd 29775 root 593u IPv4 81593574 TCP 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) rsyslogd 29775 root 595u IPv4 81624236 TCP 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) rsyslogd 29775 root 599u IPv4 81631713 TCP 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) rsyslogd 29775 root 601u IPv4 81641244 TCP 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) rsyslogd 29775 root 603u IPv4 82260661 TCP 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) rsyslogd 29775 root 684u IPv4 84358985 TCP 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) rsyslogd 29775 root 699u IPv4 84499197 TCP 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) rsyslogd 29775 root 701u IPv4 84557429 TCP 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) rsyslogd 29775 root 714u IPv4 86973034 TCP 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) rsyslogd 29775 root 823u IPv4 88591917 TCP 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) rsyslogd 29775 root 999u IPv4 90314222 TCP 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) rsyslogd 29775 root 1003u IPv4 125443032 TCP 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) server# ssh 10.132.8.1 lsof -n -i :514 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsyslogd 1595 root 8u IPv4 59789 0t0 TCP 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) So you can see that the client has only 1 connection open, while the server has many. Could the server be changed to close connections old connections to a particular IP? I guess that would have issues for NATing, or perhaps the server could just timeout the TCP connections after a period of inactivity? Any ideas appreciated. cheers, P?draig. For my own reference, these seem closely related: http://kb.monitorware.com/post5056.html http://bugzilla.adiscon.com/show_bug.cgi?id=190 From ktm at rice.edu Tue Jul 6 15:04:51 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:04:51 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C33271C.70805@draigBrady.com> References: <4C33271C.70805@draigBrady.com> Message-ID: <20100706130451.GI341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 01:52:44PM +0100, P??draig Brady wrote: > I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 > server on debian. Eventually the server exhausts it's connections as > there are multiple connections from each client. > > Taking 1 client in particular: > > server# lsof -n -i at 10.132.8.1 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > rsyslogd 29775 root 325u IPv4 81017793 TCP > 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) > rsyslogd 29775 root 515u IPv4 81085917 TCP > 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) > rsyslogd 29775 root 531u IPv4 81187589 TCP > 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) > rsyslogd 29775 root 568u IPv4 81263960 TCP > 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) > rsyslogd 29775 root 570u IPv4 81275186 TCP > 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) > rsyslogd 29775 root 573u IPv4 81300023 TCP > 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) > rsyslogd 29775 root 574u IPv4 81412888 TCP > 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) > rsyslogd 29775 root 588u IPv4 81503100 TCP > 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) > rsyslogd 29775 root 591u IPv4 81559427 TCP > 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) > rsyslogd 29775 root 593u IPv4 81593574 TCP > 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) > rsyslogd 29775 root 595u IPv4 81624236 TCP > 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) > rsyslogd 29775 root 599u IPv4 81631713 TCP > 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) > rsyslogd 29775 root 601u IPv4 81641244 TCP > 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) > rsyslogd 29775 root 603u IPv4 82260661 TCP > 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) > rsyslogd 29775 root 684u IPv4 84358985 TCP > 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) > rsyslogd 29775 root 699u IPv4 84499197 TCP > 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) > rsyslogd 29775 root 701u IPv4 84557429 TCP > 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) > rsyslogd 29775 root 714u IPv4 86973034 TCP > 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) > rsyslogd 29775 root 823u IPv4 88591917 TCP > 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) > rsyslogd 29775 root 999u IPv4 90314222 TCP > 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) > rsyslogd 29775 root 1003u IPv4 125443032 TCP > 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) > > server# ssh 10.132.8.1 lsof -n -i :514 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > rsyslogd 1595 root 8u IPv4 59789 0t0 TCP > 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) > > So you can see that the client has only 1 connection open, while the > server has many. Could the server be changed to close connections old > connections to a particular IP? I guess that would have issues for > NATing, or perhaps the server could just timeout the TCP connections > after a period of inactivity? > > Any ideas appreciated. > > cheers, > P??draig. > > For my own reference, these seem closely related: > http://kb.monitorware.com/post5056.html > http://bugzilla.adiscon.com/show_bug.cgi?id=190 Attempts to ameliorate these types of problems by kludging the server always end badly. I do not know anything about the RELP protocol, but it sounds like the client has a bug as well as possibly the server. Does it happen without RELP? If not, can you run without RELP? If not, you may need to get out the debugger. :) Cheers, Ken From P at draigBrady.com Tue Jul 6 15:16:24 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 14:16:24 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706130451.GI341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> Message-ID: <4C332CA8.8030301@draigBrady.com> On 06/07/10 14:04, Kenneth Marshall wrote: > Attempts to ameliorate these types of problems by kludging the > server always end badly. I do not know anything about the RELP > protocol, but it sounds like the client has a bug as well as > possibly the server. True. I've not looked into why the client is not tearing down connections, but in practice the clients can always just disappear. > Does it happen without RELP? If not, can > you run without RELP? If not, you may need to get out the > debugger. :) Unless it's enabled by default I've no mention of "relp" in my client configs. I'm using plain TCP I think. cheers, P?draig. From ktm at rice.edu Tue Jul 6 15:53:58 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:53:58 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C332CA8.8030301@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> Message-ID: <20100706135358.GK341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 02:16:24PM +0100, P?draig Brady wrote: > On 06/07/10 14:04, Kenneth Marshall wrote: > > Attempts to ameliorate these types of problems by kludging the > > server always end badly. I do not know anything about the RELP > > protocol, but it sounds like the client has a bug as well as > > possibly the server. > > True. I've not looked into why the client is not tearing down connections, > but in practice the clients can always just disappear. > > > Does it happen without RELP? If not, can > > you run without RELP? If not, you may need to get out the > > debugger. :) > > Unless it's enabled by default I've no mention of "relp" > in my client configs. I'm using plain TCP I think. > > cheers, > P?draig. > Are you certain you are not having a problem with some intervening firewall/IPtables network filtering. Poorly configured, they can cause the TCP network stack shutdown to fail because they block packets that should be passed for a correct shutdown. Regards, Ken From P at draigBrady.com Tue Jul 6 16:12:18 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 15:12:18 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706135358.GK341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> Message-ID: <4C3339C2.6000800@draigBrady.com> On 06/07/10 14:53, Kenneth Marshall wrote: > Are you certain you are not having a problem with some > intervening firewall/IPtables network filtering. Poorly > configured, they can cause the TCP network stack shutdown > to fail because they block packets that should be passed > for a correct shutdown. Clients and server are on the same LAN. I've just done this on the 400+ clients: /etc/init.d/rsyslog restart There were about 20 stale connections left on the server. cheers, P?draig. From ktm at rice.edu Tue Jul 6 16:54:45 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 09:54:45 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C3339C2.6000800@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> <4C3339C2.6000800@draigBrady.com> Message-ID: <20100706145445.GL341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 03:12:18PM +0100, P?draig Brady wrote: > On 06/07/10 14:53, Kenneth Marshall wrote: > > Are you certain you are not having a problem with some > > intervening firewall/IPtables network filtering. Poorly > > configured, they can cause the TCP network stack shutdown > > to fail because they block packets that should be passed > > for a correct shutdown. > > Clients and server are on the same LAN. > I've just done this on the 400+ clients: > /etc/init.d/rsyslog restart > There were about 20 stale connections left on the server. > > cheers, > P?draig. > Are the clients/server running any type of firewall software or IPtables? Being on the same LAN will not prevent problems if they are running such software and it is misconfigured. Ken From tbergfeld at hq.adiscon.com Wed Jul 7 13:41:32 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 7 Jul 2010 13:41:32 +0200 Subject: [rsyslog] rsyslog 4.6.3 (v4-stable) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F73@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.6.3, a member of the v4-stable branch. This is a bug-fixing release which contains an improved testbench and a new configure option that permits to disable and enable an extended testbench. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article463.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-205.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From joe at joetify.com Wed Jul 7 18:29:31 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 09:29:31 -0700 Subject: [rsyslog] logging hostnames Message-ID: I have a couple services (haproxy and homegrown erlang stuff) that log directly to my rsyslog server. With these services I found that they log the reverse DNS rather than the hostname but with the logs that come from actual rsyslog clients they show up as one would expect with the real hostname, like what is returned from the "hostname" command. I've tried a few different things with "-x" and fromhost vs hostname and can't seem to get anything other than either an IP or a rDNS. Any suggestions? Do I need to include more information in the messages I send to rsyslog or perhaps adjust a config? Thanks. -Joe Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From david at lang.hm Wed Jul 7 19:27:37 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 10:27:37 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > I have a couple services (haproxy and homegrown erlang stuff) that log > directly to my rsyslog server. With these services I found that they log > the reverse DNS rather than the hostname but with the logs that come > from actual rsyslog clients they show up as one would expect with the > real hostname, like what is returned from the "hostname" command. I've > tried a few different things with "-x" and fromhost vs hostname and > can't seem to get anything other than either an IP or a rDNS. Any > suggestions? Do I need to include more information in the messages I > send to rsyslog or perhaps adjust a config? probably what is happening is that your server is not sending a properly formatted syslog message to rsyslog, so it is figuring out the info itself. try setting up a format with %raw% in it (the raw message that rsyslog receives) and look at it. it _should_ be in the format HH:MM:SS hostname syslogtag message I suspect that you are not getting the data in that format so rsyslog isn't recognising the hostname from the syslog message, so is having to fall back on IP address or reverse DNS. David Lang From joe at joetify.com Wed Jul 7 19:42:37 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 10:42:37 -0700 Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> David, Thanks, I think you're right: <14>Jul 2 21:25:38 HOSTNAME log message vs <149>customer:[<0.20341.5496>] IPADDR log message The latter is the message that our server is sending. -Joe On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > On Wed, 7 Jul 2010, Joe Williams wrote: > >> I have a couple services (haproxy and homegrown erlang stuff) that log >> directly to my rsyslog server. With these services I found that they log >> the reverse DNS rather than the hostname but with the logs that come >> from actual rsyslog clients they show up as one would expect with the >> real hostname, like what is returned from the "hostname" command. I've >> tried a few different things with "-x" and fromhost vs hostname and >> can't seem to get anything other than either an IP or a rDNS. Any >> suggestions? Do I need to include more information in the messages I >> send to rsyslog or perhaps adjust a config? > > probably what is happening is that your server is not sending a properly > formatted syslog message to rsyslog, so it is figuring out the info > itself. > > try setting up a format with %raw% in it (the raw message that rsyslog > receives) and look at it. > > it _should_ be in the format > > HH:MM:SS hostname syslogtag message > > I suspect that you are not getting the data in that format so rsyslog > isn't recognising the hostname from the syslog message, so is having to > fall back on IP address or reverse DNS. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From pkrash at exegy.com Wed Jul 7 22:14:18 2010 From: pkrash at exegy.com (Paul Krash) Date: Wed, 7 Jul 2010 20:14:18 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error Message-ID: Hello! I have recently tried to parse syslog messages by %hostname% using the $RuleSet module. I have seen this work in Centos with no probs. Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf (from the all in one conf file found on Centos). I am getting the error that a module is missing? Is this an Ubuntu special, where a module is not compiled in the distro? I tried to compile from src, and got the same error. How can I get and enable the Module for rulesets? Thanks in advance, PKrash DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" error in /var/log/messages: Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 94 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 109 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 110 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 112 Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] From david at lang.hm Thu Jul 8 03:21:52 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:21:52 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > David, > > Thanks, I think you're right: > > <14>Jul 2 21:25:38 HOSTNAME log message > > vs > > <149>customer:[<0.20341.5496>] IPADDR log message > > The latter is the message that our server is sending. yep, there's no timestamp or hostname in the message. This is a failry common way to malform syslog messages, and the standard thing to do is to use the current time as the timestamp and use the IP address (or reverse DNS lookup) as the hostname if you can get the srver to change it's log format you should start seeing the hostname correctly, short of this you have to settle for what you can get from the IP address. David Lang > -Joe > > > On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > >> On Wed, 7 Jul 2010, Joe Williams wrote: >> >>> I have a couple services (haproxy and homegrown erlang stuff) that log >>> directly to my rsyslog server. With these services I found that they log >>> the reverse DNS rather than the hostname but with the logs that come >>> from actual rsyslog clients they show up as one would expect with the >>> real hostname, like what is returned from the "hostname" command. I've >>> tried a few different things with "-x" and fromhost vs hostname and >>> can't seem to get anything other than either an IP or a rDNS. Any >>> suggestions? Do I need to include more information in the messages I >>> send to rsyslog or perhaps adjust a config? >> >> probably what is happening is that your server is not sending a properly >> formatted syslog message to rsyslog, so it is figuring out the info >> itself. >> >> try setting up a format with %raw% in it (the raw message that rsyslog >> receives) and look at it. >> >> it _should_ be in the format >> >> HH:MM:SS hostname syslogtag message >> >> I suspect that you are not getting the data in that format so rsyslog >> isn't recognising the hostname from the syslog message, so is having to >> fall back on IP address or reverse DNS. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > Name: Joseph A. Williams > Email: joe at joetify.com > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 8 03:24:17 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:24:17 -0700 (PDT) Subject: [rsyslog] $RuleSet parameter yields 3003 error In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Paul Krash wrote: > Hello! > > I have recently tried to parse syslog messages by %hostname% using the $RuleSet > module. I have seen this work in Centos with no probs. > > Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf > (from the all in one conf file found on Centos). > > I am getting the error that a module is missing? > > Is this an Ubuntu special, where a module is not compiled in the distro? I think it's most likely a problem where ubuntu just ships too old a version. It shipps 4.2.0 and I think rulesets were introduced later than that. > I tried to compile from src, and got the same error. did you uninstall the ubuntu default first? if not then you may be conflicting with it's modules (in /usr/lib/rsyslog where your modules probably went into usr/local/lib/rsyslog) David Lang > How can I get and enable the Module for rulesets? > > Thanks in advance, > > PKrash > > > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=10.04 > DISTRIB_CODENAME=lucid > DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" > > error in /var/log/messages: > > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 94 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 109 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 110 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 112 > Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master > config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 8 09:37:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 8 Jul 2010 09:37:22 +0200 Subject: [rsyslog] logging hostnames References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F79@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 08, 2010 3:22 AM > To: rsyslog-users > Subject: Re: [rsyslog] logging hostnames > > On Wed, 7 Jul 2010, Joe Williams wrote: > > > David, > > > > Thanks, I think you're right: > > > > <14>Jul 2 21:25:38 HOSTNAME log message > > > > vs > > > > <149>customer:[<0.20341.5496>] IPADDR log message > > > > The latter is the message that our server is sending. > > yep, there's no timestamp or hostname in the message. This is a failry > common way to malform syslog messages, and the standard thing to do is > to > use the current time as the timestamp and use the IP address (or > reverse > DNS lookup) as the hostname > > if you can get the srver to change it's log format you should start > seeing > the hostname correctly, short of this you have to settle for what you > can > get from the IP address. David is absolutely right, but I would like to mention that a way to address such things (if you can use the IPADDR from the log message) is to write a custom message parser. Rsyslog has recently enhanced to provide this facility for solving such common malformed message issues. If you can not write one yourself, Adiscon offers to write message parsers for little money (provided the parser is contributed back to the project). As a side-note, my hope is that over time we will get a set of parsers that address most of the malformed messages we see... Rainer From pkrash at exegy.com Thu Jul 8 15:10:28 2010 From: pkrash at exegy.com (Paul Krash) Date: Thu, 8 Jul 2010 13:10:28 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error References: Message-ID: lang.hm> writes: > I think it's most likely a problem where ubuntu just ships too old a > version. It shipps 4.2.0 and I think rulesets were introduced later than > that. AHA! Thanks for the important tip! Confirmed, 4.2.0 is shipped with Ubuntu Lucid (10.04). 5.4 is shipped with Centos 5.4 The one instance that Centos is more modern than another distro... :-) > did you uninstall the ubuntu default first? if not then you may be > conflicting with it's modules (in /usr/lib/rsyslog where your modules > probably went into usr/local/lib/rsyslog) Yes, I did. I was depending on dpkg to purge all the files installed, possibly incorrect backout script from the Ubuntu package maintainer. I'll try from source again. Is there a specific ./configure option to include the ruleset module? Thanks in advance! PKrash From david at lang.hm Fri Jul 9 23:42:58 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 9 Jul 2010 14:42:58 -0700 (PDT) Subject: [rsyslog] spoofing module configuration Message-ID: in reading the spoofing module configuration it strikes me that the defaults can be significantly improved. the common case for needing to so spoofing is that you are spoofing the original source IP address so the current configuration equivalent commands $template spoofaddr, "%fromhost-ip%" $ActionUDPSpoofSourceNameTemplate spoofaddr could be made the default (or call it RSYSLOG_spoofaddr to keep from polluting the namespace) and the result would be far simpler for people to configure, becomging simply $modload omudpspoof $ActionUDPSpoofTargetHost server.example.com *.* :omudpspoof: it could be simplified even further if there was some way to specify the destination on the action line (like the @ and @@ functions do today, could we use @S@ to indicate spoofing?) changing the defaults should have no problems with backwards compatibility, adding/changing how the desitnation is specified could break backward compatibility, but this is a very new piece of functionality and the simplification may be worth it (what versions have this available?) David Lang From Jon.Combe at telindus.co.uk Mon Jul 12 15:55:41 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 14:55:41 +0100 Subject: [rsyslog] Last message repeated n times problem Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> I see from a previous post (http://lists.adiscon.net/pipermail/rsyslog/2010-February/003416.html) that this has come up before but there was no answer previously. I have rsyslogd (the latest, version 5.4) installed and running on a host configured to accept remote syslog messages. I have another server configured to send it's syslog messages to the host running rsyslog. I have rsyslog configured to store its entries in a MySQL database using the supplied rsyslog MySQL module. What I find is that most of the messages come through as expected. For example:- *************************** 3. row *************************** ID: 163941 CustomerID: NULL ReceivedAt: 2010-07-12 14:42:38 DeviceReportedTime: 2010-07-12 14:42:38 Facility: 10 Priority: 6 FromHost: 10.167.3.18 Message: pam_unix(sshd:session): session closed for user root NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: sshd[7809]: EventLogType: NULL GenericFileName: NULL SystemID: NULL However each time I get a "Last message repeated X times" message I see corrupted entries in the database:- *************************** 2. row *************************** ID: 163942 CustomerID: NULL ReceivedAt: 2010-07-12 14:43:15 DeviceReportedTime: 2010-07-12 14:43:15 Facility: 3 Priority: 3 FromHost: last Message: repeated 5 times NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: message EventLogType: NULL GenericFileName: NULL SystemID: NULL You can see that the message text has been incorrectly split across the fields message, FromHost and SysLogTag. I have run a tcpdump and here are the two relevant packets:- 14:42:38.985098 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 111: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 97) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 69 Facility authpriv (10), Severity info (6) Msg: sshd[7809]: pam_unix(sshd:session): session closed for user root\012 0x0000: 3c38 363e 7373 6864 5b37 3830 395d 3a20 0x0010: 7061 6d5f 756e 6978 2873 7368 643a 7365 0x0020: 7373 696f 6e29 3a20 7365 7373 696f 6e20 0x0030: 636c 6f73 6564 2066 6f72 2075 7365 7220 0x0040: 726f 6f74 0a 0x0000: 4500 0061 0000 4000 3f11 20ec 0aa7 0312 E..a.. at .?....... 0x0010: 0aa7 0241 0202 0202 004d 5dc8 3c38 363e ...A.....M].<86> 0x0020: 7373 6864 5b37 3830 395d 3a20 7061 6d5f sshd[7809]:.pam_ 0x0030: 756e 6978 2873 7368 643a 7365 7373 696f unix(sshd:sessio 0x0040: 6e29 3a20 7365 7373 696f 6e20 636c 6f73 n):.session.clos 0x0050: 6564 2066 6f72 2075 7365 7220 726f 6f74 ed.for.user.root 0x0060: 0a . 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 34 Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 0x0020: 730a 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 E..>.. at .?.!..... 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e ...A.....*.D<27> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 last.message.rep 0x0030: 6561 7465 6420 3520 7469 6d65 730a eated.5.times. In both cases it seems to me that the IP address of the sender has been included in the packet (0a a7 03 12) which translates as the IP 10.167.3.18 which is the sender. Is this an rsyslog issue? Is it a known problem? Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 16:50:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 16:50:10 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> [snip] Well, as you can see: > 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > sum ok] SYSLOG, length: 34 > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > 0x0020: 730a > 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > E..>.. at .?.!..... > 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > ...A.....*.D<27> > 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > last.message.rep > 0x0030: 6561 7465 6420 3520 7469 6d65 730a > eated.5.times. > the message is totally malformed. > In both cases it seems to me that the IP address of the sender has been > included in the packet (0a a7 03 12) which translates as the IP > 10.167.3.18 which is the sender. > > Is this an rsyslog issue? Is it a known problem? The sender must be fixed to emit correct format. It is a known problem with some senders (sysklogd namely), but we have not yet provided a work-around for it because that causes unnecessary performance loss on the rsyslog side. However, thinking now about it, a special message parser module could be used to solve that situation. That way, only those that actually have this problem would need to bear the cost of the work-around. Let me think a bit about this... > Thanks. > Jon. > > This email is private No, it isn't -- it was sent to a public mailing list and is probably archived on a myriad of sites by now. Please note that as of the ToS of the mailing list, we do not accept any liability. It would be decent to tell your mail folks to turn off this disclaimer for list-directed mail. Thanks! Rainer > and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Jon.Combe at telindus.co.uk Mon Jul 12 17:19:13 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 16:19:13 +0100 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > >the message is totally malformed. Rainer, Thanks for the reply. I'm no expert on the format I'm afraid but I have looked at the RFC http://tools.ietf.org/search/rfc5424 You're correct that the sender is using sysklogd. Would you be able to tell me how it is malformed? I can see that something (tcpdump?) has parsed the message here:- Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 Reading the RFC it says the header should be PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID Where pri are enclosed in < and > (which is the <27> in the above), followed by a space and then the version, which can be NIL, followed by timestamp (which can also be NIL), followed by hostname (also NIL permitted), APP NAME (also NIL is permitted), PROCID (also NIL permitted), MSGID (also NIL permitted) and then after the header is the actual message. So my understanding of the RFC is that the only field required in the header is , which is present. I'm not clear on whether the spaces are required or not or only if the optional fields are present. The only difference I see between the valid packet I sent and this one is that the valid packet has "sshd[7809]:" at the start of the message - is this the APP-NAME field from the header perhaps? I realise from the RFC that many of these fields are listed as SHOULD be provided Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 17:22:43 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 17:22:43 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F95@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Jon Combe > Sent: Monday, July 12, 2010 5:19 PM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 > > You're correct that the sender is using sysklogd. Would you be able to > tell me how it is malformed? I can see that something (tcpdump?) has > parsed the message here:- > > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > > Reading the RFC it says the header should be > > PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID > > Where pri are enclosed in < and > (which is the <27> in the above), > followed by a space and then the version, which can be NIL, followed by > timestamp (which can also be NIL), followed by hostname (also NIL > permitted), APP NAME (also NIL is permitted), PROCID (also NIL > permitted), MSGID (also NIL permitted) and then after the header is the > actual message. > > So my understanding of the RFC is that the only field required in the > header is , which is present. I'm not clear on whether the spaces > are required or not or only if the optional fields are present. Spaces are required, VERSION can not be NILVALUE and NILVALUE is defined as "-". ;) Rainer > > The only difference I see between the valid packet I sent and this one > is that the valid packet has "sshd[7809]:" at the start of the message > - is this the APP-NAME field from the header perhaps? I realise from > the RFC that many of these fields are listed as SHOULD be provided > > Thanks. > Jon. > > This email is private and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From chs7490 at gmail.com Mon Jul 12 23:33:36 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 06:33:36 +0900 Subject: [rsyslog] kernel messages on usb flash drive Message-ID: Hi everyone I want to write kernel meesage,which is generally recorded at /var/log/messages, at usb flash memory. It goes well when the kernel mesage recording file is specified on hard disk, but it does not on usb flash memory. What I have worked on is as below. -- >mkdir /var/log/hm >mount /dev/sdb /var/log/hm (I checked that usb flash memory is mounted.) >vi /etc/rsyslog.conf I changed *.info;mail.none;authpriv.none;cron.none /var/log/messages to *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages -- When the kernel message recording place is specified on hard disk (such as /var/log/messages2), it records well. However, it does not record on usb flash memory Please let me know if there is something that I have to revise or add thanks in advance, Cheon. From david at lang.hm Mon Jul 12 23:52:05 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 14:52:05 -0700 (PDT) Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: On Tue, 13 Jul 2010, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- >> mkdir /var/log/hm > >> mount /dev/sdb /var/log/hm > (I checked that usb flash memory is mounted.) > >> vi /etc/rsyslog.conf > > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory when you say it doesn't record on the USB flash, what is happening? do you get errors or do you find that the data is still written to the hard drive? My guess is that it's being written to the hard drive because the USB stick is no mounted yet when rsyslog starts, so the file that it has open is on the hard drive and not the flash drive. you need to start rsyslog after the flash drive is mounted, and then stop rsyslog before you unmount it to make sure the data is written to it. David Lang From rory at ooma.com Mon Jul 12 23:43:05 2010 From: rory at ooma.com (Rory Toma) Date: Mon, 12 Jul 2010 14:43:05 -0700 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: <4C3B8C69.6080001@ooma.com> What filesystem is on your USB drive? If you just plugged something in, it's likely FAT32, and you may be seeing performance issues if you have a lot of messages. I assume you can write files by hand to this drive? On 7/12/10 2:33 PM, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- > >> mkdir /var/log/hm >> > >> mount /dev/sdb /var/log/hm >> > (I checked that usb flash memory is mounted.) > > >> vi /etc/rsyslog.conf >> > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory > > Please let me know if there is something that I have to revise or add > > thanks in advance, > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Jul 13 00:25:21 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 15:25:21 -0700 (PDT) Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 12 Jul 2010, Rainer Gerhards wrote: > [snip] > Well, as you can see: >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > the message is totally malformed. > >> In both cases it seems to me that the IP address of the sender has been >> included in the packet (0a a7 03 12) which translates as the IP >> 10.167.3.18 which is the sender. >> >> Is this an rsyslog issue? Is it a known problem? > > The sender must be fixed to emit correct format. It is a known problem with > some senders (sysklogd namely), but we have not yet provided a work-around > for it because that causes unnecessary performance loss on the rsyslog side. > However, thinking now about it, a special message parser module could be used > to solve that situation. That way, only those that actually have this problem > would need to bear the cost of the work-around. Let me think a bit about > this... if I'm understanding this correctly the filter seems like it would be pretty simple. accept the message as being potentially well formed IFF (if and only if) it meets the following criteria. 1. has a valid tag 2. characters 4, 7, 16 are ' ' 3. characters 10,13 are ':' this isn't absolute proof that this is a valid timestamp, but it's pretty good and very quick to check in C. if not, it can't possibly be a valid message, set the timestamp (current time) and hostname (based on the source IP in the packet). then check the word staring at position 17 to see if it is made up of characters that mean it could be a hostname (a-zA-Z0-9.-) if not, it can't possibly be a valid hostname, set the hostname (based on the source IP in the packet) now, if something passes this test but has other garbage in the hostname field, that will take system specific fixups. In this case, after the tests I describe you would still have the syslog tag of 'last' and the message 'message repeated 5 times' that would need to be fixed by a filter that checked for 'last message repeated' and put it all in the message (filling in a dummy or blank syslog tag) there are unfortunantly a bunch of such filters that are needed. now that they are easy to create we can hopefully get a bunch of them done so that only the people who need them bother with them. one question on stackable filters. how much overhead is there in putting the tests in separate filters as opposed to in one filter? for example, take 3 tests 1. 'message forwarded from hostname' -> hostname 2. 'last message repeated' -> move to message body 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN what would the impact be of having each of these as separate filters vs one filter with configurable tests? (i.e. is there a noticable overhead in stacking the filters) David Lang >> Thanks. >> Jon. >> >> This email is private > > No, it isn't -- it was sent to a public mailing list and is probably archived > on a myriad of sites by now. Please note that as of the ToS of the mailing > list, we do not accept any liability. It would be decent to tell your mail > folks to turn off this disclaimer for list-directed mail. Thanks! > > Rainer > >> and may be confidential and is for the intended >> recipient only. If misdirected, please notify us by telephone and >> confirm that it has been deleted from your system and any copies >> destroyed. If you are not the intended recipient you are strictly >> prohibited from using, printing, copying, distributing or disseminating >> this email or any information contained in it. We use reasonable >> endeavours to virus scan all emails leaving the Company but no warranty >> is given that this email and any attachments are virus free. You should >> undertake your own virus checking. The right to monitor email >> communications through our network is reserved by us. >> >> Telindus Limited is a company registered in England and Wales under >> number 02020395. The registered office is Centurion, Riverside Way, >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From sean at conman.org Tue Jul 13 02:50:37 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 20:50:37 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> Message-ID: <20100713005037.GB3089@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > But my overall assumption is that we stick what we currently have, but > > extend > > it in a way that provides scoping and do so in a way the provides as > > many > > usable interim steps as possible (without adding major work just for > > those > > steps). I hope this covers the spirit of our discussion. > > I tried very hard the past days to get a grammar together that is an > evolution from what we currently have. I did not yet succeed fully (thus I > have no formal grammar to show), but I think I made some progress. > > So please let me come back and present a config sample: > > http://download.rsyslog.com/rainerscript2_rsyslog.conf > > It actually is three configs in one file > > a) a standard rsyslog.conf in mixed new and old format > b) a standard rsyslog.conf in new format, only > c) a complex rsyslog.conf (not really working) in new format > > [partitioned by (just) comments] > > Note that being an evolution, any currently existing rsyslog.conf would also > be a valid new conf (via the *same* parser). I have not thought out the full > semantics and thousand other things that need to be thought of -- this > actually opened up a can of worms ;) However, I find the proposed format > seems to be a good compromise between the need to preserve and the need to > move on, and between the need for simplicity and the need for power. > > As such, before I invest even more time into that format, I'd like to get > some feedback on what you folks think ;) Okay, take number two. After reading the various comments about my last message (using Lua---rejected for various reasons) what it sounds like you want is a more declaritive syntax---a mapping of input to output. Have you considered a syntax like Haskel or Erlang? There functions are declared by pattern matching input parameters and thus, you tend not to see many (if any) if statements (okay, I checked a sizable Erlang program I have, and it does use 'case' in a few spots, but not many). The original syslog.conf file has what I mean to some degree, with a syntax like: mail.* @maillogprocessinghost mail.warn /some/log/file cron.* /some/other/logfile Since most of what you want to do is based off the input message, how about extending this style of syntax to more than just the facility/priority pair? Since host, program, facility, priority and message are typically the most interesting fields (at least, in my experience), perhaps a syntax that includes matching those as well would work. Something like: # order is host, program, facility, priority, msg ( * , * , mail , (warn err crit alert emerg) , *) => file("/var/log/mail.log") # the above is the same as the traditional syslog syntax of # mail.warn /var/log/mail.log # log cron messages to logs based off the hostname ( * , * , cron , * , * ) => file("/var/log/{host}/cron.log") # define a list of values routers = { ip1 ip2 ip3 ip4 } # use said list in a pattern matching rule # the msg field uses a regex ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*Neighbor Down)/ ) => email( ... ) ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*LOADING to FULL)/ ) => email( ... ) # feed SSH failed logins to external program, to block repeated attemts # ~"blah" will check for the existance of "blah" somewhere in the string # log all SSH information to a file ( localhost , sshd , auth2 , info , ~"Fail password for" ) => exec( ... ) ( * , sshd , auth2 , * , * ) => file( ... ) # auth messages go offsite, never locally, everything else # gets logged locally, except for *.debug, which gets relayed # to development machines for processing ( * , * , auth , * , * ) => relay(secure) ( * , * , !auth , !debug , * ) => file(...) ( * , * , !auth , debug , * ) => relay(dev) Seldom used fields can be explicitely checked ( * , * , * , * , * , relay = A) => ... No if statements in sight, just a series of patterns and actions when said pattern is matched. You also have "variables" and a way to reference them, and I left the syntax for actions vague intentionally. -spc (Just an idea ... ) From sean at conman.org Tue Jul 13 03:09:26 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 21:09:26 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <20100713010926.GC3089@brevard.conman.org> It was thus said that the Great Jon Combe once stated: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 The format being sent is documented in RFC-3164, in which the only mandatory field is PRI---it's up the the receiving end to make sense of the rest of the message. It appears that in your case rsyslogd is mis-interpreting the incoming message. -spc From david at lang.hm Tue Jul 13 06:29:45 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 21:29:45 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713005037.GB3089@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: On Mon, 12 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >>> But my overall assumption is that we stick what we currently have, but >>> extend >>> it in a way that provides scoping and do so in a way the provides as >>> many >>> usable interim steps as possible (without adding major work just for >>> those >>> steps). I hope this covers the spirit of our discussion. >> >> I tried very hard the past days to get a grammar together that is an >> evolution from what we currently have. I did not yet succeed fully (thus I >> have no formal grammar to show), but I think I made some progress. >> >> So please let me come back and present a config sample: >> >> http://download.rsyslog.com/rainerscript2_rsyslog.conf >> >> It actually is three configs in one file >> >> a) a standard rsyslog.conf in mixed new and old format >> b) a standard rsyslog.conf in new format, only >> c) a complex rsyslog.conf (not really working) in new format >> >> [partitioned by (just) comments] >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > Okay, take number two. > > After reading the various comments about my last message (using > Lua---rejected for various reasons) what it sounds like you want is a more > declaritive syntax---a mapping of input to output. Have you considered a > syntax like Haskel or Erlang? There functions are declared by pattern > matching input parameters and thus, you tend not to see many (if any) if > statements (okay, I checked a sizable Erlang program I have, and it does use > 'case' in a few spots, but not many). > > The original syslog.conf file has what I mean to some degree, with a > syntax like: > > mail.* @maillogprocessinghost > mail.warn /some/log/file > cron.* /some/other/logfile > > Since most of what you want to do is based off the input message, how > about extending this style of syntax to more than just the facility/priority > pair? Since host, program, facility, priority and message are typically the > most interesting fields (at least, in my experience), perhaps a syntax that > includes matching those as well would work. Something like: this is the approach that rsyslog took with the old config file. the problem is that we are now getting capibilities that can't easily be represented this way David Lang From chs7490 at gmail.com Tue Jul 13 06:49:34 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 13:49:34 +0900 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: 2010/7/13 > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > Hi everyone > > > > > > I want to write kernel meesage,which is generally recorded at > > /var/log/messages, at usb flash memory. > > It goes well when the kernel mesage recording file is specified on hard > > disk, but it does not on usb flash memory. > > > > What I have worked on is as below. > > > > -- > >> mkdir /var/log/hm > > > >> mount /dev/sdb /var/log/hm > > (I checked that usb flash memory is mounted.) > > > >> vi /etc/rsyslog.conf > > > > I changed > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > to > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > -- > > > > When the kernel message recording place is specified on hard disk (such > as > > /var/log/messages2), it records well. However, it does not record on usb > > flash memory > > when you say it doesn't record on the USB flash, what is happening? > do you > get errors or do you find that the data is still written to the hard > drive? > ==> I can see following message through 'dmesg' cmd. SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts i don't know what the message means. I cannot find the data on the hard drive. > > My guess is that it's being written to the hard drive because the USB > stick is no mounted yet when rsyslog starts, so the file that it has open > is on the hard drive and not the flash drive. > you need to start rsyslog after the flash drive is mounted, and then stop > rsyslog before you unmount it to make sure the data is written to it. > ==> after the usb stick is mounted, i restarted rsyslog. But nothing is changed T.T when i try to write kenel messages to usb flash drive, I can see kernel messages using 'dmesg' cmd, but they are not written to the flash drive or hard drive. Cheon. From sean at conman.org Tue Jul 13 08:27:22 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 02:27:22 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: <20100713062722.GA3959@brevard.conman.org> It was thus said that the Great david at lang.hm once stated: > On Mon, 12 Jul 2010, Sean Conner wrote: > > > Since most of what you want to do is based off the input message, how > > about extending this style of syntax to more than just the facility/priority > > pair? Since host, program, facility, priority and message are typically the > > most interesting fields (at least, in my experience), perhaps a syntax that > > includes matching those as well would work. Something like: > > > > this is the approach that rsyslog took with the old config file. > > the problem is that we are now getting capibilities that can't easily be > represented this way Such as? That's one reason why I took the approach I did in my syslogd (which uses Lua)---if the configuration file is going to be complex anyway, why not just write a syslog filter in Lua and be done with it? I know why Rainer is rejecting Lua (and by extension, even his own RanierScript), but the current method is obviously not working, because the topic keeps coming up as mroe and more use cases come into being. So perhaps the question to ask is not what the configuration file looks like, but rather, what, exactly, is rsyslogd expected to do? Just route messages from sources to destinations and nothing more? Or do people want logic in the processing? (My guess is "Yes"---and that's what is causing problems with the configuration file). -spc From rgerhards at hq.adiscon.com Tue Jul 13 09:08:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:08:50 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com><35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> <20100713010926.GC3089@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> > The format being sent is documented in RFC-3164, in which the only > mandatory field is PRI No, not even PRI ;) > ---it's up the the receiving end to make sense of > the > rest of the message. It appears that in your case rsyslogd is > mis-interpreting the incoming message. Technically speaking, RFC3164 is not a standard, because it is an informational document. I have elaborated about its implications in: http://www.rsyslog.com/doc-syslog_parsing.html So if we follow your view, we simply need to accept anything as being valid, and as such we do never know which information is contained inside a message (just ask yourself the question how you know what the sender meant in this case. Message is "hostname junk" Was this intended to mean MSG = "hostname junk" or was it intended to mean hostname="hostname", MSG="junk" -- or something else? As I already wrote, we can potentially handle the "last message repeated ..." case, but only at a performance toll (we need to do a full message compare). I do not consider this acceptable as a general case. But crafting a parser module probably makes a lot of sense (thankfully we have this capability now). Rainer From david at lang.hm Tue Jul 13 09:10:57 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 00:10:57 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713062722.GA3959@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: On Tue, 13 Jul 2010, Sean Conner wrote: > It was thus said that the Great david at lang.hm once stated: >> On Mon, 12 Jul 2010, Sean Conner wrote: >> >>> Since most of what you want to do is based off the input message, how >>> about extending this style of syntax to more than just the facility/priority >>> pair? Since host, program, facility, priority and message are typically the >>> most interesting fields (at least, in my experience), perhaps a syntax that >>> includes matching those as well would work. Something like: >> >> >> >> this is the approach that rsyslog took with the old config file. >> >> the problem is that we are now getting capibilities that can't easily be >> represented this way > > Such as? > > That's one reason why I took the approach I did in my syslogd (which uses > Lua)---if the configuration file is going to be complex anyway, why not just > write a syslog filter in Lua and be done with it? I know why Rainer is > rejecting Lua (and by extension, even his own RanierScript), but the current > method is obviously not working, because the topic keeps coming up as mroe > and more use cases come into being. > > So perhaps the question to ask is not what the configuration file looks > like, but rather, what, exactly, is rsyslogd expected to do? Just route > messages from sources to destinations and nothing more? Or do people want > logic in the processing? (My guess is "Yes"---and that's what is causing > problems with the configuration file). if-then-else logic in the processing, sending things to the same output based on different logic, subsets of rules that only get evaluated if earlier conditions are true, allowing some outputs to queue while not others. just as a few of them earlier in this thread some of the examples that Rainer gave give some hints of this. David Lang From rgerhards at hq.adiscon.com Tue Jul 13 09:16:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:16:32 +0200 Subject: [rsyslog] kernel messages on usb flash drive References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F98@GRFEXC.intern.adiscon.com> All I can say is that rsyslog just calls the usual open() API. You may run it in debug mode to see what the OS returns when trying to open the file on the USB drive. From rsyslog's POV, all files are equal, no matter where they reside. Of course, this means the filesystem must be mounted (as David pointed out). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Hongseok Cheon > Sent: Tuesday, July 13, 2010 6:50 AM > To: rsyslog-users > Subject: Re: [rsyslog] kernel messages on usb flash drive > > 2010/7/13 > > > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > > > Hi everyone > > > > > > > > > I want to write kernel meesage,which is generally recorded at > > > /var/log/messages, at usb flash memory. > > > It goes well when the kernel mesage recording file is specified on > hard > > > disk, but it does not on usb flash memory. > > > > > > What I have worked on is as below. > > > > > > -- > > >> mkdir /var/log/hm > > > > > >> mount /dev/sdb /var/log/hm > > > (I checked that usb flash memory is mounted.) > > > > > >> vi /etc/rsyslog.conf > > > > > > I changed > > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > > to > > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > > -- > > > > > > When the kernel message recording place is specified on hard disk > (such > > as > > > /var/log/messages2), it records well. However, it does not record > on usb > > > flash memory > > > > when you say it doesn't record on the USB flash, what is happening? > > > > > > do you > > get errors or do you find that the data is still written to the hard > > drive? > > > ==> > I can see following message through 'dmesg' cmd. > SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts > i don't know what the message means. > > I cannot find the data on the hard drive. > > > > > > > > > My guess is that it's being written to the hard drive because the USB > > stick is no mounted yet when rsyslog starts, so the file that it has > open > > is on the hard drive and not the flash drive. > > > > you need to start rsyslog after the flash drive is mounted, and then > stop > > rsyslog before you unmount it to make sure the data is written to it. > > > > ==> > after the usb stick is mounted, i restarted rsyslog. But nothing is > changed > T.T > > > when i try to write kenel messages to usb flash drive, > I can see kernel messages using 'dmesg' cmd, but they are not written > to > the flash drive or hard drive. > > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:31:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:31:32 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 9:11 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great david at lang.hm once stated: > >> On Mon, 12 Jul 2010, Sean Conner wrote: > >> > >>> Since most of what you want to do is based off the input message, > how > >>> about extending this style of syntax to more than just the > facility/priority > >>> pair? Since host, program, facility, priority and message are > typically the > >>> most interesting fields (at least, in my experience), perhaps a > syntax that > >>> includes matching those as well would work. Something like: > >> > >> > >> > >> this is the approach that rsyslog took with the old config file. > >> > >> the problem is that we are now getting capibilities that can't > easily be > >> represented this way > > > > Such as? > > > > That's one reason why I took the approach I did in my syslogd (which > uses > > Lua)---if the configuration file is going to be complex anyway, why > not just > > write a syslog filter in Lua and be done with it? I know why Rainer > is > > rejecting Lua (and by extension, even his own RanierScript), but the > current > > method is obviously not working, because the topic keeps coming up as > mroe > > and more use cases come into being. > > > > So perhaps the question to ask is not what the configuration file > looks > > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > > messages from sources to destinations and nothing more? Or do people > want > > logic in the processing? (My guess is "Yes"---and that's what is > causing > > problems with the configuration file). > > if-then-else logic in the processing, sending things to the same output > based on different logic, subsets of rules that only get evaluated if > earlier conditions are true, allowing some outputs to queue while not > others. > > just as a few of them > > earlier in this thread some of the examples that Rainer gave give some > hints of this. To add some of the less obvious things: support for multiple listeners going to different outputs, in an easy to use way. Support for explicitely specified concurrency (or serialization) for high-speed environments, support for different queues, and tying of different queues to different object classes (inputs, message processors, actions). Flexibility to support configuration for even unexpected plugins that we may not even know about (because some third party writes them and never publishes them). But I begin to agree that we, the community, as a whole have very different needs. I have gotten the impression that it is probably a good idea to stop the current effort and re-start it with a requirements definition. I have tried to digest the discussions on config format we had over the year, but sometimes it looks like the only consensus we have is that the current format is ugly and hard to use. The solutions are very wide-ranging. I have even briefly looked at syslog-ng, and seen a lot of the pain again that makes me dislike that format (but I'll probably still have a closer look and will try to write up my detailed position why I do not find buying into this format is a good idea). All in all, I think the best way to re-start our thinking about the config format is to set up a web site where we gather user feedback on a) what problems they have with the config format (not what they just dislike, but real problems, an example From myself: it is nearly impossible to get the sequence right To bind inputs to the right rulesets AND use ruleset inclusion) b) which alternatives they see With all this being on a web site, it may be possible to craft a better decision in 6 to 9 month, assuming we were able to gain sufficient feedback during that time. An alternative would be to create a config parser interface, so that everybody could code up his favorite config language. However, this seems to be impractical, as many of the ideas floating around (Lua, syslog-ng style) require not just different config parsers, but a different rsyslog processing core as well. Obviously a complete rewrite in the case of Lua, less for syslog-ng, but still considerate. For the syslog-ng style we would need to create named filters, something that I really find questionable. Also, we would need to add an interim layer between inputs and rulesets, something that eats performance. In any case, this are not config-parser only changes. Of course, I could just pick one of the alternatives. However, it doesn't make sense to invest a couple of month to do the config system "right", if we know that a lot of folks will still be unhappy after we have done this. Rainer From rgerhards at hq.adiscon.com Tue Jul 13 09:40:25 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:40:25 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 12:25 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > On Mon, 12 Jul 2010, Rainer Gerhards wrote: > > > [snip] > > Well, as you can see: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > the message is totally malformed. > > > >> In both cases it seems to me that the IP address of the sender has > been > >> included in the packet (0a a7 03 12) which translates as the IP > >> 10.167.3.18 which is the sender. > >> > >> Is this an rsyslog issue? Is it a known problem? > > > > The sender must be fixed to emit correct format. It is a known > problem with > > some senders (sysklogd namely), but we have not yet provided a work- > around > > for it because that causes unnecessary performance loss on the > rsyslog side. > > However, thinking now about it, a special message parser module could > be used > > to solve that situation. That way, only those that actually have this > problem > > would need to bear the cost of the work-around. Let me think a bit > about > > this... > > if I'm understanding this correctly the filter seems like it would be > pretty simple. > > accept the message as being potentially well formed IFF (if and only > if) > it meets the following criteria. > > 1. has a valid tag > > 2. characters 4, 7, 16 are ' ' > > 3. characters 10,13 are ':' > > this isn't absolute proof that this is a valid timestamp, but it's > pretty > good and very quick to check in C. > That's definitely a way to go. Unfortunately, pmrfc3164 already does a lot of guesswork for other cases where things are malformed (just as an example, there are devices that put an additional space in front of the date, invalidating all the offsets you give...). The problem is that in a strict sense, RFC3164 does not demand anything. So there are lots of things that are mutually exclusive. In the current parser, I try to weigh importance of occurrence and performance. So the most prominent cases are probably handled, conflicting less common cases not. "last message repeated n times" is pretty useless, so it has low priority. I have also a "performance filter" on my mind, that means I do only those things that seem reasonable. However, the whole idea of introducing message parsers was to solve exactly that problem. So I think it is natural to write a new message parser rather than try (and probably fail) to fiddle even more with the 3164 parser, which already is overwhelmed with guesswork. For "last message...", I would need to do a full string compare, anything else would be incompatible with the already-existing guesswork in pmrfc3164. Rainer > if not, it can't possibly be a valid message, set the timestamp > (current > time) and hostname (based on the source IP in the packet). > > then check the word staring at position 17 to see if it is made up of > characters that mean it could be a hostname (a-zA-Z0-9.-) > > if not, it can't possibly be a valid hostname, set the hostname (based > on > the source IP in the packet) > > > now, if something passes this test but has other garbage in the > hostname > field, that will take system specific fixups. In this case, after the > tests I describe you would still have the syslog tag of 'last' and the > message 'message repeated 5 times' > > that would need to be fixed by a filter that checked for 'last message > repeated' and put it all in the message (filling in a dummy or blank > syslog tag) > > there are unfortunantly a bunch of such filters that are needed. now > that > they are easy to create we can hopefully get a bunch of them done so > that > only the people who need them bother with them. > > one question on stackable filters. > > how much overhead is there in putting the tests in separate filters > as > opposed to in one filter? > > for example, take 3 tests > > 1. 'message forwarded from hostname' -> hostname > > 2. 'last message repeated' -> move to message body > > 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN > > what would the impact be of having each of these as separate filters vs > one filter with configurable tests? (i.e. is there a noticable overhead > in > stacking the filters) > > David Lang > > >> Thanks. > >> Jon. > >> > >> This email is private > > > > No, it isn't -- it was sent to a public mailing list and is probably > archived > > on a myriad of sites by now. Please note that as of the ToS of the > mailing > > list, we do not accept any liability. It would be decent to tell your > mail > > folks to turn off this disclaimer for list-directed mail. Thanks! > > > > Rainer > > > >> and may be confidential and is for the intended > >> recipient only. If misdirected, please notify us by telephone and > >> confirm that it has been deleted from your system and any copies > >> destroyed. If you are not the intended recipient you are strictly > >> prohibited from using, printing, copying, distributing or > disseminating > >> this email or any information contained in it. We use reasonable > >> endeavours to virus scan all emails leaving the Company but no > warranty > >> is given that this email and any attachments are virus free. You > should > >> undertake your own virus checking. The right to monitor email > >> communications through our network is reserved by us. > >> > >> Telindus Limited is a company registered in England and Wales under > >> number 02020395. The registered office is Centurion, Riverside Way, > >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:44:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:44:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9B@GRFEXC.intern.adiscon.com> > So perhaps the question to ask is not what the configuration file > looks > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > messages from sources to destinations and nothing more? Or do people > want > logic in the processing? (My guess is "Yes"---and that's what is > causing > problems with the configuration file). You still miss the point that performance is *very* critical. Also, audit-gradness for the routing process is critical. It's not just about flow-of-control. You need to be able to configure all these properties for various use cases. Rainer From sean at conman.org Tue Jul 13 09:46:39 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 03:46:39 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> References: <20100713010926.GC3089@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> Message-ID: <20100713074639.GB23556@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > The format being sent is documented in RFC-3164, in which the only > > mandatory field is PRI > > No, not even PRI ;) Yes, you are correct. I misspoke 8-) > > ---it's up the the receiving end to make sense of > > the > > rest of the message. It appears that in your case rsyslogd is > > mis-interpreting the incoming message. > > Technically speaking, RFC3164 is not a standard, because it is an > informational document. I have elaborated about its implications in: > > http://www.rsyslog.com/doc-syslog_parsing.html > > So if we follow your view, we simply need to accept anything as being valid, > and as such we do never know which information is contained inside a message > (just ask yourself the question how you know what the sender meant in this > case. Message is > > "hostname junk" > > Was this intended to mean MSG = "hostname junk" or was it intended to mean > hostname="hostname", MSG="junk" -- or something else? In my own project, I treat it as MSG = "hostname junk" with a facility of USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, because of the wide variance I've encountered in parsing syslog messages, when I send out a message, I use the IP address as the hostname (I find the IP address (either v4 or v6) to be unambigious and easier to find than a hostname), and anything else in that portion (up to a colon) as the program name (one exception: anything in square brackets is a process id). The entire parser routine is 210 lines of C (including a ton of comments) and it works enough for my tastes (and if I come across somethign that doesn't parse right, I still have the raw log to check against). Adding RFC-5424 parsing support would be easy, but I don't have anything generating RFC-5424 records (well, I suppose my program could relay in RFC-5424 format ... ) -spc From rgerhards at hq.adiscon.com Tue Jul 13 10:15:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:15:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> <20100713074639.GB23556@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 9:47 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > > The format being sent is documented in RFC-3164, in which the > only > > > mandatory field is PRI > > > > No, not even PRI ;) > > Yes, you are correct. I misspoke 8-) > > > > ---it's up the the receiving end to make sense of > > > the > > > rest of the message. It appears that in your case rsyslogd is > > > mis-interpreting the incoming message. > > > > Technically speaking, RFC3164 is not a standard, because it is an > > informational document. I have elaborated about its implications in: > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > So if we follow your view, we simply need to accept anything as being > valid, > > and as such we do never know which information is contained inside a > message > > (just ask yourself the question how you know what the sender meant in > this > > case. Message is > > > > "hostname junk" > > > > Was this intended to mean MSG = "hostname junk" or was it intended to > mean > > hostname="hostname", MSG="junk" -- or something else? > > In my own project, I treat it as MSG = "hostname junk" with a > facility of > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, > because of the wide variance I've encountered in parsing syslog > messages, > when I send out a message, I use the IP address as the hostname (I find > the > IP address (either v4 or v6) to be unambigious and easier to find than > a > hostname), and anything else in that portion (up to a colon) as the > program > name (one exception: anything in square brackets is a process id). That's the well known approach, which means you do not really interpret the message. Also, it makes your project unsuitable for NAT environments and relay chains. This, as a side-note, where some of the reasons why syslog standardization started. Even 10 years ago, people where quite unsatisfied with these problems. > > The entire parser routine is 210 lines of C (including a ton of > comments) > and it works enough for my tastes (and if I come across somethign that > doesn't parse right, I still have the raw log to check against). %rawmsg% Rainer > Adding > RFC-5424 parsing support would be easy, but I don't have anything > generating > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > format > ... ) > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:16:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:16:22 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Oh, yes, you got me here. So please elaborate how you parse "<13>hostname junk" ;) Rainer > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:30:15 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:30:15 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Spc, well, on second thought: rather than (somewhat) heatedly discussing the pros and cons of various parser modes: Wouldn't it make sense if you turn your code into a parser module and contribute that to the project? So users could decide what they prefer. I think that would be truly in the spirit of open source. I will happily accept such a contribution! (It is always great to have freedom of choice). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Tue Jul 13 11:09:04 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:09:04 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> Message-ID: <20100713090904.GA18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > > > > In my own project, I treat it as MSG = "hostname junk" with a > > > facility of > > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > > Oh, yes, you got me here. So please elaborate how you parse > > "<13>hostname junk" > > ;) It's be interpreted as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: notice (this is priority---I call it level) msg: hostname junk If instead it was: <15>hostname junk my program would parse it as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: debug msg: hostname junk -spc (At least it's consistent 8-) From sean at conman.org Tue Jul 13 11:18:54 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:18:54 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Message-ID: <20100713091854.GB18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > Spc, > > well, on second thought: rather than (somewhat) heatedly discussing the pros > and cons of various parser modes: Wouldn't it make sense if you turn your > code into a parser module and contribute that to the project? So users could > decide what they prefer. I think that would be truly in the spirit of open > source. I will happily accept such a contribution! (It is always great to > have freedom of choice). Which code? My 210 lines of parser? Or a module to toss the message to some Lua code? -spc From rgerhards at hq.adiscon.com Tue Jul 13 11:31:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 11:31:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> <20100713091854.GB18093@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 11:19 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > Spc, > > > > well, on second thought: rather than (somewhat) heatedly discussing > the pros > > and cons of various parser modes: Wouldn't it make sense if you turn > your > > code into a parser module and contribute that to the project? So > users could > > decide what they prefer. I think that would be truly in the spirit of > open > > source. I will happily accept such a contribution! (It is always > great to > > have freedom of choice). > > Which code? My 210 lines of parser? I think we were talking about the parser here ;) So, yes, I asked you to turn your parser into a parsing module and contribute it to the project. That makes probably an awful lot of more sense than to discuss what *would* be better. Thinking about it, that discussion probably took more time than it would have taken to create a parser module for "last message...". So if you have running code that you think works (at least in some cases) better than the provided parsers, the most natural thing would be to contribute that code and help to grow the project. > Or a module to toss the message > to > some Lua code? Well, if you can do that (as an output module, I assume), I'd definitely would accept that as a contribution as well. Rainer > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 16:21:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:21:46 +0200 Subject: [rsyslog] pmlastmsg available - workaround for: Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Hi all, > That's definitely a way to go. Unfortunately, pmrfc3164 already does a > lot of > guesswork for other cases where things are malformed (just as an > example, > there are devices that put an additional space in front of the date, > invalidating all the offsets you give...). > > The problem is that in a strict sense, RFC3164 does not demand > anything. So > there are lots of things that are mutually exclusive. In the current > parser, > I try to weigh importance of occurrence and performance. So the most > prominent cases are probably handled, conflicting less common cases > not. > "last message repeated n times" is pretty useless, so it has low > priority. I > have also a "performance filter" on my mind, that means I do only those > things that seem reasonable. > > However, the whole idea of introducing message parsers was to solve > exactly > that problem. So I think it is natural to write a new message parser > rather > than try (and probably fail) to fiddle even more with the 3164 parser, > which > already is overwhelmed with guesswork. For "last message...", I would > need to > do a full string compare, anything else would be incompatible with the > already-existing guesswork in pmrfc3164. > > Rainer I have crafted the new message parser I spoke about this morning. The module is called "pmlastmsg" and available via the git master branch right now. The commit is here (you notice it is not much code, if you ignore the macros and preprocessor statements): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=73ebadd5980f91079416a14b a6463d576ecb6207 Doc, with the typical usage sample, is available here: http://www.rsyslog.com/doc-pmlastmsg.html This parser module should solve the "last message repeated n times" problem for all future ;) Rainer From timo.bumke at web.de Tue Jul 13 16:34:21 2010 From: timo.bumke at web.de (Timo Bumke) Date: Tue, 13 Jul 2010 16:34:21 +0200 Subject: [rsyslog] Omoracle ORA-01461 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Message-ID: <4C3C796D.1030003@web.de> Hello, I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: |create table test (hostname varchar2(100), message varchar2(4000)); |I found out that if I am only writing one syslog property to oracle it succeeds. My configuration: |(...) ################ #### ORACLE #### ################ $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt|i| | Any ideas? From rgerhards at hq.adiscon.com Tue Jul 13 16:46:47 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:46:47 +0200 Subject: [rsyslog] spoofing module configuration References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA4@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 09, 2010 11:43 PM > To: rsyslog-users > Subject: [rsyslog] spoofing module configuration > > in reading the spoofing module configuration it strikes me that the > defaults can be significantly improved. > > the common case for needing to so spoofing is that you are spoofing the > original source IP address > > so the current configuration equivalent commands > > $template spoofaddr, "%fromhost-ip%" > $ActionUDPSpoofSourceNameTemplate spoofaddr > > could be made the default (or call it RSYSLOG_spoofaddr to keep from > polluting the namespace) and the result would be far simpler for people > to > configure, becomging simply That's a good idea, and as so far it needs to be specified, we simply can not break existing configs. I'll see to add it ASAP (but I am on the road tomorrow and am now preparing for it). > > $modload omudpspoof > $ActionUDPSpoofTargetHost server.example.com > *.* :omudpspoof: > > it could be simplified even further if there was some way to specify > the > destination on the action line (like the @ and @@ functions do today, > could we use @S@ to indicate spoofing?) Actually, I would not like to do that, because that would merge the functionality into omfwd. Acutally, having tcp and udp in the same module is legacy and cause quite some problems in the past. I am short of splitting these two (it would also have been very useful if we were gone for a new config format in the near term). I think it is not much more burden and clearer to read if we retain a separate module type. But I am open to discussion, I could use @S@ as an alternative module designator, that would work with the current config system, but probably not extend into a new one (whatever we will end up with). > changing the defaults should have no problems with backwards > compatibility, full ack > adding/changing how the desitnation is specified could > break backward compatibility, but this is a very new piece of > functionality and the simplification may be worth it (what versions > have > this available?) 5.1.3 and above Rainer From david at lang.hm Tue Jul 13 19:29:30 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 10:29:30 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: On Tue, 13 Jul 2010, Rainer Gerhards wrote: > To add some of the less obvious things: support for multiple listeners going > to different outputs, in an easy to use way. Support for explicitely > specified concurrency (or serialization) for high-speed environments, support > for different queues, and tying of different queues to different object > classes (inputs, message processors, actions). Flexibility to support > configuration for even unexpected plugins that we may not even know about > (because some third party writes them and never publishes them). > > But I begin to agree that we, the community, as a whole have very different > needs. I have gotten the impression that it is probably a good idea to stop > the current effort and re-start it with a requirements definition. I have > tried to digest the discussions on config format we had over the year, but > sometimes it looks like the only consensus we have is that the current format > is ugly and hard to use. The solutions are very wide-ranging. I have even > briefly looked at syslog-ng, and seen a lot of the pain again that makes me > dislike that format (but I'll probably still have a closer look and will try > to write up my detailed position why I do not find buying into this format is > a good idea). > > All in all, I think the best way to re-start our thinking about the config > format is to set up a web site where we gather user feedback on > > a) what problems they have with the config format > (not what they just dislike, but real problems, an example > From myself: it is nearly impossible to get the sequence right > To bind inputs to the right rulesets AND use ruleset inclusion) > b) which alternatives they see > > With all this being on a web site, it may be possible to craft a better > decision in 6 to 9 month, assuming we were able to gain sufficient feedback > during that time. > > An alternative would be to create a config parser interface, so that > everybody could code up his favorite config language. However, this seems to > be impractical, as many of the ideas floating around (Lua, syslog-ng style) > require not just different config parsers, but a different rsyslog processing > core as well. Obviously a complete rewrite in the case of Lua, less for > syslog-ng, but still considerate. For the syslog-ng style we would need to > create named filters, something that I really find questionable. Also, we > would need to add an interim layer between inputs and rulesets, something > that eats performance. In any case, this are not config-parser only changes. > > Of course, I could just pick one of the alternatives. However, it doesn't > make sense to invest a couple of month to do the config system "right", if we > know that a lot of folks will still be unhappy after we have done this. one thing that's really good about the current rsyslog config is that it makes doing simple things simple, especially for people used to classic syslog. as you say, we need to say what the problems there are with the existing config format and look at how to solve those. We don't necessarily need to change everything. weaknesses that I know of inability to easily/clearly define if-then-else inability to easily/clearly define/use rulesets inability to easily have multiple conditions that go to the same destination (this can be implemented via rulesets, see above) unclear scope rules for config options inability to easily/clearly define per-input rules/filters (this is part of the scope problem above) I don't think that this requires an entirely new config language. I think that almost everything can be solved with a couple simple changes to the config language (although as we found when I proposed this on June 25 there are more drastic changes under the covers to check/correct/document what gets changed when a config option is processed) Ignoring for the moment the problem of changing how the config options are processed (and the fact that you would need to know what data structures are managed/created/modified) what does the following proposal _not_ do? (pasted in from the mail on June 25 since that's now quite a ways back in the archives ;-) I would propose the following (more or less in order of difficulty) introduce scoping whenever you see a "{" in the config file, save the current config options to a stack. when you see a "}" pop the config options from the stack (undoing any changes in between) introduce statement blocks change the parser so that wherever it currently allows one action make it accept a {} block of actions (treat them as if they were multiple actions with & as the selector) introduce named actions something like sub NAME to define and use NAME to use introduce if-then-else internally you could convert it to ruleset { if condition { block discard} { block } } introduct the ability to implcitly define a ruleset if an action is a condition (i.e. nested configutations) then implicitly create a new ruleset to resolve the nesting. with these capabilities available I think that this will allow for straightforward config files representing very complex configurations with very little change internally to rsyslog. I suspect that the result is going to have some bottlenecks in complex configurations due to all the different rulesets and the passing of messages between them, but once the capability is in place in the config file the implementation under the covers could change later to be better optimized. as far as the rsyslog config being hard to understand, I think there are two conditions here. 1. very simple configs where the fact that rsyslog can use a traditional syslog config file (with a header on it that seldom needs to change) is a huge advantage 2. complex configs where the inability to define scope and nest things is a major problem and makes the resulting config hard to write. David Lang From rgerhards at hq.adiscon.com Thu Jul 15 09:41:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:41:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Hi David, thanks for the well-crafted mail. My concerns for this proposal were (and are) mainly based on the "under the cover" changes. Other than that, I think you are right, except that it boils down to personal taste. Let me ignore the internal changes for now. Throwing in "{}" creates a very compact, ultra-brief config language. But it would definitely work. I just have to admit it does not fit my *personal* taste because it carries a lot of implicit scoping as well (like what exactly is meant to be scoped by the {} -- an action, or an input, or a ruleset...). But I think the semantics of this format are close to any other config format that fits rsyslog. So I think it is probably worth giving it a try, so that we make at least some progress. The only thing I really would like to change is to use "()" instead of "{}" because I would like to reserve "{}" for future use, where it may fit the user's expectation better than simple parenthesis. But I guess that's not really a problem. One thing though, that is on my feature list is that I would like to use a more standard parser, that means one that can becreated with lex and Bison. While the hand-crafted parser is fine, it always is more work to extend and enhance it. As the parser is no critical component, I'd prefer to use the simpler approach. However, I need to check if I can find a suitable grammar for this proposal. This also works on the assumption. I'd also just concentrate on actions for now. So to double-check a fairly simple config in that format would look as follows: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files ( $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; ) ============================================================== This is based on the second example in http://www.rsyslog.com/doc-rsyslog_high_database_rate.html I will probably also begin to look at the internal changes. As it looks, we need to make them in any case. So it doesn't hurt to start with them, even though there initially will be no external (user) visibility that they are made. But at first, I'll start looking at how this may be processed by a standard flex/bison parser. From the work I already did, I know this is not easy, but could probably work. Feedback appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 7:30 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > To add some of the less obvious things: support for multiple > listeners going > > to different outputs, in an easy to use way. Support for explicitely > > specified concurrency (or serialization) for high-speed environments, > support > > for different queues, and tying of different queues to different > object > > classes (inputs, message processors, actions). Flexibility to support > > configuration for even unexpected plugins that we may not even know > about > > (because some third party writes them and never publishes them). > > > > But I begin to agree that we, the community, as a whole have very > different > > needs. I have gotten the impression that it is probably a good idea > to stop > > the current effort and re-start it with a requirements definition. I > have > > tried to digest the discussions on config format we had over the > year, but > > sometimes it looks like the only consensus we have is that the > current format > > is ugly and hard to use. The solutions are very wide-ranging. I have > even > > briefly looked at syslog-ng, and seen a lot of the pain again that > makes me > > dislike that format (but I'll probably still have a closer look and > will try > > to write up my detailed position why I do not find buying into this > format is > > a good idea). > > > > All in all, I think the best way to re-start our thinking about the > config > > format is to set up a web site where we gather user feedback on > > > > a) what problems they have with the config format > > (not what they just dislike, but real problems, an example > > From myself: it is nearly impossible to get the sequence right > > To bind inputs to the right rulesets AND use ruleset inclusion) > > b) which alternatives they see > > > > With all this being on a web site, it may be possible to craft a > better > > decision in 6 to 9 month, assuming we were able to gain sufficient > feedback > > during that time. > > > > An alternative would be to create a config parser interface, so that > > everybody could code up his favorite config language. However, this > seems to > > be impractical, as many of the ideas floating around (Lua, syslog-ng > style) > > require not just different config parsers, but a different rsyslog > processing > > core as well. Obviously a complete rewrite in the case of Lua, less > for > > syslog-ng, but still considerate. For the syslog-ng style we would > need to > > create named filters, something that I really find questionable. > Also, we > > would need to add an interim layer between inputs and rulesets, > something > > that eats performance. In any case, this are not config-parser only > changes. > > > > Of course, I could just pick one of the alternatives. However, it > doesn't > > make sense to invest a couple of month to do the config system > "right", if we > > know that a lot of folks will still be unhappy after we have done > this. > > one thing that's really good about the current rsyslog config is that > it > makes doing simple things simple, especially for people used to classic > syslog. > > as you say, we need to say what the problems there are with the > existing > config format and look at how to solve those. We don't necessarily need > to > change everything. > > weaknesses that I know of > > inability to easily/clearly define if-then-else > > inability to easily/clearly define/use rulesets > > inability to easily have multiple conditions that go to the same > destination (this can be implemented via rulesets, see above) > > unclear scope rules for config options > > inability to easily/clearly define per-input rules/filters (this is > part > of the scope problem above) > > > I don't think that this requires an entirely new config language. I > think > that almost everything can be solved with a couple simple changes to > the > config language (although as we found when I proposed this on June 25 > there are more drastic changes under the covers to > check/correct/document > what gets changed when a config option is processed) > > > Ignoring for the moment the problem of changing how the config options > are > processed (and the fact that you would need to know what data > structures > are managed/created/modified) what does the following proposal _not_ > do? > > (pasted in from the mail on June 25 since that's now quite a ways back > in > the archives ;-) > > > > I would propose the following (more or less in order of difficulty) > > introduce scoping > > whenever you see a "{" in the config file, save the current config > options to a stack. when you see a "}" pop the config options from the > stack (undoing any changes in between) introduce statement blocks > change the parser so that wherever it currently allows one action > make > it accept a {} block of actions (treat them as if they were multiple > actions with & as the selector) > > introduce named actions > > something like sub NAME to define and use NAME to use > > introduce if-then-else > > internally you could convert it to > > ruleset { > if condition { > block > discard} > { block } } > > introduct the ability to implcitly define a ruleset > > if an action is a condition (i.e. nested configutations) then > implicitly > create a new ruleset to resolve the nesting. > > > with these capabilities available I think that this will allow for > straightforward config files representing very complex configurations > with > very little change internally to rsyslog. > > I suspect that the result is going to have some bottlenecks in complex > configurations due to all the different rulesets and the passing of > messages between them, but once the capability is in place in the > config > file the implementation under the covers could change later to be > better > optimized. > > as far as the rsyslog config being hard to understand, I think there > are > two conditions here. > > 1. very simple configs where the fact that rsyslog can use a > traditional > syslog config file (with a header on it that seldom needs to change) is > a > huge advantage > > 2. complex configs where the inability to define scope and nest things > is > a major problem and makes the resulting config hard to write. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 09:50:55 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 00:50:55 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were (and > are) mainly based on the "under the cover" changes. Other than that, I think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. But it > would definitely work. I just have to admit it does not fit my *personal* > taste because it carries a lot of implicit scoping as well (like what exactly > is meant to be scoped by the {} -- an action, or an input, or a ruleset...). > But I think the semantics of this format are close to any other config format > that fits rsyslog. So I think it is probably worth giving it a try, so that > we make at least some progress. The only thing I really would like to change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. sure, I suggested {} in part from habit as they are used to defien blocks in several languages while () tends to be used for parameters to a function, but this is a cosmetic change (and easy to tweak once a proof-of-concept parser is available) > One thing though, that is on my feature list is that I would like to use a > more standard parser, that means one that can becreated with lex and Bison. > While the hand-crafted parser is fine, it always is more work to extend and > enhance it. As the parser is no critical component, I'd prefer to use the > simpler approach. However, I need to check if I can find a suitable grammar > for this proposal. This also works on the assumption. I don't see this as a problem. It's work to define a parser, but I don't think that the current grammer is significantly harder to put into a lex/bison parser than any other (the exception being the implicit scoping rules) > I'd also just concentrate on actions for now. So to double-check a fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html looks sane to me. one question, does the comment really mean what it sounds like on this line? $ActionQueueType LinkedList # use asynchronous processing This makes it sound like you don't do async processing if you use the default queue type. I didn't think that that was the case. > I will probably also begin to look at the internal changes. As it looks, we > need to make them in any case. So it doesn't hurt to start with them, even > though there initially will be no external (user) visibility that they are > made. I agree, the changes that I think are going to be needed are as much documentation as they are functional changes. Makeing sure that we know what variables are changed by each config line that's possible, and making it so that these changes are done in a way that they can be swapped out for a different set of values as scope changes happen. David Lang > But at first, I'll start looking at how this may be processed by a standard > flex/bison parser. From the work I already did, I know this is not easy, but > could probably work. > > Feedback appreciated. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, July 13, 2010 7:30 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >> >>> To add some of the less obvious things: support for multiple >> listeners going >>> to different outputs, in an easy to use way. Support for explicitely >>> specified concurrency (or serialization) for high-speed environments, >> support >>> for different queues, and tying of different queues to different >> object >>> classes (inputs, message processors, actions). Flexibility to support >>> configuration for even unexpected plugins that we may not even know >> about >>> (because some third party writes them and never publishes them). >>> >>> But I begin to agree that we, the community, as a whole have very >> different >>> needs. I have gotten the impression that it is probably a good idea >> to stop >>> the current effort and re-start it with a requirements definition. I >> have >>> tried to digest the discussions on config format we had over the >> year, but >>> sometimes it looks like the only consensus we have is that the >> current format >>> is ugly and hard to use. The solutions are very wide-ranging. I have >> even >>> briefly looked at syslog-ng, and seen a lot of the pain again that >> makes me >>> dislike that format (but I'll probably still have a closer look and >> will try >>> to write up my detailed position why I do not find buying into this >> format is >>> a good idea). >>> >>> All in all, I think the best way to re-start our thinking about the >> config >>> format is to set up a web site where we gather user feedback on >>> >>> a) what problems they have with the config format >>> (not what they just dislike, but real problems, an example >>> From myself: it is nearly impossible to get the sequence right >>> To bind inputs to the right rulesets AND use ruleset inclusion) >>> b) which alternatives they see >>> >>> With all this being on a web site, it may be possible to craft a >> better >>> decision in 6 to 9 month, assuming we were able to gain sufficient >> feedback >>> during that time. >>> >>> An alternative would be to create a config parser interface, so that >>> everybody could code up his favorite config language. However, this >> seems to >>> be impractical, as many of the ideas floating around (Lua, syslog-ng >> style) >>> require not just different config parsers, but a different rsyslog >> processing >>> core as well. Obviously a complete rewrite in the case of Lua, less >> for >>> syslog-ng, but still considerate. For the syslog-ng style we would >> need to >>> create named filters, something that I really find questionable. >> Also, we >>> would need to add an interim layer between inputs and rulesets, >> something >>> that eats performance. In any case, this are not config-parser only >> changes. >>> >>> Of course, I could just pick one of the alternatives. However, it >> doesn't >>> make sense to invest a couple of month to do the config system >> "right", if we >>> know that a lot of folks will still be unhappy after we have done >> this. >> >> one thing that's really good about the current rsyslog config is that >> it >> makes doing simple things simple, especially for people used to classic >> syslog. >> >> as you say, we need to say what the problems there are with the >> existing >> config format and look at how to solve those. We don't necessarily need >> to >> change everything. >> >> weaknesses that I know of >> >> inability to easily/clearly define if-then-else >> >> inability to easily/clearly define/use rulesets >> >> inability to easily have multiple conditions that go to the same >> destination (this can be implemented via rulesets, see above) >> >> unclear scope rules for config options >> >> inability to easily/clearly define per-input rules/filters (this is >> part >> of the scope problem above) >> >> >> I don't think that this requires an entirely new config language. I >> think >> that almost everything can be solved with a couple simple changes to >> the >> config language (although as we found when I proposed this on June 25 >> there are more drastic changes under the covers to >> check/correct/document >> what gets changed when a config option is processed) >> >> >> Ignoring for the moment the problem of changing how the config options >> are >> processed (and the fact that you would need to know what data >> structures >> are managed/created/modified) what does the following proposal _not_ >> do? >> >> (pasted in from the mail on June 25 since that's now quite a ways back >> in >> the archives ;-) >> >> >> >> I would propose the following (more or less in order of difficulty) >> >> introduce scoping >> >> whenever you see a "{" in the config file, save the current config >> options to a stack. when you see a "}" pop the config options from the >> stack (undoing any changes in between) introduce statement blocks >> change the parser so that wherever it currently allows one action >> make >> it accept a {} block of actions (treat them as if they were multiple >> actions with & as the selector) >> >> introduce named actions >> >> something like sub NAME to define and use NAME to use >> >> introduce if-then-else >> >> internally you could convert it to >> >> ruleset { >> if condition { >> block >> discard} >> { block } } >> >> introduct the ability to implcitly define a ruleset >> >> if an action is a condition (i.e. nested configutations) then >> implicitly >> create a new ruleset to resolve the nesting. >> >> >> with these capabilities available I think that this will allow for >> straightforward config files representing very complex configurations >> with >> very little change internally to rsyslog. >> >> I suspect that the result is going to have some bottlenecks in complex >> configurations due to all the different rulesets and the passing of >> messages between them, but once the capability is in place in the >> config >> file the implementation under the covers could change later to be >> better >> optimized. >> >> as far as the rsyslog config being hard to understand, I think there >> are >> two conditions here. >> >> 1. very simple configs where the fact that rsyslog can use a >> traditional >> syslog config file (with a header on it that seldom needs to change) is >> a >> huge advantage >> >> 2. complex configs where the inability to define scope and nest things >> is >> a major problem and makes the resulting config hard to write. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 09:53:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:53:35 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> After writing this, it just hit me that we could stay within the current config notation by introducing $begin $name $end Constructs and don't change anything at the config language at all. The sample below could then be: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files $Begin action $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; $End action ============================================================== This would probably be possible to implement within the constraints of the current config parser. We could also add a directive $StrictScoping on to instruct rsyslog to disallow and $Action directives outside of scoped blocks (this could be good to guard against accidential global directives). That still requires reworking of the internals, but would not need a new (real) grammar, so it would be considerable less work. I still need to see how it would work with more complex configs, but assuming we have things like $Begin Ruleset $Begin Rule $Begin Input I think the same paradigm could probably be used for everything (and that than would eliminate the need for a new grammar). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 15, 2010 9:42 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were > (and > are) mainly based on the "under the cover" changes. Other than that, I > think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. > But it > would definitely work. I just have to admit it does not fit my > *personal* > taste because it carries a lot of implicit scoping as well (like what > exactly > is meant to be scoped by the {} -- an action, or an input, or a > ruleset...). > But I think the semantics of this format are close to any other config > format > that fits rsyslog. So I think it is probably worth giving it a try, so > that > we make at least some progress. The only thing I really would like to > change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. > > One thing though, that is on my feature list is that I would like to > use a > more standard parser, that means one that can becreated with lex and > Bison. > While the hand-crafted parser is fine, it always is more work to extend > and > enhance it. As the parser is no critical component, I'd prefer to use > the > simpler approach. However, I need to check if I can find a suitable > grammar > for this proposal. This also works on the assumption. > > I'd also just concentrate on actions for now. So to double-check a > fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > > I will probably also begin to look at the internal changes. As it > looks, we > need to make them in any case. So it doesn't hurt to start with them, > even > though there initially will be no external (user) visibility that they > are > made. > > But at first, I'll start looking at how this may be processed by a > standard > flex/bison parser. From the work I already did, I know this is not > easy, but > could probably work. > > Feedback appreciated. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > Sent: Tuesday, July 13, 2010 7:30 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] NEW rsyslog.conf format > > > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > > > To add some of the less obvious things: support for multiple > > listeners going > > > to different outputs, in an easy to use way. Support for > explicitely > > > specified concurrency (or serialization) for high-speed > environments, > > support > > > for different queues, and tying of different queues to different > > object > > > classes (inputs, message processors, actions). Flexibility to > support > > > configuration for even unexpected plugins that we may not even know > > about > > > (because some third party writes them and never publishes them). > > > > > > But I begin to agree that we, the community, as a whole have very > > different > > > needs. I have gotten the impression that it is probably a good idea > > to stop > > > the current effort and re-start it with a requirements definition. > I > > have > > > tried to digest the discussions on config format we had over the > > year, but > > > sometimes it looks like the only consensus we have is that the > > current format > > > is ugly and hard to use. The solutions are very wide-ranging. I > have > > even > > > briefly looked at syslog-ng, and seen a lot of the pain again that > > makes me > > > dislike that format (but I'll probably still have a closer look and > > will try > > > to write up my detailed position why I do not find buying into this > > format is > > > a good idea). > > > > > > All in all, I think the best way to re-start our thinking about the > > config > > > format is to set up a web site where we gather user feedback on > > > > > > a) what problems they have with the config format > > > (not what they just dislike, but real problems, an example > > > From myself: it is nearly impossible to get the sequence right > > > To bind inputs to the right rulesets AND use ruleset inclusion) > > > b) which alternatives they see > > > > > > With all this being on a web site, it may be possible to craft a > > better > > > decision in 6 to 9 month, assuming we were able to gain sufficient > > feedback > > > during that time. > > > > > > An alternative would be to create a config parser interface, so > that > > > everybody could code up his favorite config language. However, this > > seems to > > > be impractical, as many of the ideas floating around (Lua, syslog- > ng > > style) > > > require not just different config parsers, but a different rsyslog > > processing > > > core as well. Obviously a complete rewrite in the case of Lua, less > > for > > > syslog-ng, but still considerate. For the syslog-ng style we would > > need to > > > create named filters, something that I really find questionable. > > Also, we > > > would need to add an interim layer between inputs and rulesets, > > something > > > that eats performance. In any case, this are not config-parser only > > changes. > > > > > > Of course, I could just pick one of the alternatives. However, it > > doesn't > > > make sense to invest a couple of month to do the config system > > "right", if we > > > know that a lot of folks will still be unhappy after we have done > > this. > > > > one thing that's really good about the current rsyslog config is that > > it > > makes doing simple things simple, especially for people used to > classic > > syslog. > > > > as you say, we need to say what the problems there are with the > > existing > > config format and look at how to solve those. We don't necessarily > need > > to > > change everything. > > > > weaknesses that I know of > > > > inability to easily/clearly define if-then-else > > > > inability to easily/clearly define/use rulesets > > > > inability to easily have multiple conditions that go to the same > > destination (this can be implemented via rulesets, see above) > > > > unclear scope rules for config options > > > > inability to easily/clearly define per-input rules/filters (this is > > part > > of the scope problem above) > > > > > > I don't think that this requires an entirely new config language. I > > think > > that almost everything can be solved with a couple simple changes to > > the > > config language (although as we found when I proposed this on June 25 > > there are more drastic changes under the covers to > > check/correct/document > > what gets changed when a config option is processed) > > > > > > Ignoring for the moment the problem of changing how the config > options > > are > > processed (and the fact that you would need to know what data > > structures > > are managed/created/modified) what does the following proposal _not_ > > do? > > > > (pasted in from the mail on June 25 since that's now quite a ways > back > > in > > the archives ;-) > > > > > > > > I would propose the following (more or less in order of difficulty) > > > > introduce scoping > > > > whenever you see a "{" in the config file, save the current config > > options to a stack. when you see a "}" pop the config options from > the > > stack (undoing any changes in between) introduce statement blocks > > change the parser so that wherever it currently allows one action > > make > > it accept a {} block of actions (treat them as if they were multiple > > actions with & as the selector) > > > > introduce named actions > > > > something like sub NAME to define and use NAME to use > > > > introduce if-then-else > > > > internally you could convert it to > > > > ruleset { > > if condition { > > block > > discard} > > { block } } > > > > introduct the ability to implcitly define a ruleset > > > > if an action is a condition (i.e. nested configutations) then > > implicitly > > create a new ruleset to resolve the nesting. > > > > > > with these capabilities available I think that this will allow for > > straightforward config files representing very complex configurations > > with > > very little change internally to rsyslog. > > > > I suspect that the result is going to have some bottlenecks in > complex > > configurations due to all the different rulesets and the passing of > > messages between them, but once the capability is in place in the > > config > > file the implementation under the covers could change later to be > > better > > optimized. > > > > as far as the rsyslog config being hard to understand, I think there > > are > > two conditions here. > > > > 1. very simple configs where the fact that rsyslog can use a > > traditional > > syslog config file (with a header on it that seldom needs to change) > is > > a > > huge advantage > > > > 2. complex configs where the inability to define scope and nest > things > > is > > a major problem and makes the resulting config hard to write. > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 10:00:42 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:00:42 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > After writing this, it just hit me that we could stay within the current > config notation by introducing > > $begin > $end I have no problem with this. I view is as symatically eqivalent to the {}(), just more characters to type ;-) > $name I had even suggested NAME block and USE syntaxes the only question is if we need to explicitly state the type or if it's good enough to be able to just nest the scope. I think you can get away with just nesting the scope, but I could be wrong and if so defining the type is a fairly cheap way of working around the issue. > The sample below could then be: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > $Begin action > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > $End action > ============================================================== > > This would probably be possible to implement within the constraints of the > current config parser. We could also add a directive > > $StrictScoping on > > to instruct rsyslog to disallow and $Action directives outside of > scoped blocks (this could be good to guard against accidential global > directives). probably a good idea. > That still requires reworking of the internals, but would not need a new > (real) grammar, so it would be considerable less work. I still need to see > how it would work with more complex configs, but assuming we have things like > > $Begin Ruleset > $Begin Rule > $Begin Input > > I think the same paradigm could probably be used for everything (and that > than would eliminate the need for a new grammar). sounds good. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Thursday, July 15, 2010 9:42 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Hi David, >> >> thanks for the well-crafted mail. My concerns for this proposal were >> (and >> are) mainly based on the "under the cover" changes. Other than that, I >> think >> you are right, except that it boils down to personal taste. >> >> Let me ignore the internal changes for now. >> >> Throwing in "{}" creates a very compact, ultra-brief config language. >> But it >> would definitely work. I just have to admit it does not fit my >> *personal* >> taste because it carries a lot of implicit scoping as well (like what >> exactly >> is meant to be scoped by the {} -- an action, or an input, or a >> ruleset...). >> But I think the semantics of this format are close to any other config >> format >> that fits rsyslog. So I think it is probably worth giving it a try, so >> that >> we make at least some progress. The only thing I really would like to >> change >> is to use "()" instead of "{}" because I would like to reserve "{}" for >> future use, where it may fit the user's expectation better than simple >> parenthesis. But I guess that's not really a problem. >> >> One thing though, that is on my feature list is that I would like to >> use a >> more standard parser, that means one that can becreated with lex and >> Bison. >> While the hand-crafted parser is fine, it always is more work to extend >> and >> enhance it. As the parser is no critical component, I'd prefer to use >> the >> simpler approach. However, I need to check if I can find a suitable >> grammar >> for this proposal. This also works on the assumption. >> >> I'd also just concentrate on actions for now. So to double-check a >> fairly >> simple config in that format would look as follows: >> >> ============================================================== >> $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) >> $ModLoad imudp # network reception >> $UDPServerRun 514 # start a udp server at port 514 >> $ModLoad imuxsock # local message reception >> >> $WorkDirectory /rsyslog/work # default location for work (spool) files >> >> ( >> $ActionQueueType LinkedList # use asynchronous processing >> $ActionQueueFileName dbq # set file name, also enables disk mode >> $ActionResumeRetryCount -1 # infinite retries on insert failure >> # for PostgreSQL replace :ommysql: by :ompgsql: below: >> *.* :ommysql:hostname,dbname,userid,password; >> ) >> ============================================================== >> >> This is based on the second example in >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html >> >> I will probably also begin to look at the internal changes. As it >> looks, we >> need to make them in any case. So it doesn't hurt to start with them, >> even >> though there initially will be no external (user) visibility that they >> are >> made. >> >> But at first, I'll start looking at how this may be processed by a >> standard >> flex/bison parser. From the work I already did, I know this is not >> easy, but >> could probably work. >> >> Feedback appreciated. >> >> Rainer >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>> Sent: Tuesday, July 13, 2010 7:30 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >>> >>>> To add some of the less obvious things: support for multiple >>> listeners going >>>> to different outputs, in an easy to use way. Support for >> explicitely >>>> specified concurrency (or serialization) for high-speed >> environments, >>> support >>>> for different queues, and tying of different queues to different >>> object >>>> classes (inputs, message processors, actions). Flexibility to >> support >>>> configuration for even unexpected plugins that we may not even know >>> about >>>> (because some third party writes them and never publishes them). >>>> >>>> But I begin to agree that we, the community, as a whole have very >>> different >>>> needs. I have gotten the impression that it is probably a good idea >>> to stop >>>> the current effort and re-start it with a requirements definition. >> I >>> have >>>> tried to digest the discussions on config format we had over the >>> year, but >>>> sometimes it looks like the only consensus we have is that the >>> current format >>>> is ugly and hard to use. The solutions are very wide-ranging. I >> have >>> even >>>> briefly looked at syslog-ng, and seen a lot of the pain again that >>> makes me >>>> dislike that format (but I'll probably still have a closer look and >>> will try >>>> to write up my detailed position why I do not find buying into this >>> format is >>>> a good idea). >>>> >>>> All in all, I think the best way to re-start our thinking about the >>> config >>>> format is to set up a web site where we gather user feedback on >>>> >>>> a) what problems they have with the config format >>>> (not what they just dislike, but real problems, an example >>>> From myself: it is nearly impossible to get the sequence right >>>> To bind inputs to the right rulesets AND use ruleset inclusion) >>>> b) which alternatives they see >>>> >>>> With all this being on a web site, it may be possible to craft a >>> better >>>> decision in 6 to 9 month, assuming we were able to gain sufficient >>> feedback >>>> during that time. >>>> >>>> An alternative would be to create a config parser interface, so >> that >>>> everybody could code up his favorite config language. However, this >>> seems to >>>> be impractical, as many of the ideas floating around (Lua, syslog- >> ng >>> style) >>>> require not just different config parsers, but a different rsyslog >>> processing >>>> core as well. Obviously a complete rewrite in the case of Lua, less >>> for >>>> syslog-ng, but still considerate. For the syslog-ng style we would >>> need to >>>> create named filters, something that I really find questionable. >>> Also, we >>>> would need to add an interim layer between inputs and rulesets, >>> something >>>> that eats performance. In any case, this are not config-parser only >>> changes. >>>> >>>> Of course, I could just pick one of the alternatives. However, it >>> doesn't >>>> make sense to invest a couple of month to do the config system >>> "right", if we >>>> know that a lot of folks will still be unhappy after we have done >>> this. >>> >>> one thing that's really good about the current rsyslog config is that >>> it >>> makes doing simple things simple, especially for people used to >> classic >>> syslog. >>> >>> as you say, we need to say what the problems there are with the >>> existing >>> config format and look at how to solve those. We don't necessarily >> need >>> to >>> change everything. >>> >>> weaknesses that I know of >>> >>> inability to easily/clearly define if-then-else >>> >>> inability to easily/clearly define/use rulesets >>> >>> inability to easily have multiple conditions that go to the same >>> destination (this can be implemented via rulesets, see above) >>> >>> unclear scope rules for config options >>> >>> inability to easily/clearly define per-input rules/filters (this is >>> part >>> of the scope problem above) >>> >>> >>> I don't think that this requires an entirely new config language. I >>> think >>> that almost everything can be solved with a couple simple changes to >>> the >>> config language (although as we found when I proposed this on June 25 >>> there are more drastic changes under the covers to >>> check/correct/document >>> what gets changed when a config option is processed) >>> >>> >>> Ignoring for the moment the problem of changing how the config >> options >>> are >>> processed (and the fact that you would need to know what data >>> structures >>> are managed/created/modified) what does the following proposal _not_ >>> do? >>> >>> (pasted in from the mail on June 25 since that's now quite a ways >> back >>> in >>> the archives ;-) >>> >>> >>> >>> I would propose the following (more or less in order of difficulty) >>> >>> introduce scoping >>> >>> whenever you see a "{" in the config file, save the current config >>> options to a stack. when you see a "}" pop the config options from >> the >>> stack (undoing any changes in between) introduce statement blocks >>> change the parser so that wherever it currently allows one action >>> make >>> it accept a {} block of actions (treat them as if they were multiple >>> actions with & as the selector) >>> >>> introduce named actions >>> >>> something like sub NAME to define and use NAME to use >>> >>> introduce if-then-else >>> >>> internally you could convert it to >>> >>> ruleset { >>> if condition { >>> block >>> discard} >>> { block } } >>> >>> introduct the ability to implcitly define a ruleset >>> >>> if an action is a condition (i.e. nested configutations) then >>> implicitly >>> create a new ruleset to resolve the nesting. >>> >>> >>> with these capabilities available I think that this will allow for >>> straightforward config files representing very complex configurations >>> with >>> very little change internally to rsyslog. >>> >>> I suspect that the result is going to have some bottlenecks in >> complex >>> configurations due to all the different rulesets and the passing of >>> messages between them, but once the capability is in place in the >>> config >>> file the implementation under the covers could change later to be >>> better >>> optimized. >>> >>> as far as the rsyslog config being hard to understand, I think there >>> are >>> two conditions here. >>> >>> 1. very simple configs where the fact that rsyslog can use a >>> traditional >>> syslog config file (with a header on it that seldom needs to change) >> is >>> a >>> huge advantage >>> >>> 2. complex configs where the inability to define scope and nest >> things >>> is >>> a major problem and makes the resulting config hard to write. >>> >>> David Lang >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 10:08:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:08:58 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB0@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 15, 2010 10:01 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Thu, 15 Jul 2010, Rainer Gerhards wrote: > > > After writing this, it just hit me that we could stay within the > current > > config notation by introducing > > > > $begin > > $end > > I have no problem with this. I view is as symatically eqivalent to the > {}(), just more characters to type ;-) Jupp, but the big difference is that the current parser can handle that. Also, if we really stick with the language, I personally think this is more consistent with the rest of the language (but that's again an issue of personal taste). > > $name > > I had even suggested NAME block and USE syntaxes Ack, didn't mention it explicitely, but definitely kept it on my mind ;) > > the only question is if we need to explicitly state the type or if it's > good enough to be able to just nest the scope. I think you can get away > with just nesting the scope, but I could be wrong and if so defining > the > type is a fairly cheap way of working around the issue. Again a taste issue first: I think it is less confusing for a human to know what exactly the block defines. But there is also a hard argument: if I know it is an action, I can disallow input or global statements inside this block (and vice versa)! So we do not only get the scoping, but also the capability to not permit irrelevant statements within the scope. The only thing I need to change is add a type to each config statement (in the statement table), but this is not much work (given the fact that I need to change some internals in any way to support the scoping). Rainer > > > The sample below could then be: > > > > ============================================================== > > $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > > $ModLoad imudp # network reception > > $UDPServerRun 514 # start a udp server at port 514 > > $ModLoad imuxsock # local message reception > > > > $WorkDirectory /rsyslog/work # default location for work (spool) > files > > > > $Begin action > > $ActionQueueType LinkedList # use asynchronous processing > > $ActionQueueFileName dbq # set file name, also enables disk mode > > $ActionResumeRetryCount -1 # infinite retries on insert failure > > # for PostgreSQL replace :ommysql: by :ompgsql: below: > > *.* :ommysql:hostname,dbname,userid,password; > > $End action > > ============================================================== > > > > This would probably be possible to implement within the constraints > of the > > current config parser. We could also add a directive > > > > $StrictScoping on > > > > to instruct rsyslog to disallow and $Action directives > outside of > > scoped blocks (this could be good to guard against accidential global > > directives). > > probably a good idea. > > > That still requires reworking of the internals, but would not need a > new > > (real) grammar, so it would be considerable less work. I still need > to see > > how it would work with more complex configs, but assuming we have > things like > > > > $Begin Ruleset > > $Begin Rule > > $Begin Input > > > > I think the same paradigm could probably be used for everything (and > that > > than would eliminate the need for a new grammar). > > sounds good. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > >> Sent: Thursday, July 15, 2010 9:42 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> Hi David, > >> > >> thanks for the well-crafted mail. My concerns for this proposal were > >> (and > >> are) mainly based on the "under the cover" changes. Other than that, > I > >> think > >> you are right, except that it boils down to personal taste. > >> > >> Let me ignore the internal changes for now. > >> > >> Throwing in "{}" creates a very compact, ultra-brief config > language. > >> But it > >> would definitely work. I just have to admit it does not fit my > >> *personal* > >> taste because it carries a lot of implicit scoping as well (like > what > >> exactly > >> is meant to be scoped by the {} -- an action, or an input, or a > >> ruleset...). > >> But I think the semantics of this format are close to any other > config > >> format > >> that fits rsyslog. So I think it is probably worth giving it a try, > so > >> that > >> we make at least some progress. The only thing I really would like > to > >> change > >> is to use "()" instead of "{}" because I would like to reserve "{}" > for > >> future use, where it may fit the user's expectation better than > simple > >> parenthesis. But I guess that's not really a problem. > >> > >> One thing though, that is on my feature list is that I would like to > >> use a > >> more standard parser, that means one that can becreated with lex and > >> Bison. > >> While the hand-crafted parser is fine, it always is more work to > extend > >> and > >> enhance it. As the parser is no critical component, I'd prefer to > use > >> the > >> simpler approach. However, I need to check if I can find a suitable > >> grammar > >> for this proposal. This also works on the assumption. > >> > >> I'd also just concentrate on actions for now. So to double-check a > >> fairly > >> simple config in that format would look as follows: > >> > >> ============================================================== > >> $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > >> $ModLoad imudp # network reception > >> $UDPServerRun 514 # start a udp server at port 514 > >> $ModLoad imuxsock # local message reception > >> > >> $WorkDirectory /rsyslog/work # default location for work (spool) > files > >> > >> ( > >> $ActionQueueType LinkedList # use asynchronous processing > >> $ActionQueueFileName dbq # set file name, also enables disk mode > >> $ActionResumeRetryCount -1 # infinite retries on insert failure > >> # for PostgreSQL replace :ommysql: by :ompgsql: below: > >> *.* :ommysql:hostname,dbname,userid,password; > >> ) > >> ============================================================== > >> > >> This is based on the second example in > >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > >> > >> I will probably also begin to look at the internal changes. As it > >> looks, we > >> need to make them in any case. So it doesn't hurt to start with > them, > >> even > >> though there initially will be no external (user) visibility that > they > >> are > >> made. > >> > >> But at first, I'll start looking at how this may be processed by a > >> standard > >> flex/bison parser. From the work I already did, I know this is not > >> easy, but > >> could probably work. > >> > >> Feedback appreciated. > >> > >> Rainer > >> > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >>> Sent: Tuesday, July 13, 2010 7:30 PM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: > >>> > >>>> To add some of the less obvious things: support for multiple > >>> listeners going > >>>> to different outputs, in an easy to use way. Support for > >> explicitely > >>>> specified concurrency (or serialization) for high-speed > >> environments, > >>> support > >>>> for different queues, and tying of different queues to different > >>> object > >>>> classes (inputs, message processors, actions). Flexibility to > >> support > >>>> configuration for even unexpected plugins that we may not even > know > >>> about > >>>> (because some third party writes them and never publishes them). > >>>> > >>>> But I begin to agree that we, the community, as a whole have very > >>> different > >>>> needs. I have gotten the impression that it is probably a good > idea > >>> to stop > >>>> the current effort and re-start it with a requirements definition. > >> I > >>> have > >>>> tried to digest the discussions on config format we had over the > >>> year, but > >>>> sometimes it looks like the only consensus we have is that the > >>> current format > >>>> is ugly and hard to use. The solutions are very wide-ranging. I > >> have > >>> even > >>>> briefly looked at syslog-ng, and seen a lot of the pain again that > >>> makes me > >>>> dislike that format (but I'll probably still have a closer look > and > >>> will try > >>>> to write up my detailed position why I do not find buying into > this > >>> format is > >>>> a good idea). > >>>> > >>>> All in all, I think the best way to re-start our thinking about > the > >>> config > >>>> format is to set up a web site where we gather user feedback on > >>>> > >>>> a) what problems they have with the config format > >>>> (not what they just dislike, but real problems, an example > >>>> From myself: it is nearly impossible to get the sequence right > >>>> To bind inputs to the right rulesets AND use ruleset inclusion) > >>>> b) which alternatives they see > >>>> > >>>> With all this being on a web site, it may be possible to craft a > >>> better > >>>> decision in 6 to 9 month, assuming we were able to gain sufficient > >>> feedback > >>>> during that time. > >>>> > >>>> An alternative would be to create a config parser interface, so > >> that > >>>> everybody could code up his favorite config language. However, > this > >>> seems to > >>>> be impractical, as many of the ideas floating around (Lua, syslog- > >> ng > >>> style) > >>>> require not just different config parsers, but a different rsyslog > >>> processing > >>>> core as well. Obviously a complete rewrite in the case of Lua, > less > >>> for > >>>> syslog-ng, but still considerate. For the syslog-ng style we would > >>> need to > >>>> create named filters, something that I really find questionable. > >>> Also, we > >>>> would need to add an interim layer between inputs and rulesets, > >>> something > >>>> that eats performance. In any case, this are not config-parser > only > >>> changes. > >>>> > >>>> Of course, I could just pick one of the alternatives. However, it > >>> doesn't > >>>> make sense to invest a couple of month to do the config system > >>> "right", if we > >>>> know that a lot of folks will still be unhappy after we have done > >>> this. > >>> > >>> one thing that's really good about the current rsyslog config is > that > >>> it > >>> makes doing simple things simple, especially for people used to > >> classic > >>> syslog. > >>> > >>> as you say, we need to say what the problems there are with the > >>> existing > >>> config format and look at how to solve those. We don't necessarily > >> need > >>> to > >>> change everything. > >>> > >>> weaknesses that I know of > >>> > >>> inability to easily/clearly define if-then-else > >>> > >>> inability to easily/clearly define/use rulesets > >>> > >>> inability to easily have multiple conditions that go to the same > >>> destination (this can be implemented via rulesets, see above) > >>> > >>> unclear scope rules for config options > >>> > >>> inability to easily/clearly define per-input rules/filters (this is > >>> part > >>> of the scope problem above) > >>> > >>> > >>> I don't think that this requires an entirely new config language. I > >>> think > >>> that almost everything can be solved with a couple simple changes > to > >>> the > >>> config language (although as we found when I proposed this on June > 25 > >>> there are more drastic changes under the covers to > >>> check/correct/document > >>> what gets changed when a config option is processed) > >>> > >>> > >>> Ignoring for the moment the problem of changing how the config > >> options > >>> are > >>> processed (and the fact that you would need to know what data > >>> structures > >>> are managed/created/modified) what does the following proposal > _not_ > >>> do? > >>> > >>> (pasted in from the mail on June 25 since that's now quite a ways > >> back > >>> in > >>> the archives ;-) > >>> > >>> > >>> > >>> I would propose the following (more or less in order of difficulty) > >>> > >>> introduce scoping > >>> > >>> whenever you see a "{" in the config file, save the current > config > >>> options to a stack. when you see a "}" pop the config options from > >> the > >>> stack (undoing any changes in between) introduce statement blocks > >>> change the parser so that wherever it currently allows one > action > >>> make > >>> it accept a {} block of actions (treat them as if they were > multiple > >>> actions with & as the selector) > >>> > >>> introduce named actions > >>> > >>> something like sub NAME to define and use NAME to use > >>> > >>> introduce if-then-else > >>> > >>> internally you could convert it to > >>> > >>> ruleset { > >>> if condition { > >>> block > >>> discard} > >>> { block } } > >>> > >>> introduct the ability to implcitly define a ruleset > >>> > >>> if an action is a condition (i.e. nested configutations) then > >>> implicitly > >>> create a new ruleset to resolve the nesting. > >>> > >>> > >>> with these capabilities available I think that this will allow for > >>> straightforward config files representing very complex > configurations > >>> with > >>> very little change internally to rsyslog. > >>> > >>> I suspect that the result is going to have some bottlenecks in > >> complex > >>> configurations due to all the different rulesets and the passing of > >>> messages between them, but once the capability is in place in the > >>> config > >>> file the implementation under the covers could change later to be > >>> better > >>> optimized. > >>> > >>> as far as the rsyslog config being hard to understand, I think > there > >>> are > >>> two conditions here. > >>> > >>> 1. very simple configs where the fact that rsyslog can use a > >>> traditional > >>> syslog config file (with a header on it that seldom needs to > change) > >> is > >>> a > >>> huge advantage > >>> > >>> 2. complex configs where the inability to define scope and nest > >> things > >>> is > >>> a major problem and makes the resulting config hard to write. > >>> > >>> David Lang > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 15 10:14:19 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:14:19 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> While I think we alread settle fort he other alternative, there is one point I'D like to take (as it may be important for future discussions): > > One thing though, that is on my feature list is that I would like to > use a > > more standard parser, that means one that can becreated with lex and > Bison. > > While the hand-crafted parser is fine, it always is more work to > extend and > > enhance it. As the parser is no critical component, I'd prefer to use > the > > simpler approach. However, I need to check if I can find a suitable > grammar > > for this proposal. This also works on the assumption. > > I don't see this as a problem. It's work to define a parser, but I > don't > think that the current grammer is significantly harder to put into a > lex/bison parser than any other (the exception being the implicit > scoping > rules) A problem from the grammer PoV is that a traditional action line has no structure at all. It is anything from the first non-whitespace after the filter to the end of line. So here we need LF as a delimiter, while in all other cases, NL should be consider as whitespace and be discarded. You really can't specify this with a decent contextfree grammar, but Flex's substates most probably provide sufficient power to cover these "two languages in one" approach. But as I said ... this seem no longer be relevant to the current discussion, as we will probably stick with the current config system and its parser. Rainer From david at lang.hm Thu Jul 15 10:37:49 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:37:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > While I think we alread settle fort he other alternative, there is one point > I'D like to take (as it may be important for future discussions): > >>> One thing though, that is on my feature list is that I would like to >> use a >>> more standard parser, that means one that can becreated with lex and >> Bison. >>> While the hand-crafted parser is fine, it always is more work to >> extend and >>> enhance it. As the parser is no critical component, I'd prefer to use >> the >>> simpler approach. However, I need to check if I can find a suitable >> grammar >>> for this proposal. This also works on the assumption. >> >> I don't see this as a problem. It's work to define a parser, but I >> don't >> think that the current grammer is significantly harder to put into a >> lex/bison parser than any other (the exception being the implicit >> scoping >> rules) > > A problem from the grammer PoV is that a traditional action line has no > structure at all. It is anything from the first non-whitespace after the > filter to the end of line. So here we need LF as a delimiter, while in all > other cases, NL should be consider as whitespace and be discarded. interesting, I'm not sure that anyone else realized that a config option could be split over multiple lines. I'd lay good odds that you could say that NL/LF is the end of a configuration option in an upgrade without anyone noticing the change. > You really > can't specify this with a decent contextfree grammar, but Flex's substates > most probably provide sufficient power to cover these "two languages in one" > approach. > > But as I said ... this seem no longer be relevant to the current discussion, > as we will probably stick with the current config system and its parser. In the long run it's probably a useful thing to switch from the current parser to a lex/bison based parser. it makes it easier to be sure that you are sticking with the defined config language, and should make it easier to add new options, but it's not a requrement. David Lang From mrdemeanour at jackpot.uk.net Thu Jul 15 11:13:15 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Thu, 15 Jul 2010 10:13:15 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: <4C3ED12B.4080704@jackpot.uk.net> david at lang.hm wrote: > > interesting, I'm not sure that anyone else realized that a config > option could be split over multiple lines. I've banged my head on this (end-of-line comments). I believe the comments problem has been worked around now, but I still make sure that I don't try to use end-of-line comments anywhere in my configs, just in case. -- Jack. From joel.merrick at gmail.com Thu Jul 15 13:18:59 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 15 Jul 2010 12:18:59 +0100 Subject: [rsyslog] MySQL custom filters? Message-ID: Hi list, I'm trying to build a service to enable the quick searching of mail logs, for our support team to use. We get quite a lot of log generation (about 2G of mysql data a day) Searching these becomes really inefficient after a while, even though there's extra keys and indexes in the db. I'd like to try and parse the syslog event using rsyslog and get the message ID out of the payload and add it as an indexed field, which should speed up queries (so we can stitch together a full email transaction) Is this something rsyslog can do? I'm currently using the default db schema and loganalyzer 3.0.1 If not, no big deal, will have to write a custom parser and use a pipe to take the syslogs from rsyslog (perhaps?) I've also thought of multiplexing the logs to ramdisk and physical disk, although that throws up another set of problems. Cheers Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 07:43:31 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 22:43:31 -0700 (PDT) Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Thu, 15 Jul 2010, Joel Merrick wrote: > Hi list, > > I'm trying to build a service to enable the quick searching of mail > logs, for our support team to use. We get quite a lot of log > generation (about 2G of mysql data a day) > > Searching these becomes really inefficient after a while, even though > there's extra keys and indexes in the db. > > I'd like to try and parse the syslog event using rsyslog and get the > message ID out of the payload and add it as an indexed field, which > should speed up queries (so we can stitch together a full email > transaction) this shouldn't be _too_ hard, depending on where the message ID is in the messages you are logging just create your own template that writes the message ID as a separate field. David Lang > Is this something rsyslog can do? I'm currently using the default db > schema and loganalyzer 3.0.1 > > If not, no big deal, will have to write a custom parser and use a pipe > to take the syslogs from rsyslog (perhaps?) > > I've also thought of multiplexing the logs to ramdisk and physical > disk, although that throws up another set of problems. > > Cheers > Joel > > From rgerhards at hq.adiscon.com Fri Jul 16 08:53:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 08:53:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Thursday, July 15, 2010 11:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > david at lang.hm wrote: > > > > interesting, I'm not sure that anyone else realized that a config > > option could be split over multiple lines. > > I've banged my head on this (end-of-line comments). I believe the > comments problem has been worked around now, but I still make sure that > I don't try to use end-of-line comments anywhere in my configs, just in > case. That's an (one?) anomaly of the current parser. Thinking that it would be replaced in the medium to long term, I did not care about it. Looks like I now need to have a look ;) Rainer From rgerhards at hq.adiscon.com Fri Jul 16 09:11:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 09:11:20 +0200 Subject: [rsyslog] MySQL custom filters? References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB8@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 16, 2010 7:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] MySQL custom filters? > > On Thu, 15 Jul 2010, Joel Merrick wrote: > > > Hi list, > > > > I'm trying to build a service to enable the quick searching of mail > > logs, for our support team to use. We get quite a lot of log > > generation (about 2G of mysql data a day) > > > > Searching these becomes really inefficient after a while, even though > > there's extra keys and indexes in the db. > > > > I'd like to try and parse the syslog event using rsyslog and get the > > message ID out of the payload and add it as an indexed field, which > > should speed up queries (so we can stitch together a full email > > transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in > the > messages you are logging > > just create your own template that writes the message ID as a separate > field. If that's fast enough, you probably use regular expressions inside templates. Depending on the message content, you can possibly use field-based extraction (which is faster). If all that is too slow, you can write (or have written) a custom message formatter, where you have full control and power over what is done. So in short: ample of possibilities. :) Rainer From timo.bumke at bayerhealthcare.com Fri Jul 16 09:24:35 2010 From: timo.bumke at bayerhealthcare.com (timo.bumke at bayerhealthcare.com) Date: Fri, 16 Jul 2010 09:24:35 +0200 Subject: [rsyslog] Omoracle ORA-01461 Message-ID: Hello list, anybody using omoracle successfully and can help me with my problem? I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: create table test (hostname varchar2(100), message varchar2(4000)); I found out that if I am only writing one syslog property to oracle it succeeds. My failing configuration: $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt Freundliche Gr??e / Best regards Timo Bumke _________________________________________ B&R Unternehmensberatungs- und Vertriebsgesellschaft mbH Amsterdamer Str.230 50735 K?ln, Deutschland Vertragspartner der Bayer Schering Pharma AG Im Auftrag der Bayer Schering Pharma AG Geb?ude A001, EG, Raum 012 59192 Bergkamen, Deutschland Phone: +49 2307 65-3803 Email: timo.bumke at bayerhealthcare.com Web: http://www.bayerscheringpharma.de From mrdemeanour at jackpot.uk.net Fri Jul 16 11:32:34 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Fri, 16 Jul 2010 10:32:34 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> Message-ID: <4C402732.5030806@jackpot.uk.net> Rainer Gerhards wrote: >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> david at lang.hm wrote: >>> interesting, I'm not sure that anyone else realized that a config >>> option could be split over multiple lines. >> I've banged my head on this (end-of-line comments). I believe the >> comments problem has been worked around now, but I still make sure >> that I don't try to use end-of-line comments anywhere in my >> configs, just in case. > > That's an (one?) anomaly of the current parser. Thinking that it > would be replaced in the medium to long term, I did not care about > it. Looks like I now need to have a look ;) No big deal for me *now*, but it caused pain when I first ran into it. Anyway, I thought you'd addressed this - about a year ago, maybe? -- Jack. From rgerhards at hq.adiscon.com Fri Jul 16 11:50:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 11:50:16 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Friday, July 16, 2010 11:33 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Rainer Gerhards wrote: > >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> david at lang.hm wrote: > >>> interesting, I'm not sure that anyone else realized that a config > >>> option could be split over multiple lines. > >> I've banged my head on this (end-of-line comments). I believe the > >> comments problem has been worked around now, but I still make sure > >> that I don't try to use end-of-line comments anywhere in my > >> configs, just in case. > > > > That's an (one?) anomaly of the current parser. Thinking that it > > would be replaced in the medium to long term, I did not care about > > it. Looks like I now need to have a look ;) > > No big deal for me *now*, but it caused pain when I first ran into it. > Anyway, I thought you'd addressed this - about a year ago, maybe? I guess just mostly -- at least it boils down with actions themselves, where it is hard to handle due to the missing well-defined structure of the string. Rainer From joel.merrick at gmail.com Fri Jul 16 12:08:15 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Fri, 16 Jul 2010 11:08:15 +0100 Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Fri, Jul 16, 2010 at 6:43 AM, wrote: > On Thu, 15 Jul 2010, Joel Merrick wrote: > >> Hi list, >> >> I'm trying to build a service to enable the quick searching of mail >> logs, for our support team to use. We get quite a lot of log >> generation (about 2G of mysql data a day) >> >> Searching these becomes really inefficient after a while, even though >> there's extra keys and indexes in the db. >> >> I'd like to try and parse the syslog event using rsyslog and get the >> message ID out of the payload and add it as an indexed field, which >> should speed up queries (so we can stitch together a full email >> transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in the > messages you are logging > > just create your own template that writes the message ID as a separate > field. > The position of the message ID's are always pretty consistent but not exactly. I've got a PoC ruby daemon listening on a named pipe and regex'ing out the message ID's already. Shawn's very kindly told me about Solr, so I'm going to give that a whirl today. If I could get away from using the ruby daemon and use rsyslog properly, that'd be good.. however it's working and can easily handle the load The regexp in ruby I'm using is; \w{6}-\w{6}-\w{2} Could this be done for the templates? -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 19:57:18 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 16 Jul 2010 10:57:18 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang From rgerhards at hq.adiscon.com Fri Jul 16 20:08:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 20:08:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format Message-ID: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> In theorie yes, in practice eg inside a password for a db connection. ----- Urspr?ngliche Nachricht ----- Von: david at lang.hm Gesendet: Freitag, 16. Juli 2010 19:57 An: rsyslog-users Betreff: Re: [rsyslog] NEW rsyslog.conf format On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From david at lang.hm Sun Jul 18 00:45:46 2010 From: david at lang.hm (david at lang.hm) Date: Sat, 17 Jul 2010 15:45:46 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: > In theorie yes, in practice eg inside a password for a db connection. how hard would it be to allow quotes around the password? (if this ends up disallowing quotes in the password to the database, that's not too bad a cost) I'm trying to think of if there are some fairly minor changes that could be made that would make it significantly easier for a better parser to be written. changng the config is always a problem, but there are some problems that are much larger than others, and if a minor change would make it much easier to move to a standard parser it may be worth making the breakage in a 5.x or 6.x release (where the new capibilities are introduced so that people can see the advantage of the breakage) David Lang > ----- Urspr?ngliche Nachricht ----- > Von: david at lang.hm > Gesendet: Freitag, 16. Juli 2010 19:57 > An: rsyslog-users > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >>> Sent: Friday, July 16, 2010 11:33 AM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> Rainer Gerhards wrote: >>>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>>> >>>>> david at lang.hm wrote: >>>>>> interesting, I'm not sure that anyone else realized that a config >>>>>> option could be split over multiple lines. >>>>> I've banged my head on this (end-of-line comments). I believe the >>>>> comments problem has been worked around now, but I still make sure >>>>> that I don't try to use end-of-line comments anywhere in my >>>>> configs, just in case. >>>> >>>> That's an (one?) anomaly of the current parser. Thinking that it >>>> would be replaced in the medium to long term, I did not care about >>>> it. Looks like I now need to have a look ;) >>> >>> No big deal for me *now*, but it caused pain when I first ran into it. >>> Anyway, I thought you'd addressed this - about a year ago, maybe? >> >> I guess just mostly -- at least it boils down with actions themselves, where >> it is hard to handle due to the missing well-defined structure of the string. > > is a # outside of quotes ever valid in an action string? > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Jul 19 08:27:52 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 19 Jul 2010 08:27:52 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Sunday, July 18, 2010 12:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > In theorie yes, in practice eg inside a password for a db connection. > > how hard would it be to allow quotes around the password? (if this ends > up > disallowing quotes in the password to the database, that's not too bad > a > cost) > > I'm trying to think of if there are some fairly minor changes that > could > be made that would make it significantly easier for a better parser to > be > written. The real problem is the interface spec: whenever I change the syntax, I also (need to) change the interface spec. That is because the current spec says that everything from first non-whitespace after the filter up to LF needs to be passed to the output module. That's it... So even a minor change invalidates that interface. Given the fact that I know about at least three externally written plugins (which means probably more), I am hesitant to break that part of the spec, at least if I can avoid it. > changng the config is always a problem, but there are some problems > that > are much larger than others, and if a minor change would make it much > easier to move to a standard parser it may be worth making the breakage I agree, but only if unavoidable. As it currently looks, I think I will probably be able to generate a (decently complex) flex/bison parser that processes old and new-style (whatever it be) format. However, moving to flex/bison is considerable work, even if it were crystal-clear what we intend to do. So it sounds very appealing to me to stay within the constraints of the current parser and implement scoping with its help. That is still a lot of work, but much, much less than a full overhaul. Most importantly, it enables us to experimentally extend the config language, see how that works out in practice and *then* decide if we should really pursue that route. If so, we can than look at what exactly it takes to create a new parser subsystem. Of course, while extending the current system, we must keep an eye on potential "flex/bison grammars" and try not to introduce anything new that causes new problems. With the current proposal, I do not see any such problems. This gradual approach has the vast advantage that we get scoping into rsyslog at a far earlier time than when we did the full "right thing". However, the plugin interface will still be broken (I need the push/pop config ability plus config statement type designators), but at a far easier to fix level (from a plugin developer's PoV). > in > a 5.x or 6.x So doing this in a 6.x version sounds like a good thing, as it makes crystal-clear that some important things have changed. So I think you proposal is a very good one ;) Rainer > release (where the new capibilities are introduced so that > people can see the advantage of the breakage) > > David Lang > > > ----- Urspr?ngliche Nachricht ----- > > Von: david at lang.hm > > Gesendet: Freitag, 16. Juli 2010 19:57 > > An: rsyslog-users > > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > >>> Sent: Friday, July 16, 2010 11:33 AM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> Rainer Gerhards wrote: > >>>>> -----Original Message----- From: rsyslog- > bounces at lists.adiscon.com > >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog- > users > >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>>>> > >>>>> david at lang.hm wrote: > >>>>>> interesting, I'm not sure that anyone else realized that a > config > >>>>>> option could be split over multiple lines. > >>>>> I've banged my head on this (end-of-line comments). I believe the > >>>>> comments problem has been worked around now, but I still make > sure > >>>>> that I don't try to use end-of-line comments anywhere in my > >>>>> configs, just in case. > >>>> > >>>> That's an (one?) anomaly of the current parser. Thinking that it > >>>> would be replaced in the medium to long term, I did not care about > >>>> it. Looks like I now need to have a look ;) > >>> > >>> No big deal for me *now*, but it caused pain when I first ran into > it. > >>> Anyway, I thought you'd addressed this - about a year ago, maybe? > >> > >> I guess just mostly -- at least it boils down with actions > themselves, where > >> it is hard to handle due to the missing well-defined structure of > the string. > > > > is a # outside of quotes ever valid in an action string? > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Mon Jul 19 22:33:18 2010 From: sean at conman.org (Sean Conner) Date: Mon, 19 Jul 2010 16:33:18 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> Message-ID: <20100719203318.GB17467@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > If so, we can than look at what exactly it takes to create a new parser > subsystem. Of course, while extending the current system, we must keep an eye > on potential "flex/bison grammars" and try not to introduce anything new that > causes new problems. With the current proposal, I do not see any such > problems. The current parser obviously creates some internal structures used by the engine to run. Is this fully documented? If so, what's to keep someone from replacing the current parser with a completely different one that builds the same internal structures? Could you not have different configuration parsers? (issue: how to know which one to use; command line option perhaps? the first line describing which parsing module to use (and if missing, use the original one)?) Such a method might be beneficial to explore alternative configuration files. -spc (Just an idea ... ) From david at lang.hm Mon Jul 19 23:20:49 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Jul 2010 14:20:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100719203318.GB17467@brevard.conman.org> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> <20100719203318.GB17467@brevard.conman.org> Message-ID: On Mon, 19 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> If so, we can than look at what exactly it takes to create a new parser >> subsystem. Of course, while extending the current system, we must keep an eye >> on potential "flex/bison grammars" and try not to introduce anything new that >> causes new problems. With the current proposal, I do not see any such >> problems. > > The current parser obviously creates some internal structures used by the > engine to run. This is an incorrect assumption. the current parser creates some internal structures, but it also executes things immediatly > Is this fully documented? No, it's not fully documented because it's currently up to the individual module to do whatever it wants to do when it sees a config option. It can _do_ something, or it can create a variable that nothing else knows about, or it can change an existing variable. I initially made the same assumption, but Rainer has clarified this in these threads. David Lang > If so, what's to keep someone > from replacing the current parser with a completely different one that > builds the same internal structures? Could you not have different > configuration parsers? (issue: how to know which one to use; command line > option perhaps? the first line describing which parsing module to use (and > if missing, use the original one)?) Such a method might be beneficial to > explore alternative configuration files. > > -spc (Just an idea ... ) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From akozumpl at redhat.com Tue Jul 20 10:55:18 2010 From: akozumpl at redhat.com (Ales Kozumplik) Date: Tue, 20 Jul 2010 10:55:18 +0200 Subject: [rsyslog] log forwarding through unix sockets Message-ID: <4C456476.4010703@redhat.com> Hi list, I am using rsyslog to forward logs between KVM guest and host machines during the Fedora installation program (aka Anaconda). Details are described here: https://fedoraproject.org/wiki/Anaconda/Logging#Remote_logging_via_virtio, but in the gist: recent QEMU/KVM has a feature using which one can write to a character device on the guest end and read those data from a unix socket on the host end. We are tying to use this facility to forward the installation logs to the host. Two rsyslogd instances are involved in the process: the sending one on the guest end and the receiving one on the host end (which parses the incoming messages' headers and files the messages into different files). Unfortunately I've run into a couple of issues trying to set up the forwarding using this mechanism: 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to read data from SOCK_DGRAM. This has two consequences: first, to be able to attach rsyslog on the host end one first needs to copy the data between the two socket types, e.g. using socat. Second, messages longer than 1024 characters are sometimes split into two. The second message is thus missing the syslog header and the receiving rsyslogd doesn't know where to file it. Is there a recommended workaround for those things (maybe a parameter I overlooked in the docs tellling rsyslogd to use SOCK_STREAM)? 2) I seem to be unable to get the forwarding template right. For network forwarding (which is also supported in Anaconda), simply putting no explicit formatting does the trick: *.* @@ some.host The received logs can be matched for anything: severity, facility, hostname and programname. This is not the case when logs are forwarded through the character device: *.* /dev/virtio_ports/port_name Using the implicit formatting the receiving syslog won't parse the programname. I tried using the predefined ForwardFormat but then the receiving rsyslogd parsed hostname as the programname and the programname remains part of the final message. Is that the expected behavior? What worked for me in the end was creating a template based on the ForwardFormat but with the %HOSTNAME% part omitted: I can live with that for know since I know the message came from a certain socket so it can be only one host. Still: it seems weird there's no forwarding format provided that would retain 100% of the information parsable by another rsyslog reading from a socket. I'm probably just missing something? Thanks for any reply about this. Ales Kozumplik From rgerhards at hq.adiscon.com Tue Jul 20 15:40:17 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Jul 2010 15:40:17 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 19, 2010 11:21 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Mon, 19 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great Rainer Gerhards once stated: > >> > >> If so, we can than look at what exactly it takes to create a new > parser > >> subsystem. Of course, while extending the current system, we must > keep an eye > >> on potential "flex/bison grammars" and try not to introduce anything > new that > >> causes new problems. With the current proposal, I do not see any > such > >> problems. > > > > The current parser obviously creates some internal structures used > by the > > engine to run. > > This is an incorrect assumption. the current parser creates some > internal > structures, but it also executes things immediatly > > > Is this fully documented? > > No, it's not fully documented because it's currently up to the > individual > module to do whatever it wants to do when it sees a config option. It > can > _do_ something, or it can create a variable that nothing else knows > about, > or it can change an existing variable. > > I initially made the same assumption, but Rainer has clarified this in > these threads. David is absolutely right in his posting. But let me add some more explanation. Rsyslog's config parser was never "designed". We inherited it from sysklogd and it probably is one of the last remaining parts that actually have sysklogd heritage at all. It is not even a real parser, at least if you make some usual assumptions of what a language parser does. This all is part of the problem, and this also is the reason why it is considerable effort to change the way the config system operates. I'd really love to have what Sean assumes we have. This would be a big step into the right direction. But even if we had it, I don't think that would change the discussion. Even though loadable parsers could then be easily added, I doubt someone except me will ever write on. Look at the situation of message parsers and such -- while it is fairly simple to create one, most people are hesitant to do it (for output plugins it is even more simple, and there we see third parties!). A parser is not trivial, so I don't expect to see someone actually write one (vs. claim he would write one if the interface were there). I, on the other hand, have no motivation at all to write multiple parsers - just duplicated (aka wasted) effort. So the discussion about which parsers is the first (and thus potentially only) one is very vital. Just for the records: the current route probably is to stay with the current config system, introduce scoping and *then* think about how the system could be modified. Rainer From tbergfeld at hq.adiscon.com Wed Jul 21 15:06:02 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 21 Jul 2010 15:06:02 +0200 Subject: [rsyslog] rsyslog 5.5.6 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.6, a member of the devel branch. The new release provides exciting performance enhancements: on multicore-machines it can be many times faster than version 5.5.5 (which already was quite fast). Most importantly, the enhancement provides much better scalability, so adding many additional core gains much more speedup than with any previous version. A new concept of "strgen" modules has been implemented, which permit to use high speed C code as templates. Also, support for malformed "last message repated n times" messages, as emited by some syslogds, has been added in form of a custom message parser. There are also a couple of bugfixes and minor improvements. See ChangeLog for more details. ChangeLog: http://www.rsyslog.com/changelog-for-5-5-6-devel/ Download: http://www.rsyslog.com/rsyslog-5-5-6-devel As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From friedl at hq.adiscon.com Wed Jul 21 15:55:26 2010 From: friedl at hq.adiscon.com (Florian Riedl) Date: Wed, 21 Jul 2010 15:55:26 +0200 Subject: [rsyslog] New rsyslog website is live! Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Dear rsyslog folks, The Adiscon GmbH is proud to announce that today we have made the new rsyslog website live. If you find something missing or not working correctly, please let us know. Further, we are open to suggestions to make the new website even better. We will do some last finishing touches to it currently as well, therefore sometimes some things might not work correctly. Since we did not drag over the complete old content like old news releases, you can still get find it at http://old.rsyslog.com. We hope you have a good experience with the new website. Best regards, Florian Riedl Adiscon -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From lists at luigirosa.com Thu Jul 22 05:53:38 2010 From: lists at luigirosa.com (Luigi Rosa) Date: Thu, 22 Jul 2010 05:53:38 +0200 Subject: [rsyslog] New rsyslog website is live! In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Message-ID: <4C47C0C2.5010806@luigirosa.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Riedl said the following on 21/07/10 15:55: > If you find something missing or not working correctly, please let us know. The style of both Google ad does not display well on Firefox+Ubuntu The right coloumn of ad is too big, the row below the three boxes overlaps the other elements. http://luigirosa.com/rsyslog.png Ciao, luigi - -- / +--[Luigi Rosa]-- \ There is a greater darkness than the one we fight. It is the darkness of the soul that has lost its way. The war we fight is not against powers and principalities, it is against chaos and despair. Greater than the death of flesh is the death of hope, the death of dreams. Against this peril we can never surrender. The future is all around us, waiting, in moments of transition, to be born in moments of revelation. No one knows the shape of that future or where it will take us. We know only that it is always born in pain. --G'Kar, "Z'ha'dum" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHwL8ACgkQ3kWu7Tfl6ZSi1QCfUkQXhzdCRzcdu81gEp43bqCg N7oAnipWupEp16ILTl4omY5jdu9bncG+ =ELlp -----END PGP SIGNATURE----- From rgerhards at hq.adiscon.com Fri Jul 23 17:43:09 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Jul 2010 17:43:09 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FED@GRFEXC.intern.adiscon.com> For those interested: I have begun to implement action scoping. A snapshot with partial functionality is available at http://git.adiscon.com/?p=rsyslog.git;a=shortlog;h=refs/heads/newconf It does NOT yet include the necessary output plugin interface change (or updated plugins), but it implements $Begin action $End action $StrictScoping [on/off] -- off default So if you want to play a bit with it, feel free to do so. Note that it disallows global statements within action scope and in overall has somewhat better detection of user errors (these are easier to detect when scoping is used). Note that scoping is purely optional: if not enabled, it will not be used. So any current rsyslog.conf remains valid. I will see that I change the projects's output plugins next week, and will possibly then make an experimental release. I just thought I let all of you know. Rainer From david at lang.hm Sat Jul 24 06:57:26 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 23 Jul 2010 21:57:26 -0700 (PDT) Subject: [rsyslog] mark messages Message-ID: I have a server sending me bad data, so I implmented the following rule to trap log messaages where the hostname isn't an IP address or name :hostname, regex, "[a-zA-Z\.]" /file & ~ *.* /file2;fixformat unfortunantly it turns out that this also traps mark messages. the %rawmsg% for mark is just "-- MARK --" and apparently hostname is not populated (fromhost-ip is 127.0.0.1) I do have -x on the rsyslog command line, so it is not doing DNS resolution, but it should come up with either the local hostname or 127.0.0.1 as the hostname for locally generated messages. Either one of these would match my regex as being a 'normal' message This box is currently running 5.5.3 David Lang From rgerhards at hq.adiscon.com Mon Jul 26 14:18:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 14:18:20 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Hi David, I have just checked immark, it uses a function to log internal messages (that alone is questionable, but stems back to its history). However, this function should properly populate hostname, so it looks like something else is broken. Will check and keep you updated. Thanks for the info, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Jul 26 15:18:44 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:18:44 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF9@GRFEXC.intern.adiscon.com> David, I now checked > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% This is a special case where %rawmsg% does not contain everything. Internal messages generate the necessary in-memory structure, but do not try to emulate %rawmsg% in all its glory (but it may be worth thinking about that). HOWEVER, fromhost and fromhost-ip are properly populated. So the filter should work, assuming that the hostname actually matches the regex. I suggest that you use the canned RSYSLOG_DebugFormat template so that we can see what exactly is stored in your in-memory message representation. Rainer > for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:18:02 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:18:02 +0200 Subject: [rsyslog] Rsyslog Version Comparison Message-ID: <4C4D8B0A.8090503@kinzesberg.de> Hi folks, I have searched the new site for a comparison of the major version of rsyslog (3, 4, 5), but found nothing. Only information seems to be the change logs, but I would not like to parse through several dozen documents and work on a matrix for some hours, so ... Is there an overview document relating versions and features? Any hint or help is appreciated. Dirk From rgerhards at hq.adiscon.com Mon Jul 26 15:27:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:27:31 +0200 Subject: [rsyslog] Rsyslog Version Comparison References: <4C4D8B0A.8090503@kinzesberg.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> As far as I know, there is no such comparison. But I agree this would probably be very useful. I'll ask the web folks if they have time to generate such a page (maybe not with all details, but the more important features, at least for a start). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz > Sent: Monday, July 26, 2010 3:18 PM > To: rsyslog-users > Subject: [rsyslog] Rsyslog Version Comparison > > Hi folks, > > I have searched the new site for a comparison of the major version of > rsyslog (3, 4, 5), but found nothing. Only information seems to be the > change logs, but I would not like to parse through several dozen > documents and work on a matrix for some hours, so ... > > Is there an overview document relating versions and features? > > Any hint or help is appreciated. > > Dirk > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:35:25 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:35:25 +0200 Subject: [rsyslog] Rsyslog Version Comparison In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> References: <4C4D8B0A.8090503@kinzesberg.de> <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> Message-ID: <4C4D8F1D.8000507@kinzesberg.de> thanks a lot, that would be great! dirk Am 26.07.10 15:27, schrieb Rainer Gerhards: > As far as I know, there is no such comparison. But I agree this would > probably be very useful. I'll ask the web folks if they have time to generate > such a page (maybe not with all details, but the more important features, at > least for a start). > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz >> Sent: Monday, July 26, 2010 3:18 PM >> To: rsyslog-users >> Subject: [rsyslog] Rsyslog Version Comparison >> >> Hi folks, >> >> I have searched the new site for a comparison of the major version of >> rsyslog (3, 4, 5), but found nothing. Only information seems to be the >> change logs, but I would not like to parse through several dozen >> documents and work on a matrix for some hours, so ... >> >> Is there an overview document relating versions and features? >> >> Any hint or help is appreciated. >> >> Dirk >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Mon Jul 26 20:25:40 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 26 Jul 2010 11:25:40 -0700 (PDT) Subject: [rsyslog] mark messages In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 26 Jul 2010, Rainer Gerhards wrote: > Hi David, > > I have just checked immark, it uses a function to log internal messages (that > alone is questionable, but stems back to its history). However, this function > should properly populate hostname, so it looks like something else is broken. > Will check and keep you updated. you may need to explicitly check what happens when -x is provided. David Lang > Thanks for the info, > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Saturday, July 24, 2010 6:57 AM >> To: rsyslog-users >> Subject: [rsyslog] mark messages >> >> I have a server sending me bad data, so I implmented the following rule >> to >> trap log messaages where the hostname isn't an IP address or name >> >> :hostname, regex, "[a-zA-Z\.]" /file >> & ~ >> *.* /file2;fixformat >> >> unfortunantly it turns out that this also traps mark messages. >> >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname is >> not >> populated (fromhost-ip is 127.0.0.1) >> >> I do have -x on the rsyslog command line, so it is not doing DNS >> resolution, but it should come up with either the local hostname or >> 127.0.0.1 as the hostname for locally generated messages. Either one of >> these would match my regex as being a 'normal' message >> >> This box is currently running 5.5.3 >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Jul 27 09:29:28 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Jul 2010 09:29:28 +0200 Subject: [rsyslog] mark messages References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104002@GRFEXC.intern.adiscon.com> David, have you seen my other message where I asked to check all properties? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 26, 2010 8:26 PM > To: rsyslog-users > Subject: Re: [rsyslog] mark messages > > On Mon, 26 Jul 2010, Rainer Gerhards wrote: > > > Hi David, > > > > I have just checked immark, it uses a function to log internal > messages (that > > alone is questionable, but stems back to its history). However, this > function > > should properly populate hostname, so it looks like something else is > broken. > > Will check and keep you updated. > > you may need to explicitly check what happens when -x is provided. > > David Lang > > > > Thanks for the info, > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Saturday, July 24, 2010 6:57 AM > >> To: rsyslog-users > >> Subject: [rsyslog] mark messages > >> > >> I have a server sending me bad data, so I implmented the following > rule > >> to > >> trap log messaages where the hostname isn't an IP address or name > >> > >> :hostname, regex, "[a-zA-Z\.]" /file > >> & ~ > >> *.* /file2;fixformat > >> > >> unfortunantly it turns out that this also traps mark messages. > >> > >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname > is > >> not > >> populated (fromhost-ip is 127.0.0.1) > >> > >> I do have -x on the rsyslog command line, so it is not doing DNS > >> resolution, but it should come up with either the local hostname or > >> 127.0.0.1 as the hostname for locally generated messages. Either one > of > >> these would match my regex as being a 'normal' message > >> > >> This box is currently running 5.5.3 > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Tue Jul 27 13:51:21 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Tue, 27 Jul 2010 13:51:21 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors Message-ID: I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. I'm trying to use the rsyslog to send syslog messages to an existing oracle db. I'm facing these problems, and don't really know where to begin. I've setup the correct oracle environment during startup of the rsyslog and it got me errors seen below. I have done the same trying to build the rsyslog using "./configure --enable-oracle", then "make", "make install" with the oracle environment setup, but got same errors seen below. Can anyone help me solve this? errors while building rsyslog's plugin omoracle: make[2]: Entering directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' CC omoracle_la-omoracle.lo omoracle.c: In function ?prepare_statement?: omoracle.c:254: warning: pointer targets in passing argument 3 of ?OCIStmtPrepare? differ in signedness omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from incompatible pointer type omoracle.c: In function ?createInstance?: omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? differ in signedness omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? differ in signedness omoracle.c: In function ?log_detailed_err?: omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from incompatible pointer type omoracle.c: In function ?tryResume?: omoracle.c:461: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?startSession?: omoracle.c:481: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?parseSelectorAct?: omoracle.c:517: warning: implicit declaration of function ?cflineParseTemplateName? CCLD omoracle.la make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' Making all in tests syslog entries when starting rsyslog daemon: 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = /proc/kmsg started. 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: TNS:could not resolve the connect identifier specified 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle session 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line without actions will be discarded 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2124 ] Debug statements checking rsyslog's configuration: 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' 1494.718302000:2abb22fc5ac0: loading module '/usr/local/lib/rsyslog/omoracle.so' 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry -- Best regards! Damien From mrdemeanour at jackpot.uk.net Tue Jul 27 14:30:08 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 27 Jul 2010 13:30:08 +0100 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: References: Message-ID: <4C4ED150.4070603@jackpot.uk.net> Damjan ?iberna wrote: > I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 > and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. > I'm trying to use the rsyslog to send syslog messages to an existing oracle > db. I'm facing these problems, and don't really know where to begin. I've > setup the correct oracle environment during startup of the rsyslog and it > got me errors seen below. I have done the same trying to build the rsyslog > using "./configure --enable-oracle", then "make", "make install" with the > oracle environment setup, but got same errors seen below. > > Can anyone help me solve this? I'm very much not up-to-date on Oracle, and I've never used instantclient. I've never tried to use rsyslog with Oracle either. Inline remarks [below] may therefore be wide of the mark. However it looks to me that you have a problem with your Oracle connect string; a problem with your rsyslog config; and a problem with your ORACLE_HOME. > > > errors while building rsyslog's plugin omoracle: > > make[2]: Entering directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > CC omoracle_la-omoracle.lo > omoracle.c: In function ?prepare_statement?: > omoracle.c:254: warning: pointer targets in passing argument 3 of > ?OCIStmtPrepare? differ in signedness > omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from > incompatible pointer type > omoracle.c: In function ?createInstance?: > omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? > differ in signedness > omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? > differ in signedness > omoracle.c: In function ?log_detailed_err?: > omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from > incompatible pointer type > omoracle.c: In function ?tryResume?: > omoracle.c:461: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?startSession?: > omoracle.c:481: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?parseSelectorAct?: > omoracle.c:517: warning: implicit declaration of function > ?cflineParseTemplateName? > CCLD omoracle.la > make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > Making all in tests Those all look like warnings, not errors. Did the module get built? > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = > /proc/kmsg started. > 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" > swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: > TNS:could not resolve the connect identifier specified http://ora-12154.ora-code.com/ Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached. > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > session > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > without actions will be discarded Defective rsyslog.conf. > 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could > not interpret master config file '/etc/rsyslog.conf'. [try > http://www.rsyslog.com/e/2124 ] > > > Debug statements checking rsyslog's configuration: > > 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' > 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' > 1494.718302000:2abb22fc5ac0: loading module > '/usr/local/lib/rsyslog/omoracle.so' > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html The poster says: tora: symbol lookup error: /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: nltrc_entry [...] When I switch ORACLE_HOME to point to a full install of Oracle 10g, the problem goes away, and TOra launches normally. HTH, -- MrD. From damjanster at gmail.com Wed Jul 28 10:10:22 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 10:10:22 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: <4C4ED150.4070603@jackpot.uk.net> References: <4C4ED150.4070603@jackpot.uk.net> Message-ID: > > However it looks to me that you have a problem with your Oracle connect > string; a problem with your rsyslog config; and a problem with your > ORACLE_HOME. > The ORACLE_HOME, TNS_ADMIN, LD_LIBRARY_PATH variables get set just before the rsyslogd is run. ORACLE_HOME is set to the production installation of our database - not to instantclinet's home. > > > > > > errors while building rsyslog's plugin omoracle: > > > CCLD omoracle.la > > make[2]: Leaving directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > > Making all in tests > > Those all look like warnings, not errors. Did the module get built? > The module got built and installed. It's just not loading. > > > > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: > ORA-12154: > > TNS:could not resolve the connect identifier specified > > http://ora-12154.ora-code.com/ > This error is interesting in its own, but since the omoracle plugin doesn't get loaded the $Om... parameters get ignored - as I can see from the debug output running rsyslog. > > > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > > session > > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured > in > > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > > without actions will be discarded > > Defective rsyslog.conf. > Not 100% sure, but I believe this is due to omoracle not loading. > > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry > > > http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html > > The poster says: > tora: symbol lookup error: > /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: > nltrc_entry > [...] > When I switch ORACLE_HOME to point to a full install of Oracle 10g, > the problem goes away, and TOra launches normally. > An interesting point. As I've mentioned before, these variables are set like this: export LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.4/client64/lib export PATH=/ust/lib/oracle/10.2.0.4/client64:/usr/local/bin:$PATH export TNS_ADMIN=/usr/lib/oracle/10.2.0.4/client64 export ORAENV_ASK=NO export ORACLE_SID=dbase . oraenv unset ORAENV_ASK ORACLE_HOME gets set via oraenv to the production database path - not instantclient's. The database in question is verison 11.2G, but this should not be a problem. Any help is much apprechiated. From damjanster at gmail.com Wed Jul 28 15:35:51 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 15:35:51 +0200 Subject: [rsyslog] OmoracleStatement format Message-ID: I'm trying to get as much valuable info into our oracledb as possible for further analysis. This is what I came up with so far: $template OmoracleStatement,"INSERT INTO SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message)" $template TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost-ip%%syslogfacility%%syslogseverity%%msg%" *.* :omoracle:;TestStmt These statements don't really work well: 1. timestamp ~ timereported - there's no reference on the web site about how different options format the output. I'd love to have the full-form date&time format, but without the letter "T" in the middle, since Oracle doesn't know how to handle it. The above values string is a workaround, but I'm afraid it's too slow to process great amounts of entries. 2. hostname doesn't get written - I only get 127.0.0.1 3. hostip - only gets written when messages arrive from localhost: 127.0.0.1 4. facility - gets written correctly 5. severity - the %msg% value gets written into this column 6. message - always empty I'm trying to centralize syslog from all surrounding servers. Only the central server uses rsyslog, all the rest use the plain syslog daemon. Should I replace syslog with rsyslog on the surrounding servers to get this to work? Is there some place to get some better reference for the rsyslog strings and it's results? Is it possible to log the exact values that omoracle tries to commit to the database? -- Best regards! Damien From rgerhards at hq.adiscon.com Wed Jul 28 15:42:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 28 Jul 2010 15:42:22 +0200 Subject: [rsyslog] OmoracleStatement format References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> I have no idea on omoracle, but I can comment on the "normal" rsyslog stuff... > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Wednesday, July 28, 2010 3:36 PM > To: rsyslog-users > Subject: [rsyslog] OmoracleStatement format > > I'm trying to get as much valuable info into our oracledb as possible > for > further analysis. This is what I came up with so far: > > > $template OmoracleStatement,"INSERT INTO > SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES > (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY- > MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message) > " > $template > TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost- > ip%%syslogfacility%%syslogseverity%%msg%" > *.* :omoracle:;TestStmt > > These statements don't really work well: > 1. timestamp ~ timereported - there's no reference on the web site > about how > different options format the output. I'd love to have the full-form > date&time format, but without the letter "T" in the middle, since > Oracle > doesn't know how to handle it. The above values string is a workaround, > but > I'm afraid it's too slow to process great amounts of entries. I think it would be best to split the RFC3339 date via the property replacer (using start and end position) and then feed this to omoracle. The full doc on property replacer is here: http://www.rsyslog.com/doc/property_replacer.html > > 2. hostname doesn't get written - I only get 127.0.0.1 It would be useful to write a quick debug file *.* /var/log/debug.log;RSYSLOG_DebugFormat This shows what exactly is stored in which property and can probably used to solve the question what exactly happens. > > 3. hostip - only gets written when messages arrive from localhost: > 127.0.0.1 > > 4. facility - gets written correctly > > 5. severity - the %msg% value gets written into this column > > 6. message - always empty see 2. > I'm trying to centralize syslog from all surrounding servers. Only the > central server uses rsyslog, all the rest use the plain syslog daemon. > Should I replace syslog with rsyslog on the surrounding servers to get > this > to work? That's probably not necessary, but let's see the result of 2. > Is there some place to get some better reference for the rsyslog > strings and > it's results? see link above > > Is it possible to log the exact values that omoracle tries to commit to > the > database? you can write to a file with the same template you use for omoracle. But 2. should be sufficient. Rainer > > > -- > Best regards! > Damien > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Thu Jul 29 03:43:40 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Wed, 28 Jul 2010 21:43:40 -0400 Subject: [rsyslog] How to write to a local socket? Message-ID: I just configured a privilege-separated RSyslog instance, and it's running fine. To read the kernel message log, I'm running a second daemon instance as root, along the lines described in the wiki. Currently, my root instance forwards messages via UDP to unprivileged instance's localhost-only listener. It works, but I'm not entirely happy with it. I'd like to forward via a local UNIX domain socket, instead. I think I understand how to configure the 'imuxsock' module so my unprivileged instance reads from a non-standard socket location. But I can't figure out how to tell my root instance to forward via a local domain socket. Is this possible? If so, how? Ryan B. Lynch ryan.b.lynch at gmail.com From sledz at dresearch.de Thu Jul 29 09:17:00 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 09:17:00 +0200 Subject: [rsyslog] Buggy pipe behaviour Message-ID: <4C512AEC.9070301@dresearch.de> We need to configure a pipe to connect the output to a special application. Our configuration looks like this: ----->snip<-------- $ModLoad imuxsock $ModLoad imklog $ModLoad immark $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $RepeatedMsgReduction on *.* |/var/run/syslog2thinfs ... some other channels ----->snap<-------- The fifo is created and has sufficient rights. Now we can see the following behaviour: No receiver connected to the pipe, rsyslog writes messages into it Receiver is connected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (just a few) Receiver is reconnected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (more than the pipe capacity?) Receiver is reconnected, *some queued messages* are read (but only up to the pipe capacity?) After this *no more messages* reach the end of the pipe. Disconnect/reconnect the receiver makes no difference. -> bad :( I believe this is a bug. May be some messages get lost because there is no place for intermediate storage. But after reconnecting the receiver new messages should pass the pipe again. Right? We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour using the following shell snippets. Sender: ----->snip<-------- i=0;while true; do logger -t count $i; i=$(($i+1)); done ----->snap<-------- Receiver: ----->snip<-------- while true; do cat /var/run/syslog2thinfs ; done ----->snap<-------- Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 10:46:18 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 10:46:18 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> This sounds like intended behavior. When an action fails (pipe fails when nobody reads and it is tried to write to it), rsyslog retries the configured number of times and then suspends the action for the configured period (at least I think it is configurable, you need to look up the details). Only after this period the action is retried. If it fails again, it is re-suspended, but this time with a longer suspension period. This is done so that rsyslog does not spent a lot of time on actions known to be failing. >From what you wrote, I think your use case would probably better be served by omprog, but I may be wrong. If you think about this route, you need to know that someone requested the functionality, but was never seen when it was done ;) So the module is only barely tested. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 9:17 AM > To: rsyslog ML > Subject: [rsyslog] Buggy pipe behaviour > > We need to configure a pipe to connect the output to a special > application. Our configuration looks like this: > > ----->snip<-------- > $ModLoad imuxsock > $ModLoad imklog > $ModLoad immark > > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat > > $RepeatedMsgReduction on > > *.* |/var/run/syslog2thinfs > > ... some other channels > ----->snap<-------- > > The fifo is created and has sufficient rights. > > Now we can see the following behaviour: > > No receiver connected to the pipe, rsyslog writes messages into it > > Receiver is connected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (just a few) > > Receiver is reconnected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (more than the pipe capacity?) > > Receiver is reconnected, *some queued messages* are read (but only up > to the pipe capacity?) > > After this *no more messages* reach the end of the pipe. > Disconnect/reconnect the receiver makes no difference. -> bad :( > > I believe this is a bug. May be some messages get lost because there is > no place for intermediate storage. But after reconnecting the receiver > new messages should pass the pipe again. Right? > > We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour > using the following shell snippets. > > Sender: > ----->snip<-------- > i=0;while true; do logger -t count $i; i=$(($i+1)); done > ----->snap<-------- > > Receiver: > ----->snip<-------- > while true; do cat /var/run/syslog2thinfs ; done > ----->snap<-------- > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 12:33:26 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:33:26 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> Message-ID: <4C5158F6.3060702@dresearch.de> Am 29.07.2010 10:46, schrieb Rainer Gerhards: > This sounds like intended behavior. When an action fails (pipe fails when > nobody reads and it is tried to write to it), rsyslog retries the configured > number of times and then suspends the action for the configured period (at > least I think it is configurable, you need to look up the details). Only > after this period the action is retried. If it fails again, it is > re-suspended, but this time with a longer suspension period. This is done so > that rsyslog does not spent a lot of time on actions known to be failing. So you say, if i wait long enough the messages should receive the end of the pipe? Are there some related debug printouts i can search for? Can you give some hints to the related configuration parameters (URL or keyword). Unfortunately the manual is not very helpful here. > From what you wrote, I think your use case would probably better be served by > omprog, but I may be wrong. If you think about this route, you need to know > that someone requested the functionality, but was never seen when it was done > ;) So the module is only barely tested. Same wish. Where can i read more about omprog? Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 12:43:06 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:43:06 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 12:33 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > This sounds like intended behavior. When an action fails (pipe fails > when > > nobody reads and it is tried to write to it), rsyslog retries the > configured > > number of times and then suspends the action for the configured > period (at > > least I think it is configurable, you need to look up the details). > Only > > after this period the action is retried. If it fails again, it is > > re-suspended, but this time with a longer suspension period. This is > done so > > that rsyslog does not spent a lot of time on actions known to be > failing. > > So you say, if i wait long enough the messages should receive the end > of the pipe? Yes, that's what I assume. > > Are there some related debug printouts i can search for? Search for "suspend", that should bring up a couple of messages. > > Can you give some hints to the related configuration parameters (URL or > keyword). Unfortunately the manual is not very helpful here. See http://www.rsyslog.com/doc/rsyslog_conf_global.html quick check brings up that $ActionResumeRetryCount $ACtionREsumeInterval Is relevant > > > From what you wrote, I think your use case would probably better be > served by > > omprog, but I may be wrong. If you think about this route, you need > to know > > that someone requested the functionality, but was never seen when it > was done > > ;) So the module is only barely tested. > > Same wish. Where can i read more about omprog? I thought I had writen some doc before I learned that this work was not being used by the original requester. I just checked, but it does not seem so. So it is probably best to look at the source. Rainer > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 12:46:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:46:10 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> This may also be of interest: http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982. html Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 12:43 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 12:33 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > > This sounds like intended behavior. When an action fails (pipe > fails > > when > > > nobody reads and it is tried to write to it), rsyslog retries the > > configured > > > number of times and then suspends the action for the configured > > period (at > > > least I think it is configurable, you need to look up the details). > > Only > > > after this period the action is retried. If it fails again, it is > > > re-suspended, but this time with a longer suspension period. This > is > > done so > > > that rsyslog does not spent a lot of time on actions known to be > > failing. > > > > So you say, if i wait long enough the messages should receive the end > > of the pipe? > > Yes, that's what I assume. > > > > > Are there some related debug printouts i can search for? > > Search for "suspend", that should bring up a couple of messages. > > > > > Can you give some hints to the related configuration parameters (URL > or > > keyword). Unfortunately the manual is not very helpful here. > > See > http://www.rsyslog.com/doc/rsyslog_conf_global.html > > quick check brings up that > $ActionResumeRetryCount > $ACtionREsumeInterval > > Is relevant > > > > > > From what you wrote, I think your use case would probably better be > > served by > > > omprog, but I may be wrong. If you think about this route, you need > > to know > > > that someone requested the functionality, but was never seen when > it > > was done > > > ;) So the module is only barely tested. > > > > Same wish. Where can i read more about omprog? > > I thought I had writen some doc before I learned that this work was not > being > used by the original requester. I just checked, but it does not seem > so. So > it is probably best to look at the source. > > Rainer > > > > Regards, > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From joel.merrick at gmail.com Thu Jul 29 12:53:13 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 29 Jul 2010 11:53:13 +0100 Subject: [rsyslog] Problem with mysql template Message-ID: Hi all, I'm trying to create a very quick mail log searching solution. The idea is to pre-hash the database by using the last 2 alpha-numeric characters on the message id. This isn't inserting to the database and I can't think why.. I've already built the tables with the structure logs-aa.. logs-ZZ etc.. $template OurDBLog,"INSERT INTO logs-'%msg:R,ERE,1,NULL:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-([A-Za-z0-9]{2})--end%' (messageid, host, \ send_host, created_at, payload, subject) values \ ('%msg:R,ERE,0,ZERO:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-[A-Za-z0-9]{2}--end%','%HOSTNAME%', '%msg:R,ERE,0,ZERO:H=.*\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}]--end%', \ '%timegenerated:::date-mysql%', '%msg%', '%msg:R,ERE,1,ZERO:T="(.+)"--end%')",SQL Any idea? On a side note, how can I get extra verbosity out of rsyslog so I'm not blindly trying to insert and then check via mysql Cheers, Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From sledz at dresearch.de Thu Jul 29 12:58:21 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:58:21 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> Message-ID: <4C515ECD.6060109@dresearch.de> Am 29.07.2010 12:46, schrieb Rainer Gerhards: > This may also be of interest: > > http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982.html General Error Language file ./language/en/404error.php couldn't be opened. Please notify the board administrator or webmaster: alorbach at adiscon.com :( From sledz at dresearch.de Thu Jul 29 13:13:04 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 13:13:04 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <4C516240.3000200@dresearch.de> Am 29.07.2010 12:43, schrieb Rainer Gerhards: >>> This sounds like intended behavior. When an action fails >>> (pipe fails when nobody reads and it is tried to write to >>> it), rsyslog retries the configured number of times and >>> then suspends the action for the configured period (at >>> least I think it is configurable, you need to look up the >>> details). Only after this period the action is retried. >>> If it fails again, it is re-suspended, but this time with >>> a longer suspension period. This is done so that rsyslog >>> does not spent a lot of time on actions known to be failing. >> >> So you say, if i wait long enough the messages should receive >> the end of the pipe? > > Yes, that's what I assume. I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 and your assumption seems to be wrong. :( If the receiver is available again after about 20 seconds (while flooding syslog with the mentioned script) it reads the content of the pipe and nothing more. The debug log from rsyslogd endless says ----------->snip<---------------- 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start 1711.687992707:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1711.688016872:b6644b70: Message from UNIX socket: #3 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start 1713.688441799:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1713.688488314:b6644b70: Message from UNIX socket: #3 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. ----------->snap<---------------- So it seems that rsyslogd does not detect that the receiver is available again (as mentioned before this only occurs if the receiver is not available for a "longer" time - probably the time the pipe runs full). Steffen From rgerhards at hq.adiscon.com Thu Jul 29 13:16:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:16:16 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <4C516240.3000200@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> OK, then this seems to be a bug indeed. I suggest you file a bug report with bugzilla. Usually, I tend to forget about those things if they exist on the mailing list only :( When they are in bugzilla, I pick them as soon as I have time to do so. It would probably wise to include a link to the mailing list archive. I will try to look into this ASAP, but it may take some while as I am pretty busy right at the moment. Thanks, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 1:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > >>> This sounds like intended behavior. When an action fails > >>> (pipe fails when nobody reads and it is tried to write to > >>> it), rsyslog retries the configured number of times and > >>> then suspends the action for the configured period (at > >>> least I think it is configurable, you need to look up the > >>> details). Only after this period the action is retried. > >>> If it fails again, it is re-suspended, but this time with > >>> a longer suspension period. This is done so that rsyslog > >>> does not spent a lot of time on actions known to be failing. > >> > >> So you say, if i wait long enough the messages should receive > >> the end of the pipe? > > > > Yes, that's what I assume. > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 > and your assumption seems to be wrong. :( > > If the receiver is available again after about 20 seconds (while > flooding syslog with the mentioned script) it reads the content of the > pipe and nothing more. > > The debug log from rsyslogd endless says > > ----------->snip<---------------- > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > 1711.687992707:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1711.688016872:b6644b70: Message from UNIX socket: #3 > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > 1713.688441799:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1713.688488314:b6644b70: Message from UNIX socket: #3 > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > ----------->snap<---------------- > > So it seems that rsyslogd does not detect that the receiver is > available again (as mentioned before this only occurs if the receiver > is not available for a "longer" time - probably the time the pipe runs > full). > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 13:19:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:19:27 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> One more thing: it may be useful if you could send me (privately) a complete debug log. I've just taken a look at ompipe, and there is no indication why this bug should happen. If I see how things proceed, I may be able to solve it quickly. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 1:16 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > OK, then this seems to be a bug indeed. I suggest you file a bug report > with > bugzilla. Usually, I tend to forget about those things if they exist on > the > mailing list only :( When they are in bugzilla, I pick them as soon as > I have > time to do so. It would probably wise to include a link to the mailing > list > archive. > > I will try to look into this ASAP, but it may take some while as I am > pretty > busy right at the moment. > > Thanks, > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 1:13 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > > >>> This sounds like intended behavior. When an action fails > > >>> (pipe fails when nobody reads and it is tried to write to > > >>> it), rsyslog retries the configured number of times and > > >>> then suspends the action for the configured period (at > > >>> least I think it is configurable, you need to look up the > > >>> details). Only after this period the action is retried. > > >>> If it fails again, it is re-suspended, but this time with > > >>> a longer suspension period. This is done so that rsyslog > > >>> does not spent a lot of time on actions known to be failing. > > >> > > >> So you say, if i wait long enough the messages should receive > > >> the end of the pipe? > > > > > > Yes, that's what I assume. > > > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval > 30 > > and your assumption seems to be wrong. :( > > > > If the receiver is available again after about 20 seconds (while > > flooding syslog with the mentioned script) it reads the content of > the > > pipe and nothing more. > > > > The debug log from rsyslogd endless says > > > > ----------->snip<---------------- > > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > > 1711.687992707:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1711.688016872:b6644b70: Message from UNIX socket: #3 > > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > > 1713.688441799:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1713.688488314:b6644b70: Message from UNIX socket: #3 > > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > ----------->snap<---------------- > > > > So it seems that rsyslogd does not detect that the receiver is > > available again (as mentioned before this only occurs if the receiver > > is not available for a "longer" time - probably the time the pipe > runs > > full). > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Thu Jul 29 13:24:29 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Thu, 29 Jul 2010 13:24:29 +0200 Subject: [rsyslog] OmoracleStatement format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: > > I think it would be best to split the RFC3339 date via the property > replacer > (using start and end position) and then feed this to omoracle. > > The full doc on property replacer is here: > > http://www.rsyslog.com/doc/property_replacer.html I first thought I could replace some strings with regex, but I've got a fix from coworker to solve the issue like this: $template OmoracleStatement,"INSERT INTO SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" $template TestStmt,"%hostname%%timereported:0:10:date-rfc3339%%timereported:12:32:date-rfc3339%%fromhost-ip%%syslogfacility%%syslogseverity%%programname%%msg%" It works great now. > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > It would be useful to write a quick debug file > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > This shows what exactly is stored in which property and can probably used > to > solve the question what exactly happens. > It seems that the issue with timestamp was the cause of all the problems. The data got displaced for one colon. Not it works like a charm. Thanks for the help. From sledz at dresearch.de Thu Jul 29 14:05:10 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 14:05:10 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> Message-ID: <4C516E76.3080209@dresearch.de> On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > One more thing: it may be useful if you could send me (privately) a complete > debug log. I've just taken a look at ompipe, and there is no indication why > this bug should happen. If I see how things proceed, I may be able to solve > it quickly. Is on the way. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 15:00:01 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:00:01 +0200 Subject: [rsyslog] OmoracleStatement format References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104024@GRFEXC.intern.adiscon.com> Excellent, great to hear it is working now :) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Thursday, July 29, 2010 1:24 PM > To: rsyslog-users > Subject: Re: [rsyslog] OmoracleStatement format > > > > > I think it would be best to split the RFC3339 date via the property > > replacer > > (using start and end position) and then feed this to omoracle. > > > > The full doc on property replacer is here: > > > > http://www.rsyslog.com/doc/property_replacer.html > > > I first thought I could replace some strings with regex, but I've got a > fix > from coworker to solve the issue like this: > > $template OmoracleStatement,"INSERT INTO > SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES > (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" > > $template > TestStmt,"%hostname%%timereported:0:10:date- > rfc3339%%timereported:12:32:date-rfc3339%%fromhost- > ip%%syslogfacility%%syslogseverity%%programname%%msg%" > > It works great now. > > > > > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > > > It would be useful to write a quick debug file > > > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > > > This shows what exactly is stored in which property and can probably > used > > to > > solve the question what exactly happens. > > > > It seems that the issue with timestamp was the cause of all the > problems. > The data got displaced for one colon. Not it works like a charm. > > Thanks for the help. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 15:07:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:07:31 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Ah, OK, now I see clearly. Well, the "obvious" happens, but I didn't realize it myself: You set the retry count to -1, that is infinite. So messages are never discarded. When nobody is reading the pipe, a queue builds up. In the log, the queue capacity is simply exhausted. As it looks from the log, nobody seems to be reading the pipe, at least we consistently get error 11 back from the write API call. Can you confirm this (I may be wrong, just looking quickly). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 2:05 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > > One more thing: it may be useful if you could send me (privately) a > complete > > debug log. I've just taken a look at ompipe, and there is no > indication why > > this bug should happen. If I see how things proceed, I may be able to > solve > > it quickly. > > Is on the way. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 15:18:05 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 15:18:05 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Message-ID: <4C517F8D.9020405@dresearch.de> On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > You set the retry count to -1, that is infinite. So > messages are never discarded. When nobody is reading > the pipe, a queue builds up. In the log, the queue > capacity is simply exhausted. As it looks from the > log, nobody seems to be reading the pipe, at least > we consistently get error 11 back from the write API > call. As i wrote before *there is someone reading* the pipe. In another shell i run while true; do cat /var/run/syslog2thinfs ; done Also when i kill and restart the reader the behaviour still is the same. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 16:35:33 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 16:35:33 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Did you keep it running for more than 30 seconds after it has reached the stalled state? From the log, it looks like it were only roughly 9 seconds. As I said, I don'T see any more activity inside the debug log. But maybe it is just hidden. I suggest you restart the test and then wait for 5 minutes and se what happens. You may want to stop the producer after a few seconds, because messages are still sitting inside the queue and that makes looking at the log easier. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 3:18 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > > You set the retry count to -1, that is infinite. So > > messages are never discarded. When nobody is reading > > the pipe, a queue builds up. In the log, the queue > > capacity is simply exhausted. As it looks from the > > log, nobody seems to be reading the pipe, at least > > we consistently get error 11 back from the write API > > call. > > As i wrote before *there is someone reading* the pipe. > > In another shell i run > > while true; do cat /var/run/syslog2thinfs ; done > > Also when i kill and restart the reader the behaviour still is the > same. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Fri Jul 30 00:33:43 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Thu, 29 Jul 2010 18:33:43 -0400 Subject: [rsyslog] How to write to a local socket? In-Reply-To: References: Message-ID: On Wed, Jul 28, 2010 at 21:43, Ryan Lynch wrote: > I'd like to forward via a local UNIX domain socket, instead. I think I > understand how to configure the 'imuxsock' module so my unprivileged > instance reads from a non-standard socket location. But I can't figure > out how to tell my root instance to forward via a local domain socket. I didn't figure out a completely RSyslog-native method, but another poster's message pointed me toward 'socat' and 'omprog', which I have working, now. (It would be really nice if RSyslog could support this natively, though.) In case anyone else wants to set this up, maybe this will save you some effort. I'm also interested in any comments/criticisms about this method, I'd love to hear suggestions for better ways to make this work. Also, I rolled it all up into a Fedora/EL RPM spec, and I'll send it on to anyone who's interested--just ask. Setup steps: * Install the 'socat' utility. * Build RSyslog with the '--enable-omprog' ./configure flag. * Create two separate RSyslog config files, one for the 'root' instance (writes to the socket) and a second for the 'unprivileged' instance (reads from the socket). * Rewrite your RSyslog init script to start two separate daemon instances, one using each config file (and separate PID files, too). * Create the user 'rsyslogd' and the group 'rsyslogd'. * Set permissions/ownerships as needed to allow the user 'rsyslogd' to write to the file '/var/log/rsyslog.log' * Create an executable script called '/usr/libexec/rsyslogd/omprog_socat' that contains the lines: #!/bin/bash /usr/bin/socat -t0 -T0 -lydaemon -d - UNIX-SENDTO:/dev/log * The 'root' instance config file should contain (modifying the output actions to taste): $ModLoad imklog $ModLoad omprog $Template FwdViaUNIXSocket,"<%pri%>%syslogtag%%msg%" $ActionOMProgBinary /usr/libexec/rsyslogd/omprog_socat *.* :omprog:;FwdViaUNIXSocket * The 'unprivileged' instance config file should contain (modifying the output actions to taste): $ModLoad imuxsock $PrivDropToUser rsyslogd $PrivDropToGroup rsyslogd *.* /var/log/rsyslog.log The 'root' daemon can only accept input from the kernel message buffer, and nothing else (especially not the syslog socket (/dev/log) or any network sockets). The unprivileged user will handle all of local and network log messages. To merge the kernel logs into the same data channel as everything else, here's what happens: [During the RSyslog daemons' startup] A) At startup, the 'root' daemon's 'imklog' module starts listening for kernel messages (via '/prog/kmsg'), and its 'omprog' module starts an instance of 'socat' (called via the 'omprog_socat' wrapper), establishing a persistent one-way IO connection where 'omprog' pipes its output to the STDIN of 'socat'. (Note that this same 'socat' instance remains running throughout the life of the RSyslog daemon, handling everything 'omprog' outputs. Contrast this, efficiency-wise, against the built-in 'subshell' module [the '^/path/to/program' action], which runs a separate instance instance of the child program for each message.) B) At startup, the 'unprivileged' daemon's 'imuxsock' module opens the system logging socket ('/dev/log') and starts listening for incoming log messages from other programs. [During normal operation] 1) The kernel buffer produces a message string on '/proc/kmsg'. 2) The 'root' RSyslog daemon reads the message from '/proc/kmsg', assigning it the priority number of 'kern.info' and the string tag 'kernel'. 3) The 'root' daemon prepends the priority number and tag as a header to the message string, and then passes it to the 'omprog' module for output (via persistent pipe) to the running 'socat' instance. 4) The 'socat' instance receives the header-framed message and sends it to the system logging socket ('/dev/log'). 5) The 'unprivileged' RSyslog daemon reads the message from '/dev/log', assigning it the priority and tag given in the message header, plus all of the other properties (timestamp, hostname, etc.) a message object should have. 6) The 'unprivileged' daemon formats the message and writes it to the output file. The only real difference I can see in the forwarded messages is that the 'source' property is set to 'imuxsock' instead of 'imklog'. I don't think that's a real problem, though, since the priority and tag are still distinct. -Ryan From sledz at dresearch.de Fri Jul 30 08:18:28 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:18:28 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Message-ID: <4C526EB4.9000106@dresearch.de> Am 29.07.2010 16:35, schrieb Rainer Gerhards: > Did you keep it running for more than 30 seconds after > it has reached the stalled state? From the log, it looks > like it were only roughly 9 seconds. As I said, I don'T > see any more activity inside the debug log. But maybe it > is just hidden. > > I suggest you restart the test and then wait for 5 minutes > and se what happens. You may want to stop the producer > after a few seconds, because messages are still sitting > inside the queue and that makes looking at the log > easier. I've rerun the test: * start rsyslog * start receiver * start producer * stop and restart receiver after 5 sec -> OK * stop and restart receiver after 30 sec -> stall * stop producer * wait 10 min and call "logger test" -> still stalling :( I'll send the logfile to your personal address again. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:26:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:26:13 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 16:35, schrieb Rainer Gerhards: > > Did you keep it running for more than 30 seconds after > > it has reached the stalled state? From the log, it looks > > like it were only roughly 9 seconds. As I said, I don'T > > see any more activity inside the debug log. But maybe it > > is just hidden. > > > > I suggest you restart the test and then wait for 5 minutes > > and se what happens. You may want to stop the producer > > after a few seconds, because messages are still sitting > > inside the queue and that makes looking at the log > > easier. > > I've rerun the test: > > * start rsyslog > * start receiver > * start producer > * stop and restart receiver after 5 sec -> OK > * stop and restart receiver after 30 sec -> stall > * stop producer > * wait 10 min and call "logger test" -> still stalling :( Interesting -- I don't see any reprobing of the output. Unfortunately, the debug output does not really provide much insight of what is going on at the moment. I'll see if I can add some more instrumentation to try track this down. Not sure if I can do this today. Rainer > > I'll send the logfile to your personal address again. > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 08:30:11 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:30:11 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> Message-ID: <4C527173.9090805@dresearch.de> Am 30.07.2010 08:26, schrieb Rainer Gerhards: > Interesting -- I don't see any reprobing of the output. > Unfortunately, the debug output does not really provide > much insight of what is going on at the moment. I'll see > if I can add some more instrumentation to try track this > down. Not sure if I can do this today. Can you give some hints which source files/functions are primarily involved here? May be we can do a little code review. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:45:23 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:45:23 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> <4C527173.9090805@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > Interesting -- I don't see any reprobing of the output. > > Unfortunately, the debug output does not really provide > > much insight of what is going on at the moment. I'll see > > if I can add some more instrumentation to try track this > > down. Not sure if I can do this today. > > Can you give some hints which source files/functions are primarily > involved here? May be we can do a little code review. I'd start with ./action.[ch] and obviously ompipe itself. It may be useful to see what/how ompipe returns. You can also set debug mode to do a function trace (see debug doc), this requires --enable-rtinst. Rainer > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Fri Jul 30 08:46:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:46:57 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com><4C527173.9090805@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104033@GRFEXC.intern.adiscon.com> And if you don't know this already, this doc may be useful: http://download.rsyslog.com/design.pdf It is not totally up to date, but covers the most important ides (most importantly the engine state transitions). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Friday, July 30, 2010 8:45 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Friday, July 30, 2010 8:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > > Interesting -- I don't see any reprobing of the output. > > > Unfortunately, the debug output does not really provide > > > much insight of what is going on at the moment. I'll see > > > if I can add some more instrumentation to try track this > > > down. Not sure if I can do this today. > > > > Can you give some hints which source files/functions are primarily > > involved here? May be we can do a little code review. > > I'd start with ./action.[ch] and obviously ompipe itself. It may be > useful to > see what/how ompipe returns. You can also set debug mode to do a > function > trace (see debug doc), this requires --enable-rtinst. > > Rainer > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 14:52:55 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 14:52:55 +0200 Subject: [rsyslog] [PATCH] break potential infinite loop in actionDoRetry In-Reply-To: <4C527173.9090805@dresearch.de> References: <4C527173.9090805@dresearch.de> Message-ID: <1280494375-11930-1-git-send-email-sledz@dresearch.de> If a module always returns RS_RET_OK (like ompipe does) the actionDoRetry loop may not have leaved faked ACT_STATE_SUSP state in case iResumeOKinRow had ever reached a count of 1000. Signed-off-by: Steffen Sledz --- action.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/action.c b/action.c index 32a07dc..90ec1bf 100644 --- a/action.c +++ b/action.c @@ -508,6 +508,7 @@ static rsRetVal actionDoRetry(action_t *pThis, time_t ttNow) iRet = pThis->pMod->tryResume(pThis->pModData); if((pThis->iResumeOKinRow > 999) && (pThis->iResumeOKinRow % 1000 == 0)) { bTreatOKasSusp = 1; + pThis->iResumeOKinRow = 0; } else { bTreatOKasSusp = 0; } -- 1.6.4.2 From ryan.b.lynch at gmail.com Fri Jul 30 15:28:45 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 09:28:45 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <4C456476.4010703@redhat.com> References: <4C456476.4010703@redhat.com> Message-ID: On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > read data from SOCK_DGRAM. This has two consequences: first, to be able > to attach rsyslog on the host end one first needs to copy the data > between the two socket types, e.g. using socat. Second, messages longer > than 1024 characters are sometimes split into two. The second message is > thus missing the syslog header and the receiving rsyslogd doesn't know > where to file it. Is there a recommended workaround for those things > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > SOCK_STREAM)? I ran into a similar problem. Doesn't it seem wierd that RSyslog: - can write TO a pipe, but it can't natively read FROM a pipe. - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. The only protocols that Rsyslog can both read to AND write from are network sockets (UDP, TCP, RELP) and real files. Maybe everybody just uses UDP for local intra-daemon message routing? I guess real file I/O would work, too, but that seems kind of ugly to me (lots of needless I/O to a particularly slow subsystem). Or maybe there hasn't been much demand to support multiple local daemon instances with combined message processing. I decided to use the 'omprog' module to write via 'socat' to the '/dev/log' socket. I like your method, too. And thank you for mentioning 'socat', that's what gave me the idea to go in this direction, in the first place. > 2) I seem to be unable to get the forwarding template right. For network > forwarding (which is also supported in Anaconda), simply putting no > explicit formatting does the trick: > *.* @@ some.host > The received logs can be matched for anything: severity, facility, > hostname and programname. > > This is not the case when logs are forwarded through the character device: > *.* /dev/virtio_ports/port_name > > Using the implicit formatting the receiving syslog won't parse the > programname. > > I tried using the predefined ForwardFormat but then the receiving > rsyslogd parsed hostname as the programname and the programname remains > part of the final message. Is that the expected behavior? What worked > for me in the end was creating a template based on the ForwardFormat but > with the %HOSTNAME% part omitted: I can live with that for know since I > know the message came from a certain socket so it can be only one host. > Still: it seems weird there's no forwarding format provided that would > retain 100% of the information parsable by another rsyslog reading from > a socket. I'm probably just missing something? I don't think the problem is your forwarding format--I don't think it's possible for RSyslog to handle a HOSTNAME field, properly, in messages received via socket. Based on my own tests, I believe that 'imuxsock' and 'imudp' use different logic to parse incoming messages. 'imuxsock' always assumes that the hostname is the local host, so it doesn't have the conditional logic to differentiate between "forwarded" messages (which have an extra HOSTNAME field between the timestamp and tag) versus regular local messages (no HOSTNAME). This is a pretty reasonable assumption, really--the local UNIX socket doesn't traditionally have any way to receive messages forwarded from other hosts. Rainer could probably confirm this, or we could compare those two modules' sources. RSyslog is a fantastic piece of software, and its feature set has come a long way. But all of Rainer's excellent work has expanded our imaginations about what Syslog can do, and maybe our imaginations are advancing faster than he can code new features. -Ryan From sean at conman.org Sat Jul 31 01:05:20 2010 From: sean at conman.org (Sean Conner) Date: Fri, 30 Jul 2010 19:05:20 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: References: <4C456476.4010703@redhat.com> Message-ID: <20100730230520.GA21655@brevard.conman.org> It was thus said that the Great Ryan Lynch once stated: > On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > > read data from SOCK_DGRAM. This has two consequences: first, to be able > > to attach rsyslog on the host end one first needs to copy the data > > between the two socket types, e.g. using socat. Second, messages longer > > than 1024 characters are sometimes split into two. The second message is > > thus missing the syslog header and the receiving rsyslogd doesn't know > > where to file it. Is there a recommended workaround for those things > > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > > SOCK_STREAM)? > > I ran into a similar problem. Doesn't it seem wierd that RSyslog: > - can write TO a pipe, but it can't natively read FROM a pipe. > - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. > The only protocols that Rsyslog can both read to AND write from are > network sockets (UDP, TCP, RELP) and real files. > > Maybe everybody just uses UDP for local intra-daemon message routing? The default syslog() call uses a local UDP socket (usually '/dev/log') and there's no overhead a programmer has to do in order to call syslog() (I mean, a programm can call openlog(), but it's not mandatory). So programs (other than syslogd) use local Unix UDP socket. For talking to other syslog daemons, I think the typical scenario is to run one locally, and any forwarding is done via an actual network socket. I never thought of doing relaying to another Unix socket. I know in my case (at home) I send a copy of all logs to 239.255.0.1, which is a multicast address (local segment only) so that I can run other instances of syslogd (or in my case, my own syslogd) on that address (on any machine on the segment); I can even run multiple copies locally listening to that address without issue. Adding support for multicast addresses was simple (about 32 lines of code, but it also supports IPv6). > I guess real file I/O would work, too, but that seems kind of ugly to > me (lots of needless I/O to a particularly slow subsystem). Or maybe > there hasn't been much demand to support multiple local daemon > instances with combined message processing. I decided to use the > 'omprog' module to write via 'socat' to the '/dev/log' socket. One issue with using files is that you end up having to poll a file for input. Normally, when you read from files, reading 0 bytes means you've hit the end of the file (and read() doesn't block on end-of-file for actual files). In this case (and in the case if doing a 'tail -f') you have to keep reading the file for more input once you hit the end. In the case of 'tail -f' (and for this, I checked the actual source code) it just sleeps for a second everytime it reads 0 bytes from a file. > I like your method, too. And thank you for mentioning 'socat', that's > what gave me the idea to go in this direction, in the first place. > > > > 2) I seem to be unable to get the forwarding template right. For network > > forwarding (which is also supported in Anaconda), simply putting no > > explicit formatting does the trick: > > *.* @@ some.host > > The received logs can be matched for anything: severity, facility, > > hostname and programname. > > > > This is not the case when logs are forwarded through the character device: > > *.* /dev/virtio_ports/port_name > > > > Using the implicit formatting the receiving syslog won't parse the > > programname. > > > > I tried using the predefined ForwardFormat but then the receiving > > rsyslogd parsed hostname as the programname and the programname remains > > part of the final message. Is that the expected behavior? What worked > > for me in the end was creating a template based on the ForwardFormat but > > with the %HOSTNAME% part omitted: I can live with that for know since I > > know the message came from a certain socket so it can be only one host. > > Still: it seems weird there's no forwarding format provided that would > > retain 100% of the information parsable by another rsyslog reading from > > a socket. I'm probably just missing something? > > I don't think the problem is your forwarding format--I don't think > it's possible for RSyslog to handle a HOSTNAME field, properly, in > messages received via socket. I agree, but replace "rsyslog" with "any syslog" (it's why in my own syslogd I only send IP addresses and not hostnames). > Based on my own tests, I believe that 'imuxsock' and 'imudp' use > different logic to parse incoming messages. 'imuxsock' always assumes > that the hostname is the local host, so it doesn't have the > conditional logic to differentiate between "forwarded" messages (which > have an extra HOSTNAME field between the timestamp and tag) versus > regular local messages (no HOSTNAME). This is a pretty reasonable > assumption, really--the local UNIX socket doesn't traditionally have > any way to receive messages forwarded from other hosts. If that's the case, then I'm surprised; in my syslogd, all messages (reguardless of source) go through the same parsing engine (then again, I only handle RFC-3164 style messages). I handle messages from the local socket by setting the "hostname" to the actual socket filename; I could have used "localhost" but I felt the actual socket filename would be better in those rare instances where you had a chroot'ed program that wrote to its own "/dev/log" socket so one could see which chroot'ed environment the log message was generated under. -spc From ryan.b.lynch at gmail.com Sat Jul 31 04:23:33 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 22:23:33 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <20100730230520.GA21655@brevard.conman.org> References: <4C456476.4010703@redhat.com> <20100730230520.GA21655@brevard.conman.org> Message-ID: Hi, Sean, On Fri, Jul 30, 2010 at 19:05, Sean Conner wrote: > It was thus said that the Great Ryan Lynch once stated: >> Maybe everybody just uses UDP for local intra-daemon message routing? > > ?The default syslog() call uses a local UDP socket (usually '/dev/log') and > there's no overhead a programmer has to do in order to call syslog() (I > mean, a programm can call openlog(), but it's not mandatory). ?So programs > (other than syslogd) use local Unix UDP socket. When I wrote "UDP", I could have been clearer--I meant "UDP over a loopback IP connection", not over a local socket. That's the distinction: Are you calling sendto() to a listener on 127.0.01, or to a listener on /dev/log? The point here is that RSyslog cannot natively send its output to /dev/log (as far as I can tell). RSyslog can do IPC via a '*.* @127.0.0.1' action, but there's no corresponding '*.* @/dev/log' action, at least as far as I know. So if you want to forward messages between daemons, you HAVE to listen on the loopback IP, unless you're willing to use something like 'omprog' or pipe output, both of which require invoking an external program like 'socat' or creating a named pipe. (It works, but it's messier and more complicated--performance might be worse, too.) For Ales's KVM application, there may be a worse problem: His virtual machines might not have working network interfaces at all times, such as during provisioning/build. That's why the distinction of network socket vs. local socket matters--if you don't have any networking interfaces up, or you have security concerns about rogue local processes sending malicious traffic to the 127.0.0.1 listener, then the lack of a "send to local socket" capability makes life a little more difficult. -Ryan From rgerhards at hq.adiscon.com Thu Jul 1 08:27:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 01 Jul 2010 08:27:57 +0200 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: <1277965677.18305.13.camel@localhost> On Wed, 2010-06-30 at 17:00 -0400, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: > > > > Note that being an evolution, any currently existing rsyslog.conf would also > > be a valid new conf (via the *same* parser). I have not thought out the full > > semantics and thousand other things that need to be thought of -- this > > actually opened up a can of worms ;) However, I find the proposed format > > seems to be a good compromise between the need to preserve and the need to > > move on, and between the need for simplicity and the need for power. > > > > As such, before I invest even more time into that format, I'd like to get > > some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). Don't mistake "general programming language" via "config language for a specialised engine". Full ACK for "general programming language". > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints Don't think in terms of "constraints", but in terms of "options" and "levels of (programming) freedom". "Constraints" sounds like a bad thing from legacy. In fact, what I need is the ability to do some very special, high performance things ;) > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. OK, Lua again. I've now written up why I don't consider Lua (or any other general-purpose language) a vital alternative for use in rsyslog: http://blog.gerhards.net/2010/07/why-i-think-lua-is-no-solution-for.html Please look carefully at the arguments, especially the facts that a) I do like things like Lua, but not in this context b) Lua misses support for SIMD processing c) Lua does not permit to execute based in the inherent partial order of config statements > If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. Well, that's a primary difference: speed is on of the *prime* concerns in rsyslog. I have looked at your implementation. Of course, I could have saved myself roughly 3 to 4 years of work if I used the same approach -- and rsyslog would most probably not be the alternative to syslog-ng it currently is. Also, I question if the typical sysadmin will actually like the format that you promote. All of the examples really scared me away. I have quoted the replacement for a standard red hat syslog.conf after my signature so that the other list members can do their own judgment. Rainer Now the replacement for a standard Red Hat syslog.conf with syslogintr (taken from above-mentioned URL, file "readhat.lua" inside the offered tarball): -- *************************************************************** -- -- Copyright 2010 by Sean Conner. All Rights Reserved. -- -- This program is free software: you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation, either version 3 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program. If not, see . -- -- Comments, questions and criticisms can be sent to: sean at conman.org -- -- ****************************************************************** -- -- A file the duplicates a default install of RedHat and their syslog.conf -- file. All functions not labeled as "local" are called directly via the -- runtime engine. -- -- cleanup() - called when the daemon exits -- reload_signal() - called when the program recieves a SIGHUP -- log() - called each time the daemon receives a message -- -- This is provided as a means to replace syslogd with a drop in -- replacement, but with the ability to expand upon the functionality as -- required. -- -- ******************************************************************* function cleanup() messages:close() secure:close() maillog:close() cron:close() spooler:close() boot:close() end -- ********************************************************************* local function openfiles() messages = io.open("/var/log/messages","a") or io.stdout secure = io.open("/var/log/secure" ,"a") or io.stdout maillog = io.open("/var/log/maillog" ,"a") or io.stdout cron = io.open("/var/log/cron" ,"a") or io.stdout spooler = io.open("/var/log/spooler" ,"a") or io.stdout boot = io.open("/var/log/boot" ,"a") or io.stdout end openfiles() -- ********************************************************************* function reload_signal() cleanup() openfiles() end -- ********************************************************************* local function logfile(msg,file,flushp) local flushp = flushp or false if msg.remote == false then msg.host = "localhost" end file:write(string.format( "%s %s %s[%d]: %s\n", os.date("%b %d %H:%M:%S",msg.timestamp), msg.host, msg.program, msg.pid, msg.msg )) if flushp then file:flush() end end -- ****************************************************************** local function everybody(msg) local out = io.popen("/usr/bin/wall","w") logfile(msg,out) out:close() end -- ****************************************************************** function log(msg) if msg.level == 'info' or msg.level == 'notice' or msg.level == 'warn' or msg.level == 'err' or msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then if msg.facility ~= 'mail' and msg.facility ~= 'auth2' and msg.facility ~= 'cron' and msg.facility ~= 'local6' then logfile(msg,messages) end end if msg.facility == 'auth2' then logfile(msg,secure) end if msg.facility == 'mail' then logfile(msg,maillog,true) end if msg.facility == 'cron' then logfile(msg,cron) end if msg.level == 'emerg' then everybody(msg) end if msg.facility == 'uucp' or msg.facility == 'news' then if msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then logfile(msg,spooler) end end if msg.facility == 'local7' then logfile(msg,boot) end end -- ******************************************************************** From raja.rhel5 at gmail.com Thu Jul 1 10:10:31 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 13:40:31 +0530 Subject: [rsyslog] rsyslog Message-ID: hi, I have configured rsylog and mysql server..everything working fine. But i found after examining it for 1 week, all the logs are consuming lot of space.so i decided not to delete all the logs in database? how can i do it? how to redirect only important logs...kern,errors,warnings...? Thanks in advance. raja antony From tomasz.glowacki at pseinfo.pl Thu Jul 1 10:37:44 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 10:37:44 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 Message-ID: <8610433990.20100701103744@pseinfo.pl> Hi everyone, Web forum seems dead for a while, so I decided to post to mailing list. I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to a files based on facility and some simple forwarding using omudpspoof. That is all I have plus generic system logging. Default as much as it can be ;) rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while 5.5.0 seems to work quite normal but with CPU load for the process reaching 99%. This is simple Pentium III 833 machine. I did some sort of debuging. I disabled /dev/xconsole section, immark module as sugested. No change at all. Then, ran rsyslogd with -d and there were no errors at all, normal initialization and no further messages at all. After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of the files started to grow about 1-2 megabytes every few seconds with something like that: clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 this is tail from that rapidly growing file. How can I solve this? What kind of information should I provide to solve the problem? :) I'm open and ready for further debugging. Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with the same config besides that it doesn't support omudpspoof module, so forwarding of messages is quite useless.. -- Best regards, Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl From david at lang.hm Thu Jul 1 11:06:03 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:06:03 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: I ran into this same problem and finally discovered that it was because there were two sets of rsyslog modules, the old ubuntu defaults and the ones I compiled. the wrong ones were being found and problems resulted. you may find that you have files in /usr/lib/rsyslog and in /usr/local/lib/rsyslog delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. rsyslog needs to eventually gain the ability to version the modules and report when the wrong version module is loaded. But at the moment this is not available. David Lang On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Date: Thu, 1 Jul 2010 10:37:44 +0200 > From: utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi everyone, > > Web forum seems dead for a while, so I decided to post to mailing > list. > > I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under > Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to > a files based on facility and some simple forwarding using omudpspoof. > That is all I have plus generic system logging. Default as much as it > can be ;) > > rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while > 5.5.0 seems to work quite normal but with CPU load for the process > reaching 99%. This is simple Pentium III 833 machine. > > I did some sort of debuging. I disabled /dev/xconsole section, immark > module as sugested. No change at all. > > Then, ran rsyslogd with -d and there were no errors at all, normal > initialization and no further messages at all. > > After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of > the files started to grow about 1-2 megabytes every few seconds with > something like that: > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 > > this is tail from that rapidly growing file. > > How can I solve this? What kind of information should I provide to > solve the problem? :) I'm open and ready for further debugging. > > Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with > the same config besides that it doesn't support omudpspoof module, so > forwarding of messages is quite useless.. > > > > -- > Best regards, > Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 1 11:08:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:08:15 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: On Wed, 30 Jun 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). one key thing is that this language is not a script to be executed as logs come in, it's a config file that will get read in to configure rsyslog internals (compiiled into the rsyslog internal function calls effectivly) no off-the-shelf language is fast enough for the data rates that rsyslog is able to reach today. David Lang > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints and I've certainly seen (and worked) with worse configuration > files (sendmail.cf comes to mind). > > One last thing though, in looking over your proposed syntax for > RainerScript I see that's it already is awfully close to Lua: > > ruleset remote10515 { > if pri("mail.*") then { > action(type="omfile" file="/var/log/remote10514") > action(use="dynfile") > action(type="udpfwd" action.execonlyonce="5sec" > target="192.168.1.2" port="514") > } > action(type="udpfwd" target="192.168.1.3" > action.previousfailed="on") > action(type="omfile" file="/var/log/catchall") > if $severity == 'error' and $msg contains 'Link 2' then > action(type="ommail" server="192.168.1.3" > from="someone at example.net" > to="ops at example.net" > subject="###error \"detected\"###") > } > > could be translated into Lua as: > > function remote10515() > if pri("mail.*") then > action { type="omfile" , file="/var/log/remote10514" } > action { use="dynfile" } > action { > type = "udpfwd" , > action = { execonlyonce="5sec" }, > target = "192.168.1.2", > port = 514 > } > end > > action { > type="udpfwd" , > target="192.168.1.3" , > action = { previousfailed = true } > } > action { type="omfile" , file="/var/log/catchall" } > if severity == 'error' and string.find(msg,'Link 2') then > action { > type="ommail", > server="192.168.1.3", > from="someone at example.net", > to="ops at example.net", > subject=[[###error "detected"###]] > } > end > end > > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. > > -spc (which includes the processing of multiple thin logs into one fat > log) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From tomasz.glowacki at pseinfo.pl Thu Jul 1 11:57:33 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 11:57:33 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <6410167759.20100701115733@pseinfo.pl> Witam, Thursday, July 1, 2010, 11:06:03 AM, you wrote: > I ran into this same problem and finally discovered that it was because > there were two sets of rsyslog modules, the old ubuntu defaults and the > ones I compiled. the wrong ones were being found and problems resulted. > you may find that you have files in /usr/lib/rsyslog and in > /usr/local/lib/rsyslog > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. > rsyslog needs to eventually gain the ability to version the modules and > report when the wrong version module is loaded. But at the moment this is > not available. I don't think it is a good solution. If I compile 5.5.0 with --prefix=/my/directory and then make install is done to that directory rsyslogd should read libs from there (and in fact - is doing that because omudpspoof module is working). Not from /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. Why rsyslogd is searching for other libs elsewhere than in it's install directory? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Dzia? Sieci tel. (022) 3401597, (601) 672872 From rgerhards at hq.adiscon.com Thu Jul 1 13:55:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 13:55:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 11:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 11:06:03 AM, you wrote: > > > I ran into this same problem and finally discovered that it was > because > > there were two sets of rsyslog modules, the old ubuntu defaults and > the > > ones I compiled. the wrong ones were being found and problems > resulted. > > > you may find that you have files in /usr/lib/rsyslog and in > > /usr/local/lib/rsyslog > > > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > package. > > > rsyslog needs to eventually gain the ability to version the modules > and > > report when the wrong version module is loaded. But at the moment > this is > > not available. > > I don't think it is a good solution. > > If I compile 5.5.0 with --prefix=/my/directory and then make install > is done to that directory rsyslogd should read libs from there (and in > fact - is doing that because omudpspoof module is working). Not from > /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > > Why rsyslogd is searching for other libs elsewhere than in it's > install directory? It depends on how you configure the running system (not the build system). There is a command line switch as well as a config directive that tells form where to load modules. Distros usually set their defaults with these directives. To the root question: this may be caused by a bug. I suggest that you check out the current master branch, it may work (which would be an indication of a bug). I did some changes to the code, and I had the impression that what you report could actually something that happens with the older codebase (5.5.5 in this view being "older" ;)). HTH Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 14:51:43 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 14:51:43 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> Message-ID: <235067282.20100701145143@pseinfo.pl> Witam, Thursday, July 1, 2010, 1:55:58 PM, you wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) >> Sent: Thursday, July 01, 2010 11:58 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 >> >> Witam, >> >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: >> >> > I ran into this same problem and finally discovered that it was >> because >> > there were two sets of rsyslog modules, the old ubuntu defaults and >> the >> > ones I compiled. the wrong ones were being found and problems >> resulted. >> >> > you may find that you have files in /usr/lib/rsyslog and in >> > /usr/local/lib/rsyslog >> >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu >> package. >> >> > rsyslog needs to eventually gain the ability to version the modules >> and >> > report when the wrong version module is loaded. But at the moment >> this is >> > not available. >> >> I don't think it is a good solution. >> >> If I compile 5.5.0 with --prefix=/my/directory and then make install >> is done to that directory rsyslogd should read libs from there (and in >> fact - is doing that because omudpspoof module is working). Not from >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. >> >> Why rsyslogd is searching for other libs elsewhere than in it's >> install directory? > It depends on how you configure the running system (not the build system). > There is a command line switch as well as a config directive that tells form > where to load modules. Distros usually set their defaults with these > directives. Ok, which command line switch do you mean? And which config directive? :) I'll try to clarify: where from rsyslogd is getting it's libs by default? (as manual page says: " prefix/lib/rsyslog Default directory for rsyslogd modules. The prefix is specified during compilation (e.g. /usr/local)." I would like to know if rsyslogd is REALLY getting it's libs from prefix path. Just not to mess my system completly. > To the root question: this may be caused by a bug. I suggest that you check > out the current master branch, it may work (which would be an indication of a > bug). I did some changes to the code, and I had the impression that what you > report could actually something that happens with the older codebase (5.5.5 > in this view being "older" ;)). I'll try that but rather as my "last resort".... I would love to see 5.4.0 or 5.5.5 working properly here.... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 14:55:08 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 14:55:08 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 2:52 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 1:55:58 PM, you wrote: > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > >> Sent: Thursday, July 01, 2010 11:58 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > >> > >> Witam, > >> > >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: > >> > >> > I ran into this same problem and finally discovered that it was > >> because > >> > there were two sets of rsyslog modules, the old ubuntu defaults > and > >> the > >> > ones I compiled. the wrong ones were being found and problems > >> resulted. > >> > >> > you may find that you have files in /usr/lib/rsyslog and in > >> > /usr/local/lib/rsyslog > >> > >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > >> package. > >> > >> > rsyslog needs to eventually gain the ability to version the > modules > >> and > >> > report when the wrong version module is loaded. But at the moment > >> this is > >> > not available. > >> > >> I don't think it is a good solution. > >> > >> If I compile 5.5.0 with --prefix=/my/directory and then make install > >> is done to that directory rsyslogd should read libs from there (and > in > >> fact - is doing that because omudpspoof module is working). Not from > >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > >> > >> Why rsyslogd is searching for other libs elsewhere than in it's > >> install directory? > > > It depends on how you configure the running system (not the build > system). > > There is a command line switch as well as a config directive that > tells form > > where to load modules. Distros usually set their defaults with these > > directives. > > Ok, which command line switch do you mean? And which config directive? > :) I'll check the doc as soon as I have time to do so... Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:16:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:16:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> Message-ID: <1989837614.20100701151634@pseinfo.pl> Hi, Thursday, July 1, 2010, 2:55:08 PM, you wrote: > I'll check the doc as soon as I have time to do so... If you meant $ModDir that doesn't change much... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:18:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:18:35 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:17 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi, > > Thursday, July 1, 2010, 2:55:08 PM, you wrote: > > > > I'll check the doc as soon as I have time to do so... > > If you meant $ModDir that doesn't change much... Ah, yes, that's the name of it. The startup option is probably something like -m or -M. The simplest thing probably is to check your startup script (wherever that is located on your distro). Rainer From marc.schiffbauer at mightycare.de Thu Jul 1 15:04:04 2010 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 1 Jul 2010 15:04:04 +0200 Subject: [rsyslog] rsyslog In-Reply-To: References: Message-ID: <201007011504.04602.marc.schiffbauer@mightycare.de> Hi raja, read the docs on the homepage. you can select what to put into the database in the same way as you select what goes into which logfile. for deletin old log you will have to issue a SQL command uisng a mysql client (DELETE FROM WHERE <= ) -marc On Thursday 01 July 2010 10:10:31 Raja antony wrote: > hi, > > I have configured rsylog and mysql server..everything working fine. > > But i found after examining it for 1 week, all the logs are consuming lot > of space.so i decided not to delete all the logs in database? > > how can i do it? > > how to redirect only important logs...kern,errors,warnings...? > > Thanks in advance. > raja antony > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux :: Virtualization Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/impressum From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:24:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:24:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> Message-ID: <1987371782.20100701152434@pseinfo.pl> Witam, Thursday, July 1, 2010, 3:18:35 PM, you wrote: > Ah, yes, that's the name of it. The startup option is probably something like > -m or -M. The simplest thing probably is to check your startup script > (wherever that is located on your distro). Yep, -M. Tried that too. So, I could be sure that this is not version conflict. Forcing loading from exact path does the same as default - CPU hog on 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:26:21 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:26:21 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:25 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 3:18:35 PM, you wrote: > > > Ah, yes, that's the name of it. The startup option is probably > something like > > -m or -M. The simplest thing probably is to check your startup script > > (wherever that is located on your distro). > > Yep, -M. Tried that too. So, I could be sure that this is not version > conflict. Forcing loading from exact path does the same as default - > CPU hog on 99% That's what I suspected... So we need to see if it is already fixed or not (master branch). If not, we need to look at the debug log and try to find out what is going on. Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 16:33:58 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 16:33:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> Message-ID: <518726404.20100701163358@pseinfo.pl> Hi, Thursday, July 1, 2010, 3:26:21 PM, you wrote: > That's what I suspected... > So we need to see if it is already fixed or not (master branch). If not, we > need to look at the debug log and try to find out what is going on. Ok, that's my next try. But, I think I'm getting close to the goal. When I comment: $PrivDropToUser syslog $PrivDropToGroup adm and run the rsyslogd via sudo - it's running perfect with no CPU hog. It runs as root then. Uncommenting that gives CPU hog but running as user syslog. I've checked file priviledges and they're ok, same as directories, wherever rsyslogd needs to read/write. As I said, 4.2.0 running on the same config, same priviledge level works well. -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From james at linux-source.org Thu Jul 1 17:00:23 2010 From: james at linux-source.org (James Corteciano) Date: Thu, 1 Jul 2010 23:00:23 +0800 Subject: [rsyslog] PHP error logs In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F3E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> Message-ID: Hi Rainer, The following are my settings in remote php server. [/etc/rsyslog.conf] $ModLoad imfile $InputFileName /var/log/php/example.com/error_log $InputFileTag example.com.php.error: $InputFileStateFile stat-example.com $InputFileSeverity error $InputFileFacility local6 $InputRunFileMonitor $InputFilePollingInterval 1 local6.* @192.168.10.125 The problem is it takes 10 seconds to received the php error logs on central syslog server. How can I speed up the receiving of logs on syslog server? Do I need to add/modify on any settings? Thanks. Regards, James On Wed, Jun 30, 2010 at 8:22 PM, Rainer Gerhards wrote: > Hi James, > > well, after imfile reads the messages, they *are* already present in > rsyslog > and so they are in the syslog server. It is not a push model but rather a > pull model (the syslog server pulls the messages from the file instead of > them being pushed to it). > > If you mean how to forward them to a remote server: that's business as > usual, > so you can just do > > *.* @remote-server > > ..or use any other forwarding action. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > Sent: Wednesday, June 30, 2010 1:43 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] PHP error logs > > > > Hi Rainer, > > > > How to push the logs to syslog server? > > > > On Wed, Jun 30, 2010 at 4:49 PM, Rainer Gerhards > > wrote: > > > > > Hi James, > > > > > > if I understood you correctly, imfile may be your friend: > > > > > > http://www.rsyslog.com/doc-imfile.html > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > > > Sent: Wednesday, June 30, 2010 5:32 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] PHP error logs > > > > > > > > Hi All, > > > > > > > > I know this is out of topic here in mailing list but I couldn't get > > > > into php > > > > mailing list. > > > > > > > > Anyone have try to log php errors and forwarded it to centralized > > > > rsyslog > > > > server? I can received logs locally from /var/log/messages > > (specified > > > > from > > > > /etc/php.ini) but I want to forward it to centralized log. > > > > > > > > Thanks. > > > > > > > > Regards, > > > > James > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 1 19:02:36 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 10:02:36 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <518726404.20100701163358@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> <518726404.20100701163358@pseinfo.pl> Message-ID: On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Hi, > > Thursday, July 1, 2010, 3:26:21 PM, you wrote: > > >> That's what I suspected... > >> So we need to see if it is already fixed or not (master branch). If not, we >> need to look at the debug log and try to find out what is going on. > > Ok, that's my next try. But, I think I'm getting close to the > goal. > > When I comment: > $PrivDropToUser syslog > $PrivDropToGroup adm > > and run the rsyslogd via sudo - it's running perfect with no CPU hog. > It runs as root then. > > Uncommenting that gives CPU hog but running as user syslog. I've > checked file priviledges and they're ok, same as directories, wherever > rsyslogd needs to read/write. > > As I said, 4.2.0 running on the same config, same priviledge level works well. when I had this problem, logging *.* somewhere showed me 200,000 logs/sec being generated by an error message saying that rsyslog was not allowed to read something. do you have anything similar in your logs? David Lang From epiphani at gmail.com Thu Jul 1 19:14:12 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Thu, 1 Jul 2010 13:14:12 -0400 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: 2010/7/1 G?owacki, Tomasz (INFO) : > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 This looks like a bug. Can you provide a list of your environment variables on startup? This looks like debug logs are trying to be sent to stdout - which is failing because stdout is closed (as it should be for a daemonized application). Something somewhere has flipped debugging information on, and yet still forked the process off of the terminal. Configuring the app this way should be impossible - if its something in configuration... if not, its just a bug where debug is being properly activated after a fork. -Aaron From rgerhards at hq.adiscon.com Thu Jul 1 20:11:39 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 20:11:39 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> > This looks like debug logs are trying to be sent to stdout - which is > failing because stdout is closed (as it should be for a daemonized > application). Something somewhere has flipped debugging information > on, and yet still forked the process off of the terminal. Configuring > the app this way should be impossible - if its something in > configuration... if not, its just a bug where debug is being properly > activated after a fork. Good catch! I was so preoccupied with the known issue of action error not being properly acted on by the transaction processor, I did not notice the actual data. A full debug log should help to find out what is going on. Thanks! Rainer From raja.rhel5 at gmail.com Fri Jul 2 07:59:49 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 22:59:49 -0700 Subject: [rsyslog] Raja antony wants to chat Message-ID: ----------------------------------------------------------------------- Raja antony wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI You'll need to click this link to be able to chat with Raja antony. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with Raja antony, visit: http://mail.google.com/mail/a-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From tomasz.glowacki at pseinfo.pl Fri Jul 2 09:57:04 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 09:57:04 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <661878047.20100702095704@pseinfo.pl> Witam, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Is your list allowing attachments? Or pasting huge amount of debug here? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 14:00:55 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 14:00:55 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <1571565725.20100702140055@pseinfo.pl> Hi, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Here it is, debug: http://pastebin.com/RXQim1yh it ends just after dropping priviledges. No more messages appear. CPU is at 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 16:42:12 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 16:42:12 +0200 Subject: [rsyslog] [solved] - high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <1571565725.20100702140055@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> <1571565725.20100702140055@pseinfo.pl> Message-ID: <585116747.20100702164212@pseinfo.pl> Witam, Friday, July 2, 2010, 2:00:55 PM, you wrote: > Here it is, debug: > http://pastebin.com/RXQim1yh > it ends just after dropping priviledges. No more messages appear. CPU > is at 99% Ok, problem is gone now. If the config directive KLogPath was set to: $KLogPath /var/run/rsyslog/kmsg CPU has been hogged. Changing it to /proc/kmsg solved the problem completly. There were no file at /var/run/rsyslog/kmsg created during daemon start. Why? I dunno. The problem is described shortly at: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/401433 -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From P at draigBrady.com Tue Jul 6 14:52:44 2010 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Tue, 06 Jul 2010 13:52:44 +0100 Subject: [rsyslog] TCP connections not being closed Message-ID: <4C33271C.70805@draigBrady.com> I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 server on debian. Eventually the server exhausts it's connections as there are multiple connections from each client. Taking 1 client in particular: server# lsof -n -i at 10.132.8.1 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME rsyslogd 29775 root 325u IPv4 81017793 TCP 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) rsyslogd 29775 root 515u IPv4 81085917 TCP 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) rsyslogd 29775 root 531u IPv4 81187589 TCP 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) rsyslogd 29775 root 568u IPv4 81263960 TCP 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) rsyslogd 29775 root 570u IPv4 81275186 TCP 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) rsyslogd 29775 root 573u IPv4 81300023 TCP 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) rsyslogd 29775 root 574u IPv4 81412888 TCP 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) rsyslogd 29775 root 588u IPv4 81503100 TCP 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) rsyslogd 29775 root 591u IPv4 81559427 TCP 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) rsyslogd 29775 root 593u IPv4 81593574 TCP 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) rsyslogd 29775 root 595u IPv4 81624236 TCP 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) rsyslogd 29775 root 599u IPv4 81631713 TCP 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) rsyslogd 29775 root 601u IPv4 81641244 TCP 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) rsyslogd 29775 root 603u IPv4 82260661 TCP 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) rsyslogd 29775 root 684u IPv4 84358985 TCP 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) rsyslogd 29775 root 699u IPv4 84499197 TCP 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) rsyslogd 29775 root 701u IPv4 84557429 TCP 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) rsyslogd 29775 root 714u IPv4 86973034 TCP 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) rsyslogd 29775 root 823u IPv4 88591917 TCP 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) rsyslogd 29775 root 999u IPv4 90314222 TCP 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) rsyslogd 29775 root 1003u IPv4 125443032 TCP 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) server# ssh 10.132.8.1 lsof -n -i :514 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsyslogd 1595 root 8u IPv4 59789 0t0 TCP 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) So you can see that the client has only 1 connection open, while the server has many. Could the server be changed to close connections old connections to a particular IP? I guess that would have issues for NATing, or perhaps the server could just timeout the TCP connections after a period of inactivity? Any ideas appreciated. cheers, P?draig. For my own reference, these seem closely related: http://kb.monitorware.com/post5056.html http://bugzilla.adiscon.com/show_bug.cgi?id=190 From ktm at rice.edu Tue Jul 6 15:04:51 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:04:51 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C33271C.70805@draigBrady.com> References: <4C33271C.70805@draigBrady.com> Message-ID: <20100706130451.GI341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 01:52:44PM +0100, P??draig Brady wrote: > I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 > server on debian. Eventually the server exhausts it's connections as > there are multiple connections from each client. > > Taking 1 client in particular: > > server# lsof -n -i at 10.132.8.1 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > rsyslogd 29775 root 325u IPv4 81017793 TCP > 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) > rsyslogd 29775 root 515u IPv4 81085917 TCP > 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) > rsyslogd 29775 root 531u IPv4 81187589 TCP > 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) > rsyslogd 29775 root 568u IPv4 81263960 TCP > 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) > rsyslogd 29775 root 570u IPv4 81275186 TCP > 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) > rsyslogd 29775 root 573u IPv4 81300023 TCP > 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) > rsyslogd 29775 root 574u IPv4 81412888 TCP > 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) > rsyslogd 29775 root 588u IPv4 81503100 TCP > 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) > rsyslogd 29775 root 591u IPv4 81559427 TCP > 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) > rsyslogd 29775 root 593u IPv4 81593574 TCP > 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) > rsyslogd 29775 root 595u IPv4 81624236 TCP > 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) > rsyslogd 29775 root 599u IPv4 81631713 TCP > 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) > rsyslogd 29775 root 601u IPv4 81641244 TCP > 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) > rsyslogd 29775 root 603u IPv4 82260661 TCP > 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) > rsyslogd 29775 root 684u IPv4 84358985 TCP > 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) > rsyslogd 29775 root 699u IPv4 84499197 TCP > 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) > rsyslogd 29775 root 701u IPv4 84557429 TCP > 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) > rsyslogd 29775 root 714u IPv4 86973034 TCP > 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) > rsyslogd 29775 root 823u IPv4 88591917 TCP > 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) > rsyslogd 29775 root 999u IPv4 90314222 TCP > 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) > rsyslogd 29775 root 1003u IPv4 125443032 TCP > 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) > > server# ssh 10.132.8.1 lsof -n -i :514 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > rsyslogd 1595 root 8u IPv4 59789 0t0 TCP > 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) > > So you can see that the client has only 1 connection open, while the > server has many. Could the server be changed to close connections old > connections to a particular IP? I guess that would have issues for > NATing, or perhaps the server could just timeout the TCP connections > after a period of inactivity? > > Any ideas appreciated. > > cheers, > P??draig. > > For my own reference, these seem closely related: > http://kb.monitorware.com/post5056.html > http://bugzilla.adiscon.com/show_bug.cgi?id=190 Attempts to ameliorate these types of problems by kludging the server always end badly. I do not know anything about the RELP protocol, but it sounds like the client has a bug as well as possibly the server. Does it happen without RELP? If not, can you run without RELP? If not, you may need to get out the debugger. :) Cheers, Ken From P at draigBrady.com Tue Jul 6 15:16:24 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 14:16:24 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706130451.GI341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> Message-ID: <4C332CA8.8030301@draigBrady.com> On 06/07/10 14:04, Kenneth Marshall wrote: > Attempts to ameliorate these types of problems by kludging the > server always end badly. I do not know anything about the RELP > protocol, but it sounds like the client has a bug as well as > possibly the server. True. I've not looked into why the client is not tearing down connections, but in practice the clients can always just disappear. > Does it happen without RELP? If not, can > you run without RELP? If not, you may need to get out the > debugger. :) Unless it's enabled by default I've no mention of "relp" in my client configs. I'm using plain TCP I think. cheers, P?draig. From ktm at rice.edu Tue Jul 6 15:53:58 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:53:58 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C332CA8.8030301@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> Message-ID: <20100706135358.GK341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 02:16:24PM +0100, P?draig Brady wrote: > On 06/07/10 14:04, Kenneth Marshall wrote: > > Attempts to ameliorate these types of problems by kludging the > > server always end badly. I do not know anything about the RELP > > protocol, but it sounds like the client has a bug as well as > > possibly the server. > > True. I've not looked into why the client is not tearing down connections, > but in practice the clients can always just disappear. > > > Does it happen without RELP? If not, can > > you run without RELP? If not, you may need to get out the > > debugger. :) > > Unless it's enabled by default I've no mention of "relp" > in my client configs. I'm using plain TCP I think. > > cheers, > P?draig. > Are you certain you are not having a problem with some intervening firewall/IPtables network filtering. Poorly configured, they can cause the TCP network stack shutdown to fail because they block packets that should be passed for a correct shutdown. Regards, Ken From P at draigBrady.com Tue Jul 6 16:12:18 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 15:12:18 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706135358.GK341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> Message-ID: <4C3339C2.6000800@draigBrady.com> On 06/07/10 14:53, Kenneth Marshall wrote: > Are you certain you are not having a problem with some > intervening firewall/IPtables network filtering. Poorly > configured, they can cause the TCP network stack shutdown > to fail because they block packets that should be passed > for a correct shutdown. Clients and server are on the same LAN. I've just done this on the 400+ clients: /etc/init.d/rsyslog restart There were about 20 stale connections left on the server. cheers, P?draig. From ktm at rice.edu Tue Jul 6 16:54:45 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 09:54:45 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C3339C2.6000800@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> <4C3339C2.6000800@draigBrady.com> Message-ID: <20100706145445.GL341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 03:12:18PM +0100, P?draig Brady wrote: > On 06/07/10 14:53, Kenneth Marshall wrote: > > Are you certain you are not having a problem with some > > intervening firewall/IPtables network filtering. Poorly > > configured, they can cause the TCP network stack shutdown > > to fail because they block packets that should be passed > > for a correct shutdown. > > Clients and server are on the same LAN. > I've just done this on the 400+ clients: > /etc/init.d/rsyslog restart > There were about 20 stale connections left on the server. > > cheers, > P?draig. > Are the clients/server running any type of firewall software or IPtables? Being on the same LAN will not prevent problems if they are running such software and it is misconfigured. Ken From tbergfeld at hq.adiscon.com Wed Jul 7 13:41:32 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 7 Jul 2010 13:41:32 +0200 Subject: [rsyslog] rsyslog 4.6.3 (v4-stable) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F73@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.6.3, a member of the v4-stable branch. This is a bug-fixing release which contains an improved testbench and a new configure option that permits to disable and enable an extended testbench. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article463.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-205.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From joe at joetify.com Wed Jul 7 18:29:31 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 09:29:31 -0700 Subject: [rsyslog] logging hostnames Message-ID: I have a couple services (haproxy and homegrown erlang stuff) that log directly to my rsyslog server. With these services I found that they log the reverse DNS rather than the hostname but with the logs that come from actual rsyslog clients they show up as one would expect with the real hostname, like what is returned from the "hostname" command. I've tried a few different things with "-x" and fromhost vs hostname and can't seem to get anything other than either an IP or a rDNS. Any suggestions? Do I need to include more information in the messages I send to rsyslog or perhaps adjust a config? Thanks. -Joe Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From david at lang.hm Wed Jul 7 19:27:37 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 10:27:37 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > I have a couple services (haproxy and homegrown erlang stuff) that log > directly to my rsyslog server. With these services I found that they log > the reverse DNS rather than the hostname but with the logs that come > from actual rsyslog clients they show up as one would expect with the > real hostname, like what is returned from the "hostname" command. I've > tried a few different things with "-x" and fromhost vs hostname and > can't seem to get anything other than either an IP or a rDNS. Any > suggestions? Do I need to include more information in the messages I > send to rsyslog or perhaps adjust a config? probably what is happening is that your server is not sending a properly formatted syslog message to rsyslog, so it is figuring out the info itself. try setting up a format with %raw% in it (the raw message that rsyslog receives) and look at it. it _should_ be in the format HH:MM:SS hostname syslogtag message I suspect that you are not getting the data in that format so rsyslog isn't recognising the hostname from the syslog message, so is having to fall back on IP address or reverse DNS. David Lang From joe at joetify.com Wed Jul 7 19:42:37 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 10:42:37 -0700 Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> David, Thanks, I think you're right: <14>Jul 2 21:25:38 HOSTNAME log message vs <149>customer:[<0.20341.5496>] IPADDR log message The latter is the message that our server is sending. -Joe On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > On Wed, 7 Jul 2010, Joe Williams wrote: > >> I have a couple services (haproxy and homegrown erlang stuff) that log >> directly to my rsyslog server. With these services I found that they log >> the reverse DNS rather than the hostname but with the logs that come >> from actual rsyslog clients they show up as one would expect with the >> real hostname, like what is returned from the "hostname" command. I've >> tried a few different things with "-x" and fromhost vs hostname and >> can't seem to get anything other than either an IP or a rDNS. Any >> suggestions? Do I need to include more information in the messages I >> send to rsyslog or perhaps adjust a config? > > probably what is happening is that your server is not sending a properly > formatted syslog message to rsyslog, so it is figuring out the info > itself. > > try setting up a format with %raw% in it (the raw message that rsyslog > receives) and look at it. > > it _should_ be in the format > > HH:MM:SS hostname syslogtag message > > I suspect that you are not getting the data in that format so rsyslog > isn't recognising the hostname from the syslog message, so is having to > fall back on IP address or reverse DNS. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From pkrash at exegy.com Wed Jul 7 22:14:18 2010 From: pkrash at exegy.com (Paul Krash) Date: Wed, 7 Jul 2010 20:14:18 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error Message-ID: Hello! I have recently tried to parse syslog messages by %hostname% using the $RuleSet module. I have seen this work in Centos with no probs. Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf (from the all in one conf file found on Centos). I am getting the error that a module is missing? Is this an Ubuntu special, where a module is not compiled in the distro? I tried to compile from src, and got the same error. How can I get and enable the Module for rulesets? Thanks in advance, PKrash DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" error in /var/log/messages: Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 94 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 109 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 110 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 112 Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] From david at lang.hm Thu Jul 8 03:21:52 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:21:52 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > David, > > Thanks, I think you're right: > > <14>Jul 2 21:25:38 HOSTNAME log message > > vs > > <149>customer:[<0.20341.5496>] IPADDR log message > > The latter is the message that our server is sending. yep, there's no timestamp or hostname in the message. This is a failry common way to malform syslog messages, and the standard thing to do is to use the current time as the timestamp and use the IP address (or reverse DNS lookup) as the hostname if you can get the srver to change it's log format you should start seeing the hostname correctly, short of this you have to settle for what you can get from the IP address. David Lang > -Joe > > > On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > >> On Wed, 7 Jul 2010, Joe Williams wrote: >> >>> I have a couple services (haproxy and homegrown erlang stuff) that log >>> directly to my rsyslog server. With these services I found that they log >>> the reverse DNS rather than the hostname but with the logs that come >>> from actual rsyslog clients they show up as one would expect with the >>> real hostname, like what is returned from the "hostname" command. I've >>> tried a few different things with "-x" and fromhost vs hostname and >>> can't seem to get anything other than either an IP or a rDNS. Any >>> suggestions? Do I need to include more information in the messages I >>> send to rsyslog or perhaps adjust a config? >> >> probably what is happening is that your server is not sending a properly >> formatted syslog message to rsyslog, so it is figuring out the info >> itself. >> >> try setting up a format with %raw% in it (the raw message that rsyslog >> receives) and look at it. >> >> it _should_ be in the format >> >> HH:MM:SS hostname syslogtag message >> >> I suspect that you are not getting the data in that format so rsyslog >> isn't recognising the hostname from the syslog message, so is having to >> fall back on IP address or reverse DNS. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > Name: Joseph A. Williams > Email: joe at joetify.com > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 8 03:24:17 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:24:17 -0700 (PDT) Subject: [rsyslog] $RuleSet parameter yields 3003 error In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Paul Krash wrote: > Hello! > > I have recently tried to parse syslog messages by %hostname% using the $RuleSet > module. I have seen this work in Centos with no probs. > > Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf > (from the all in one conf file found on Centos). > > I am getting the error that a module is missing? > > Is this an Ubuntu special, where a module is not compiled in the distro? I think it's most likely a problem where ubuntu just ships too old a version. It shipps 4.2.0 and I think rulesets were introduced later than that. > I tried to compile from src, and got the same error. did you uninstall the ubuntu default first? if not then you may be conflicting with it's modules (in /usr/lib/rsyslog where your modules probably went into usr/local/lib/rsyslog) David Lang > How can I get and enable the Module for rulesets? > > Thanks in advance, > > PKrash > > > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=10.04 > DISTRIB_CODENAME=lucid > DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" > > error in /var/log/messages: > > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 94 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 109 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 110 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 112 > Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master > config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 8 09:37:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 8 Jul 2010 09:37:22 +0200 Subject: [rsyslog] logging hostnames References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F79@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 08, 2010 3:22 AM > To: rsyslog-users > Subject: Re: [rsyslog] logging hostnames > > On Wed, 7 Jul 2010, Joe Williams wrote: > > > David, > > > > Thanks, I think you're right: > > > > <14>Jul 2 21:25:38 HOSTNAME log message > > > > vs > > > > <149>customer:[<0.20341.5496>] IPADDR log message > > > > The latter is the message that our server is sending. > > yep, there's no timestamp or hostname in the message. This is a failry > common way to malform syslog messages, and the standard thing to do is > to > use the current time as the timestamp and use the IP address (or > reverse > DNS lookup) as the hostname > > if you can get the srver to change it's log format you should start > seeing > the hostname correctly, short of this you have to settle for what you > can > get from the IP address. David is absolutely right, but I would like to mention that a way to address such things (if you can use the IPADDR from the log message) is to write a custom message parser. Rsyslog has recently enhanced to provide this facility for solving such common malformed message issues. If you can not write one yourself, Adiscon offers to write message parsers for little money (provided the parser is contributed back to the project). As a side-note, my hope is that over time we will get a set of parsers that address most of the malformed messages we see... Rainer From pkrash at exegy.com Thu Jul 8 15:10:28 2010 From: pkrash at exegy.com (Paul Krash) Date: Thu, 8 Jul 2010 13:10:28 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error References: Message-ID: lang.hm> writes: > I think it's most likely a problem where ubuntu just ships too old a > version. It shipps 4.2.0 and I think rulesets were introduced later than > that. AHA! Thanks for the important tip! Confirmed, 4.2.0 is shipped with Ubuntu Lucid (10.04). 5.4 is shipped with Centos 5.4 The one instance that Centos is more modern than another distro... :-) > did you uninstall the ubuntu default first? if not then you may be > conflicting with it's modules (in /usr/lib/rsyslog where your modules > probably went into usr/local/lib/rsyslog) Yes, I did. I was depending on dpkg to purge all the files installed, possibly incorrect backout script from the Ubuntu package maintainer. I'll try from source again. Is there a specific ./configure option to include the ruleset module? Thanks in advance! PKrash From david at lang.hm Fri Jul 9 23:42:58 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 9 Jul 2010 14:42:58 -0700 (PDT) Subject: [rsyslog] spoofing module configuration Message-ID: in reading the spoofing module configuration it strikes me that the defaults can be significantly improved. the common case for needing to so spoofing is that you are spoofing the original source IP address so the current configuration equivalent commands $template spoofaddr, "%fromhost-ip%" $ActionUDPSpoofSourceNameTemplate spoofaddr could be made the default (or call it RSYSLOG_spoofaddr to keep from polluting the namespace) and the result would be far simpler for people to configure, becomging simply $modload omudpspoof $ActionUDPSpoofTargetHost server.example.com *.* :omudpspoof: it could be simplified even further if there was some way to specify the destination on the action line (like the @ and @@ functions do today, could we use @S@ to indicate spoofing?) changing the defaults should have no problems with backwards compatibility, adding/changing how the desitnation is specified could break backward compatibility, but this is a very new piece of functionality and the simplification may be worth it (what versions have this available?) David Lang From Jon.Combe at telindus.co.uk Mon Jul 12 15:55:41 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 14:55:41 +0100 Subject: [rsyslog] Last message repeated n times problem Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> I see from a previous post (http://lists.adiscon.net/pipermail/rsyslog/2010-February/003416.html) that this has come up before but there was no answer previously. I have rsyslogd (the latest, version 5.4) installed and running on a host configured to accept remote syslog messages. I have another server configured to send it's syslog messages to the host running rsyslog. I have rsyslog configured to store its entries in a MySQL database using the supplied rsyslog MySQL module. What I find is that most of the messages come through as expected. For example:- *************************** 3. row *************************** ID: 163941 CustomerID: NULL ReceivedAt: 2010-07-12 14:42:38 DeviceReportedTime: 2010-07-12 14:42:38 Facility: 10 Priority: 6 FromHost: 10.167.3.18 Message: pam_unix(sshd:session): session closed for user root NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: sshd[7809]: EventLogType: NULL GenericFileName: NULL SystemID: NULL However each time I get a "Last message repeated X times" message I see corrupted entries in the database:- *************************** 2. row *************************** ID: 163942 CustomerID: NULL ReceivedAt: 2010-07-12 14:43:15 DeviceReportedTime: 2010-07-12 14:43:15 Facility: 3 Priority: 3 FromHost: last Message: repeated 5 times NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: message EventLogType: NULL GenericFileName: NULL SystemID: NULL You can see that the message text has been incorrectly split across the fields message, FromHost and SysLogTag. I have run a tcpdump and here are the two relevant packets:- 14:42:38.985098 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 111: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 97) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 69 Facility authpriv (10), Severity info (6) Msg: sshd[7809]: pam_unix(sshd:session): session closed for user root\012 0x0000: 3c38 363e 7373 6864 5b37 3830 395d 3a20 0x0010: 7061 6d5f 756e 6978 2873 7368 643a 7365 0x0020: 7373 696f 6e29 3a20 7365 7373 696f 6e20 0x0030: 636c 6f73 6564 2066 6f72 2075 7365 7220 0x0040: 726f 6f74 0a 0x0000: 4500 0061 0000 4000 3f11 20ec 0aa7 0312 E..a.. at .?....... 0x0010: 0aa7 0241 0202 0202 004d 5dc8 3c38 363e ...A.....M].<86> 0x0020: 7373 6864 5b37 3830 395d 3a20 7061 6d5f sshd[7809]:.pam_ 0x0030: 756e 6978 2873 7368 643a 7365 7373 696f unix(sshd:sessio 0x0040: 6e29 3a20 7365 7373 696f 6e20 636c 6f73 n):.session.clos 0x0050: 6564 2066 6f72 2075 7365 7220 726f 6f74 ed.for.user.root 0x0060: 0a . 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 34 Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 0x0020: 730a 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 E..>.. at .?.!..... 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e ...A.....*.D<27> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 last.message.rep 0x0030: 6561 7465 6420 3520 7469 6d65 730a eated.5.times. In both cases it seems to me that the IP address of the sender has been included in the packet (0a a7 03 12) which translates as the IP 10.167.3.18 which is the sender. Is this an rsyslog issue? Is it a known problem? Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 16:50:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 16:50:10 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> [snip] Well, as you can see: > 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > sum ok] SYSLOG, length: 34 > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > 0x0020: 730a > 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > E..>.. at .?.!..... > 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > ...A.....*.D<27> > 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > last.message.rep > 0x0030: 6561 7465 6420 3520 7469 6d65 730a > eated.5.times. > the message is totally malformed. > In both cases it seems to me that the IP address of the sender has been > included in the packet (0a a7 03 12) which translates as the IP > 10.167.3.18 which is the sender. > > Is this an rsyslog issue? Is it a known problem? The sender must be fixed to emit correct format. It is a known problem with some senders (sysklogd namely), but we have not yet provided a work-around for it because that causes unnecessary performance loss on the rsyslog side. However, thinking now about it, a special message parser module could be used to solve that situation. That way, only those that actually have this problem would need to bear the cost of the work-around. Let me think a bit about this... > Thanks. > Jon. > > This email is private No, it isn't -- it was sent to a public mailing list and is probably archived on a myriad of sites by now. Please note that as of the ToS of the mailing list, we do not accept any liability. It would be decent to tell your mail folks to turn off this disclaimer for list-directed mail. Thanks! Rainer > and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Jon.Combe at telindus.co.uk Mon Jul 12 17:19:13 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 16:19:13 +0100 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > >the message is totally malformed. Rainer, Thanks for the reply. I'm no expert on the format I'm afraid but I have looked at the RFC http://tools.ietf.org/search/rfc5424 You're correct that the sender is using sysklogd. Would you be able to tell me how it is malformed? I can see that something (tcpdump?) has parsed the message here:- Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 Reading the RFC it says the header should be PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID Where pri are enclosed in < and > (which is the <27> in the above), followed by a space and then the version, which can be NIL, followed by timestamp (which can also be NIL), followed by hostname (also NIL permitted), APP NAME (also NIL is permitted), PROCID (also NIL permitted), MSGID (also NIL permitted) and then after the header is the actual message. So my understanding of the RFC is that the only field required in the header is , which is present. I'm not clear on whether the spaces are required or not or only if the optional fields are present. The only difference I see between the valid packet I sent and this one is that the valid packet has "sshd[7809]:" at the start of the message - is this the APP-NAME field from the header perhaps? I realise from the RFC that many of these fields are listed as SHOULD be provided Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 17:22:43 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 17:22:43 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F95@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Jon Combe > Sent: Monday, July 12, 2010 5:19 PM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 > > You're correct that the sender is using sysklogd. Would you be able to > tell me how it is malformed? I can see that something (tcpdump?) has > parsed the message here:- > > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > > Reading the RFC it says the header should be > > PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID > > Where pri are enclosed in < and > (which is the <27> in the above), > followed by a space and then the version, which can be NIL, followed by > timestamp (which can also be NIL), followed by hostname (also NIL > permitted), APP NAME (also NIL is permitted), PROCID (also NIL > permitted), MSGID (also NIL permitted) and then after the header is the > actual message. > > So my understanding of the RFC is that the only field required in the > header is , which is present. I'm not clear on whether the spaces > are required or not or only if the optional fields are present. Spaces are required, VERSION can not be NILVALUE and NILVALUE is defined as "-". ;) Rainer > > The only difference I see between the valid packet I sent and this one > is that the valid packet has "sshd[7809]:" at the start of the message > - is this the APP-NAME field from the header perhaps? I realise from > the RFC that many of these fields are listed as SHOULD be provided > > Thanks. > Jon. > > This email is private and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From chs7490 at gmail.com Mon Jul 12 23:33:36 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 06:33:36 +0900 Subject: [rsyslog] kernel messages on usb flash drive Message-ID: Hi everyone I want to write kernel meesage,which is generally recorded at /var/log/messages, at usb flash memory. It goes well when the kernel mesage recording file is specified on hard disk, but it does not on usb flash memory. What I have worked on is as below. -- >mkdir /var/log/hm >mount /dev/sdb /var/log/hm (I checked that usb flash memory is mounted.) >vi /etc/rsyslog.conf I changed *.info;mail.none;authpriv.none;cron.none /var/log/messages to *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages -- When the kernel message recording place is specified on hard disk (such as /var/log/messages2), it records well. However, it does not record on usb flash memory Please let me know if there is something that I have to revise or add thanks in advance, Cheon. From david at lang.hm Mon Jul 12 23:52:05 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 14:52:05 -0700 (PDT) Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: On Tue, 13 Jul 2010, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- >> mkdir /var/log/hm > >> mount /dev/sdb /var/log/hm > (I checked that usb flash memory is mounted.) > >> vi /etc/rsyslog.conf > > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory when you say it doesn't record on the USB flash, what is happening? do you get errors or do you find that the data is still written to the hard drive? My guess is that it's being written to the hard drive because the USB stick is no mounted yet when rsyslog starts, so the file that it has open is on the hard drive and not the flash drive. you need to start rsyslog after the flash drive is mounted, and then stop rsyslog before you unmount it to make sure the data is written to it. David Lang From rory at ooma.com Mon Jul 12 23:43:05 2010 From: rory at ooma.com (Rory Toma) Date: Mon, 12 Jul 2010 14:43:05 -0700 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: <4C3B8C69.6080001@ooma.com> What filesystem is on your USB drive? If you just plugged something in, it's likely FAT32, and you may be seeing performance issues if you have a lot of messages. I assume you can write files by hand to this drive? On 7/12/10 2:33 PM, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- > >> mkdir /var/log/hm >> > >> mount /dev/sdb /var/log/hm >> > (I checked that usb flash memory is mounted.) > > >> vi /etc/rsyslog.conf >> > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory > > Please let me know if there is something that I have to revise or add > > thanks in advance, > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Jul 13 00:25:21 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 15:25:21 -0700 (PDT) Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 12 Jul 2010, Rainer Gerhards wrote: > [snip] > Well, as you can see: >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > the message is totally malformed. > >> In both cases it seems to me that the IP address of the sender has been >> included in the packet (0a a7 03 12) which translates as the IP >> 10.167.3.18 which is the sender. >> >> Is this an rsyslog issue? Is it a known problem? > > The sender must be fixed to emit correct format. It is a known problem with > some senders (sysklogd namely), but we have not yet provided a work-around > for it because that causes unnecessary performance loss on the rsyslog side. > However, thinking now about it, a special message parser module could be used > to solve that situation. That way, only those that actually have this problem > would need to bear the cost of the work-around. Let me think a bit about > this... if I'm understanding this correctly the filter seems like it would be pretty simple. accept the message as being potentially well formed IFF (if and only if) it meets the following criteria. 1. has a valid tag 2. characters 4, 7, 16 are ' ' 3. characters 10,13 are ':' this isn't absolute proof that this is a valid timestamp, but it's pretty good and very quick to check in C. if not, it can't possibly be a valid message, set the timestamp (current time) and hostname (based on the source IP in the packet). then check the word staring at position 17 to see if it is made up of characters that mean it could be a hostname (a-zA-Z0-9.-) if not, it can't possibly be a valid hostname, set the hostname (based on the source IP in the packet) now, if something passes this test but has other garbage in the hostname field, that will take system specific fixups. In this case, after the tests I describe you would still have the syslog tag of 'last' and the message 'message repeated 5 times' that would need to be fixed by a filter that checked for 'last message repeated' and put it all in the message (filling in a dummy or blank syslog tag) there are unfortunantly a bunch of such filters that are needed. now that they are easy to create we can hopefully get a bunch of them done so that only the people who need them bother with them. one question on stackable filters. how much overhead is there in putting the tests in separate filters as opposed to in one filter? for example, take 3 tests 1. 'message forwarded from hostname' -> hostname 2. 'last message repeated' -> move to message body 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN what would the impact be of having each of these as separate filters vs one filter with configurable tests? (i.e. is there a noticable overhead in stacking the filters) David Lang >> Thanks. >> Jon. >> >> This email is private > > No, it isn't -- it was sent to a public mailing list and is probably archived > on a myriad of sites by now. Please note that as of the ToS of the mailing > list, we do not accept any liability. It would be decent to tell your mail > folks to turn off this disclaimer for list-directed mail. Thanks! > > Rainer > >> and may be confidential and is for the intended >> recipient only. If misdirected, please notify us by telephone and >> confirm that it has been deleted from your system and any copies >> destroyed. If you are not the intended recipient you are strictly >> prohibited from using, printing, copying, distributing or disseminating >> this email or any information contained in it. We use reasonable >> endeavours to virus scan all emails leaving the Company but no warranty >> is given that this email and any attachments are virus free. You should >> undertake your own virus checking. The right to monitor email >> communications through our network is reserved by us. >> >> Telindus Limited is a company registered in England and Wales under >> number 02020395. The registered office is Centurion, Riverside Way, >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From sean at conman.org Tue Jul 13 02:50:37 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 20:50:37 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> Message-ID: <20100713005037.GB3089@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > But my overall assumption is that we stick what we currently have, but > > extend > > it in a way that provides scoping and do so in a way the provides as > > many > > usable interim steps as possible (without adding major work just for > > those > > steps). I hope this covers the spirit of our discussion. > > I tried very hard the past days to get a grammar together that is an > evolution from what we currently have. I did not yet succeed fully (thus I > have no formal grammar to show), but I think I made some progress. > > So please let me come back and present a config sample: > > http://download.rsyslog.com/rainerscript2_rsyslog.conf > > It actually is three configs in one file > > a) a standard rsyslog.conf in mixed new and old format > b) a standard rsyslog.conf in new format, only > c) a complex rsyslog.conf (not really working) in new format > > [partitioned by (just) comments] > > Note that being an evolution, any currently existing rsyslog.conf would also > be a valid new conf (via the *same* parser). I have not thought out the full > semantics and thousand other things that need to be thought of -- this > actually opened up a can of worms ;) However, I find the proposed format > seems to be a good compromise between the need to preserve and the need to > move on, and between the need for simplicity and the need for power. > > As such, before I invest even more time into that format, I'd like to get > some feedback on what you folks think ;) Okay, take number two. After reading the various comments about my last message (using Lua---rejected for various reasons) what it sounds like you want is a more declaritive syntax---a mapping of input to output. Have you considered a syntax like Haskel or Erlang? There functions are declared by pattern matching input parameters and thus, you tend not to see many (if any) if statements (okay, I checked a sizable Erlang program I have, and it does use 'case' in a few spots, but not many). The original syslog.conf file has what I mean to some degree, with a syntax like: mail.* @maillogprocessinghost mail.warn /some/log/file cron.* /some/other/logfile Since most of what you want to do is based off the input message, how about extending this style of syntax to more than just the facility/priority pair? Since host, program, facility, priority and message are typically the most interesting fields (at least, in my experience), perhaps a syntax that includes matching those as well would work. Something like: # order is host, program, facility, priority, msg ( * , * , mail , (warn err crit alert emerg) , *) => file("/var/log/mail.log") # the above is the same as the traditional syslog syntax of # mail.warn /var/log/mail.log # log cron messages to logs based off the hostname ( * , * , cron , * , * ) => file("/var/log/{host}/cron.log") # define a list of values routers = { ip1 ip2 ip3 ip4 } # use said list in a pattern matching rule # the msg field uses a regex ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*Neighbor Down)/ ) => email( ... ) ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*LOADING to FULL)/ ) => email( ... ) # feed SSH failed logins to external program, to block repeated attemts # ~"blah" will check for the existance of "blah" somewhere in the string # log all SSH information to a file ( localhost , sshd , auth2 , info , ~"Fail password for" ) => exec( ... ) ( * , sshd , auth2 , * , * ) => file( ... ) # auth messages go offsite, never locally, everything else # gets logged locally, except for *.debug, which gets relayed # to development machines for processing ( * , * , auth , * , * ) => relay(secure) ( * , * , !auth , !debug , * ) => file(...) ( * , * , !auth , debug , * ) => relay(dev) Seldom used fields can be explicitely checked ( * , * , * , * , * , relay = A) => ... No if statements in sight, just a series of patterns and actions when said pattern is matched. You also have "variables" and a way to reference them, and I left the syntax for actions vague intentionally. -spc (Just an idea ... ) From sean at conman.org Tue Jul 13 03:09:26 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 21:09:26 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <20100713010926.GC3089@brevard.conman.org> It was thus said that the Great Jon Combe once stated: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 The format being sent is documented in RFC-3164, in which the only mandatory field is PRI---it's up the the receiving end to make sense of the rest of the message. It appears that in your case rsyslogd is mis-interpreting the incoming message. -spc From david at lang.hm Tue Jul 13 06:29:45 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 21:29:45 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713005037.GB3089@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: On Mon, 12 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >>> But my overall assumption is that we stick what we currently have, but >>> extend >>> it in a way that provides scoping and do so in a way the provides as >>> many >>> usable interim steps as possible (without adding major work just for >>> those >>> steps). I hope this covers the spirit of our discussion. >> >> I tried very hard the past days to get a grammar together that is an >> evolution from what we currently have. I did not yet succeed fully (thus I >> have no formal grammar to show), but I think I made some progress. >> >> So please let me come back and present a config sample: >> >> http://download.rsyslog.com/rainerscript2_rsyslog.conf >> >> It actually is three configs in one file >> >> a) a standard rsyslog.conf in mixed new and old format >> b) a standard rsyslog.conf in new format, only >> c) a complex rsyslog.conf (not really working) in new format >> >> [partitioned by (just) comments] >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > Okay, take number two. > > After reading the various comments about my last message (using > Lua---rejected for various reasons) what it sounds like you want is a more > declaritive syntax---a mapping of input to output. Have you considered a > syntax like Haskel or Erlang? There functions are declared by pattern > matching input parameters and thus, you tend not to see many (if any) if > statements (okay, I checked a sizable Erlang program I have, and it does use > 'case' in a few spots, but not many). > > The original syslog.conf file has what I mean to some degree, with a > syntax like: > > mail.* @maillogprocessinghost > mail.warn /some/log/file > cron.* /some/other/logfile > > Since most of what you want to do is based off the input message, how > about extending this style of syntax to more than just the facility/priority > pair? Since host, program, facility, priority and message are typically the > most interesting fields (at least, in my experience), perhaps a syntax that > includes matching those as well would work. Something like: this is the approach that rsyslog took with the old config file. the problem is that we are now getting capibilities that can't easily be represented this way David Lang From chs7490 at gmail.com Tue Jul 13 06:49:34 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 13:49:34 +0900 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: 2010/7/13 > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > Hi everyone > > > > > > I want to write kernel meesage,which is generally recorded at > > /var/log/messages, at usb flash memory. > > It goes well when the kernel mesage recording file is specified on hard > > disk, but it does not on usb flash memory. > > > > What I have worked on is as below. > > > > -- > >> mkdir /var/log/hm > > > >> mount /dev/sdb /var/log/hm > > (I checked that usb flash memory is mounted.) > > > >> vi /etc/rsyslog.conf > > > > I changed > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > to > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > -- > > > > When the kernel message recording place is specified on hard disk (such > as > > /var/log/messages2), it records well. However, it does not record on usb > > flash memory > > when you say it doesn't record on the USB flash, what is happening? > do you > get errors or do you find that the data is still written to the hard > drive? > ==> I can see following message through 'dmesg' cmd. SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts i don't know what the message means. I cannot find the data on the hard drive. > > My guess is that it's being written to the hard drive because the USB > stick is no mounted yet when rsyslog starts, so the file that it has open > is on the hard drive and not the flash drive. > you need to start rsyslog after the flash drive is mounted, and then stop > rsyslog before you unmount it to make sure the data is written to it. > ==> after the usb stick is mounted, i restarted rsyslog. But nothing is changed T.T when i try to write kenel messages to usb flash drive, I can see kernel messages using 'dmesg' cmd, but they are not written to the flash drive or hard drive. Cheon. From sean at conman.org Tue Jul 13 08:27:22 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 02:27:22 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: <20100713062722.GA3959@brevard.conman.org> It was thus said that the Great david at lang.hm once stated: > On Mon, 12 Jul 2010, Sean Conner wrote: > > > Since most of what you want to do is based off the input message, how > > about extending this style of syntax to more than just the facility/priority > > pair? Since host, program, facility, priority and message are typically the > > most interesting fields (at least, in my experience), perhaps a syntax that > > includes matching those as well would work. Something like: > > > > this is the approach that rsyslog took with the old config file. > > the problem is that we are now getting capibilities that can't easily be > represented this way Such as? That's one reason why I took the approach I did in my syslogd (which uses Lua)---if the configuration file is going to be complex anyway, why not just write a syslog filter in Lua and be done with it? I know why Rainer is rejecting Lua (and by extension, even his own RanierScript), but the current method is obviously not working, because the topic keeps coming up as mroe and more use cases come into being. So perhaps the question to ask is not what the configuration file looks like, but rather, what, exactly, is rsyslogd expected to do? Just route messages from sources to destinations and nothing more? Or do people want logic in the processing? (My guess is "Yes"---and that's what is causing problems with the configuration file). -spc From rgerhards at hq.adiscon.com Tue Jul 13 09:08:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:08:50 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com><35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> <20100713010926.GC3089@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> > The format being sent is documented in RFC-3164, in which the only > mandatory field is PRI No, not even PRI ;) > ---it's up the the receiving end to make sense of > the > rest of the message. It appears that in your case rsyslogd is > mis-interpreting the incoming message. Technically speaking, RFC3164 is not a standard, because it is an informational document. I have elaborated about its implications in: http://www.rsyslog.com/doc-syslog_parsing.html So if we follow your view, we simply need to accept anything as being valid, and as such we do never know which information is contained inside a message (just ask yourself the question how you know what the sender meant in this case. Message is "hostname junk" Was this intended to mean MSG = "hostname junk" or was it intended to mean hostname="hostname", MSG="junk" -- or something else? As I already wrote, we can potentially handle the "last message repeated ..." case, but only at a performance toll (we need to do a full message compare). I do not consider this acceptable as a general case. But crafting a parser module probably makes a lot of sense (thankfully we have this capability now). Rainer From david at lang.hm Tue Jul 13 09:10:57 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 00:10:57 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713062722.GA3959@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: On Tue, 13 Jul 2010, Sean Conner wrote: > It was thus said that the Great david at lang.hm once stated: >> On Mon, 12 Jul 2010, Sean Conner wrote: >> >>> Since most of what you want to do is based off the input message, how >>> about extending this style of syntax to more than just the facility/priority >>> pair? Since host, program, facility, priority and message are typically the >>> most interesting fields (at least, in my experience), perhaps a syntax that >>> includes matching those as well would work. Something like: >> >> >> >> this is the approach that rsyslog took with the old config file. >> >> the problem is that we are now getting capibilities that can't easily be >> represented this way > > Such as? > > That's one reason why I took the approach I did in my syslogd (which uses > Lua)---if the configuration file is going to be complex anyway, why not just > write a syslog filter in Lua and be done with it? I know why Rainer is > rejecting Lua (and by extension, even his own RanierScript), but the current > method is obviously not working, because the topic keeps coming up as mroe > and more use cases come into being. > > So perhaps the question to ask is not what the configuration file looks > like, but rather, what, exactly, is rsyslogd expected to do? Just route > messages from sources to destinations and nothing more? Or do people want > logic in the processing? (My guess is "Yes"---and that's what is causing > problems with the configuration file). if-then-else logic in the processing, sending things to the same output based on different logic, subsets of rules that only get evaluated if earlier conditions are true, allowing some outputs to queue while not others. just as a few of them earlier in this thread some of the examples that Rainer gave give some hints of this. David Lang From rgerhards at hq.adiscon.com Tue Jul 13 09:16:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:16:32 +0200 Subject: [rsyslog] kernel messages on usb flash drive References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F98@GRFEXC.intern.adiscon.com> All I can say is that rsyslog just calls the usual open() API. You may run it in debug mode to see what the OS returns when trying to open the file on the USB drive. From rsyslog's POV, all files are equal, no matter where they reside. Of course, this means the filesystem must be mounted (as David pointed out). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Hongseok Cheon > Sent: Tuesday, July 13, 2010 6:50 AM > To: rsyslog-users > Subject: Re: [rsyslog] kernel messages on usb flash drive > > 2010/7/13 > > > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > > > Hi everyone > > > > > > > > > I want to write kernel meesage,which is generally recorded at > > > /var/log/messages, at usb flash memory. > > > It goes well when the kernel mesage recording file is specified on > hard > > > disk, but it does not on usb flash memory. > > > > > > What I have worked on is as below. > > > > > > -- > > >> mkdir /var/log/hm > > > > > >> mount /dev/sdb /var/log/hm > > > (I checked that usb flash memory is mounted.) > > > > > >> vi /etc/rsyslog.conf > > > > > > I changed > > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > > to > > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > > -- > > > > > > When the kernel message recording place is specified on hard disk > (such > > as > > > /var/log/messages2), it records well. However, it does not record > on usb > > > flash memory > > > > when you say it doesn't record on the USB flash, what is happening? > > > > > > do you > > get errors or do you find that the data is still written to the hard > > drive? > > > ==> > I can see following message through 'dmesg' cmd. > SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts > i don't know what the message means. > > I cannot find the data on the hard drive. > > > > > > > > > My guess is that it's being written to the hard drive because the USB > > stick is no mounted yet when rsyslog starts, so the file that it has > open > > is on the hard drive and not the flash drive. > > > > you need to start rsyslog after the flash drive is mounted, and then > stop > > rsyslog before you unmount it to make sure the data is written to it. > > > > ==> > after the usb stick is mounted, i restarted rsyslog. But nothing is > changed > T.T > > > when i try to write kenel messages to usb flash drive, > I can see kernel messages using 'dmesg' cmd, but they are not written > to > the flash drive or hard drive. > > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:31:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:31:32 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 9:11 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great david at lang.hm once stated: > >> On Mon, 12 Jul 2010, Sean Conner wrote: > >> > >>> Since most of what you want to do is based off the input message, > how > >>> about extending this style of syntax to more than just the > facility/priority > >>> pair? Since host, program, facility, priority and message are > typically the > >>> most interesting fields (at least, in my experience), perhaps a > syntax that > >>> includes matching those as well would work. Something like: > >> > >> > >> > >> this is the approach that rsyslog took with the old config file. > >> > >> the problem is that we are now getting capibilities that can't > easily be > >> represented this way > > > > Such as? > > > > That's one reason why I took the approach I did in my syslogd (which > uses > > Lua)---if the configuration file is going to be complex anyway, why > not just > > write a syslog filter in Lua and be done with it? I know why Rainer > is > > rejecting Lua (and by extension, even his own RanierScript), but the > current > > method is obviously not working, because the topic keeps coming up as > mroe > > and more use cases come into being. > > > > So perhaps the question to ask is not what the configuration file > looks > > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > > messages from sources to destinations and nothing more? Or do people > want > > logic in the processing? (My guess is "Yes"---and that's what is > causing > > problems with the configuration file). > > if-then-else logic in the processing, sending things to the same output > based on different logic, subsets of rules that only get evaluated if > earlier conditions are true, allowing some outputs to queue while not > others. > > just as a few of them > > earlier in this thread some of the examples that Rainer gave give some > hints of this. To add some of the less obvious things: support for multiple listeners going to different outputs, in an easy to use way. Support for explicitely specified concurrency (or serialization) for high-speed environments, support for different queues, and tying of different queues to different object classes (inputs, message processors, actions). Flexibility to support configuration for even unexpected plugins that we may not even know about (because some third party writes them and never publishes them). But I begin to agree that we, the community, as a whole have very different needs. I have gotten the impression that it is probably a good idea to stop the current effort and re-start it with a requirements definition. I have tried to digest the discussions on config format we had over the year, but sometimes it looks like the only consensus we have is that the current format is ugly and hard to use. The solutions are very wide-ranging. I have even briefly looked at syslog-ng, and seen a lot of the pain again that makes me dislike that format (but I'll probably still have a closer look and will try to write up my detailed position why I do not find buying into this format is a good idea). All in all, I think the best way to re-start our thinking about the config format is to set up a web site where we gather user feedback on a) what problems they have with the config format (not what they just dislike, but real problems, an example From myself: it is nearly impossible to get the sequence right To bind inputs to the right rulesets AND use ruleset inclusion) b) which alternatives they see With all this being on a web site, it may be possible to craft a better decision in 6 to 9 month, assuming we were able to gain sufficient feedback during that time. An alternative would be to create a config parser interface, so that everybody could code up his favorite config language. However, this seems to be impractical, as many of the ideas floating around (Lua, syslog-ng style) require not just different config parsers, but a different rsyslog processing core as well. Obviously a complete rewrite in the case of Lua, less for syslog-ng, but still considerate. For the syslog-ng style we would need to create named filters, something that I really find questionable. Also, we would need to add an interim layer between inputs and rulesets, something that eats performance. In any case, this are not config-parser only changes. Of course, I could just pick one of the alternatives. However, it doesn't make sense to invest a couple of month to do the config system "right", if we know that a lot of folks will still be unhappy after we have done this. Rainer From rgerhards at hq.adiscon.com Tue Jul 13 09:40:25 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:40:25 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 12:25 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > On Mon, 12 Jul 2010, Rainer Gerhards wrote: > > > [snip] > > Well, as you can see: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > the message is totally malformed. > > > >> In both cases it seems to me that the IP address of the sender has > been > >> included in the packet (0a a7 03 12) which translates as the IP > >> 10.167.3.18 which is the sender. > >> > >> Is this an rsyslog issue? Is it a known problem? > > > > The sender must be fixed to emit correct format. It is a known > problem with > > some senders (sysklogd namely), but we have not yet provided a work- > around > > for it because that causes unnecessary performance loss on the > rsyslog side. > > However, thinking now about it, a special message parser module could > be used > > to solve that situation. That way, only those that actually have this > problem > > would need to bear the cost of the work-around. Let me think a bit > about > > this... > > if I'm understanding this correctly the filter seems like it would be > pretty simple. > > accept the message as being potentially well formed IFF (if and only > if) > it meets the following criteria. > > 1. has a valid tag > > 2. characters 4, 7, 16 are ' ' > > 3. characters 10,13 are ':' > > this isn't absolute proof that this is a valid timestamp, but it's > pretty > good and very quick to check in C. > That's definitely a way to go. Unfortunately, pmrfc3164 already does a lot of guesswork for other cases where things are malformed (just as an example, there are devices that put an additional space in front of the date, invalidating all the offsets you give...). The problem is that in a strict sense, RFC3164 does not demand anything. So there are lots of things that are mutually exclusive. In the current parser, I try to weigh importance of occurrence and performance. So the most prominent cases are probably handled, conflicting less common cases not. "last message repeated n times" is pretty useless, so it has low priority. I have also a "performance filter" on my mind, that means I do only those things that seem reasonable. However, the whole idea of introducing message parsers was to solve exactly that problem. So I think it is natural to write a new message parser rather than try (and probably fail) to fiddle even more with the 3164 parser, which already is overwhelmed with guesswork. For "last message...", I would need to do a full string compare, anything else would be incompatible with the already-existing guesswork in pmrfc3164. Rainer > if not, it can't possibly be a valid message, set the timestamp > (current > time) and hostname (based on the source IP in the packet). > > then check the word staring at position 17 to see if it is made up of > characters that mean it could be a hostname (a-zA-Z0-9.-) > > if not, it can't possibly be a valid hostname, set the hostname (based > on > the source IP in the packet) > > > now, if something passes this test but has other garbage in the > hostname > field, that will take system specific fixups. In this case, after the > tests I describe you would still have the syslog tag of 'last' and the > message 'message repeated 5 times' > > that would need to be fixed by a filter that checked for 'last message > repeated' and put it all in the message (filling in a dummy or blank > syslog tag) > > there are unfortunantly a bunch of such filters that are needed. now > that > they are easy to create we can hopefully get a bunch of them done so > that > only the people who need them bother with them. > > one question on stackable filters. > > how much overhead is there in putting the tests in separate filters > as > opposed to in one filter? > > for example, take 3 tests > > 1. 'message forwarded from hostname' -> hostname > > 2. 'last message repeated' -> move to message body > > 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN > > what would the impact be of having each of these as separate filters vs > one filter with configurable tests? (i.e. is there a noticable overhead > in > stacking the filters) > > David Lang > > >> Thanks. > >> Jon. > >> > >> This email is private > > > > No, it isn't -- it was sent to a public mailing list and is probably > archived > > on a myriad of sites by now. Please note that as of the ToS of the > mailing > > list, we do not accept any liability. It would be decent to tell your > mail > > folks to turn off this disclaimer for list-directed mail. Thanks! > > > > Rainer > > > >> and may be confidential and is for the intended > >> recipient only. If misdirected, please notify us by telephone and > >> confirm that it has been deleted from your system and any copies > >> destroyed. If you are not the intended recipient you are strictly > >> prohibited from using, printing, copying, distributing or > disseminating > >> this email or any information contained in it. We use reasonable > >> endeavours to virus scan all emails leaving the Company but no > warranty > >> is given that this email and any attachments are virus free. You > should > >> undertake your own virus checking. The right to monitor email > >> communications through our network is reserved by us. > >> > >> Telindus Limited is a company registered in England and Wales under > >> number 02020395. The registered office is Centurion, Riverside Way, > >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:44:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:44:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9B@GRFEXC.intern.adiscon.com> > So perhaps the question to ask is not what the configuration file > looks > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > messages from sources to destinations and nothing more? Or do people > want > logic in the processing? (My guess is "Yes"---and that's what is > causing > problems with the configuration file). You still miss the point that performance is *very* critical. Also, audit-gradness for the routing process is critical. It's not just about flow-of-control. You need to be able to configure all these properties for various use cases. Rainer From sean at conman.org Tue Jul 13 09:46:39 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 03:46:39 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> References: <20100713010926.GC3089@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> Message-ID: <20100713074639.GB23556@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > The format being sent is documented in RFC-3164, in which the only > > mandatory field is PRI > > No, not even PRI ;) Yes, you are correct. I misspoke 8-) > > ---it's up the the receiving end to make sense of > > the > > rest of the message. It appears that in your case rsyslogd is > > mis-interpreting the incoming message. > > Technically speaking, RFC3164 is not a standard, because it is an > informational document. I have elaborated about its implications in: > > http://www.rsyslog.com/doc-syslog_parsing.html > > So if we follow your view, we simply need to accept anything as being valid, > and as such we do never know which information is contained inside a message > (just ask yourself the question how you know what the sender meant in this > case. Message is > > "hostname junk" > > Was this intended to mean MSG = "hostname junk" or was it intended to mean > hostname="hostname", MSG="junk" -- or something else? In my own project, I treat it as MSG = "hostname junk" with a facility of USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, because of the wide variance I've encountered in parsing syslog messages, when I send out a message, I use the IP address as the hostname (I find the IP address (either v4 or v6) to be unambigious and easier to find than a hostname), and anything else in that portion (up to a colon) as the program name (one exception: anything in square brackets is a process id). The entire parser routine is 210 lines of C (including a ton of comments) and it works enough for my tastes (and if I come across somethign that doesn't parse right, I still have the raw log to check against). Adding RFC-5424 parsing support would be easy, but I don't have anything generating RFC-5424 records (well, I suppose my program could relay in RFC-5424 format ... ) -spc From rgerhards at hq.adiscon.com Tue Jul 13 10:15:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:15:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> <20100713074639.GB23556@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 9:47 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > > The format being sent is documented in RFC-3164, in which the > only > > > mandatory field is PRI > > > > No, not even PRI ;) > > Yes, you are correct. I misspoke 8-) > > > > ---it's up the the receiving end to make sense of > > > the > > > rest of the message. It appears that in your case rsyslogd is > > > mis-interpreting the incoming message. > > > > Technically speaking, RFC3164 is not a standard, because it is an > > informational document. I have elaborated about its implications in: > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > So if we follow your view, we simply need to accept anything as being > valid, > > and as such we do never know which information is contained inside a > message > > (just ask yourself the question how you know what the sender meant in > this > > case. Message is > > > > "hostname junk" > > > > Was this intended to mean MSG = "hostname junk" or was it intended to > mean > > hostname="hostname", MSG="junk" -- or something else? > > In my own project, I treat it as MSG = "hostname junk" with a > facility of > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, > because of the wide variance I've encountered in parsing syslog > messages, > when I send out a message, I use the IP address as the hostname (I find > the > IP address (either v4 or v6) to be unambigious and easier to find than > a > hostname), and anything else in that portion (up to a colon) as the > program > name (one exception: anything in square brackets is a process id). That's the well known approach, which means you do not really interpret the message. Also, it makes your project unsuitable for NAT environments and relay chains. This, as a side-note, where some of the reasons why syslog standardization started. Even 10 years ago, people where quite unsatisfied with these problems. > > The entire parser routine is 210 lines of C (including a ton of > comments) > and it works enough for my tastes (and if I come across somethign that > doesn't parse right, I still have the raw log to check against). %rawmsg% Rainer > Adding > RFC-5424 parsing support would be easy, but I don't have anything > generating > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > format > ... ) > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:16:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:16:22 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Oh, yes, you got me here. So please elaborate how you parse "<13>hostname junk" ;) Rainer > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:30:15 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:30:15 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Spc, well, on second thought: rather than (somewhat) heatedly discussing the pros and cons of various parser modes: Wouldn't it make sense if you turn your code into a parser module and contribute that to the project? So users could decide what they prefer. I think that would be truly in the spirit of open source. I will happily accept such a contribution! (It is always great to have freedom of choice). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Tue Jul 13 11:09:04 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:09:04 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> Message-ID: <20100713090904.GA18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > > > > In my own project, I treat it as MSG = "hostname junk" with a > > > facility of > > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > > Oh, yes, you got me here. So please elaborate how you parse > > "<13>hostname junk" > > ;) It's be interpreted as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: notice (this is priority---I call it level) msg: hostname junk If instead it was: <15>hostname junk my program would parse it as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: debug msg: hostname junk -spc (At least it's consistent 8-) From sean at conman.org Tue Jul 13 11:18:54 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:18:54 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Message-ID: <20100713091854.GB18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > Spc, > > well, on second thought: rather than (somewhat) heatedly discussing the pros > and cons of various parser modes: Wouldn't it make sense if you turn your > code into a parser module and contribute that to the project? So users could > decide what they prefer. I think that would be truly in the spirit of open > source. I will happily accept such a contribution! (It is always great to > have freedom of choice). Which code? My 210 lines of parser? Or a module to toss the message to some Lua code? -spc From rgerhards at hq.adiscon.com Tue Jul 13 11:31:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 11:31:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> <20100713091854.GB18093@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 11:19 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > Spc, > > > > well, on second thought: rather than (somewhat) heatedly discussing > the pros > > and cons of various parser modes: Wouldn't it make sense if you turn > your > > code into a parser module and contribute that to the project? So > users could > > decide what they prefer. I think that would be truly in the spirit of > open > > source. I will happily accept such a contribution! (It is always > great to > > have freedom of choice). > > Which code? My 210 lines of parser? I think we were talking about the parser here ;) So, yes, I asked you to turn your parser into a parsing module and contribute it to the project. That makes probably an awful lot of more sense than to discuss what *would* be better. Thinking about it, that discussion probably took more time than it would have taken to create a parser module for "last message...". So if you have running code that you think works (at least in some cases) better than the provided parsers, the most natural thing would be to contribute that code and help to grow the project. > Or a module to toss the message > to > some Lua code? Well, if you can do that (as an output module, I assume), I'd definitely would accept that as a contribution as well. Rainer > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 16:21:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:21:46 +0200 Subject: [rsyslog] pmlastmsg available - workaround for: Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Hi all, > That's definitely a way to go. Unfortunately, pmrfc3164 already does a > lot of > guesswork for other cases where things are malformed (just as an > example, > there are devices that put an additional space in front of the date, > invalidating all the offsets you give...). > > The problem is that in a strict sense, RFC3164 does not demand > anything. So > there are lots of things that are mutually exclusive. In the current > parser, > I try to weigh importance of occurrence and performance. So the most > prominent cases are probably handled, conflicting less common cases > not. > "last message repeated n times" is pretty useless, so it has low > priority. I > have also a "performance filter" on my mind, that means I do only those > things that seem reasonable. > > However, the whole idea of introducing message parsers was to solve > exactly > that problem. So I think it is natural to write a new message parser > rather > than try (and probably fail) to fiddle even more with the 3164 parser, > which > already is overwhelmed with guesswork. For "last message...", I would > need to > do a full string compare, anything else would be incompatible with the > already-existing guesswork in pmrfc3164. > > Rainer I have crafted the new message parser I spoke about this morning. The module is called "pmlastmsg" and available via the git master branch right now. The commit is here (you notice it is not much code, if you ignore the macros and preprocessor statements): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=73ebadd5980f91079416a14b a6463d576ecb6207 Doc, with the typical usage sample, is available here: http://www.rsyslog.com/doc-pmlastmsg.html This parser module should solve the "last message repeated n times" problem for all future ;) Rainer From timo.bumke at web.de Tue Jul 13 16:34:21 2010 From: timo.bumke at web.de (Timo Bumke) Date: Tue, 13 Jul 2010 16:34:21 +0200 Subject: [rsyslog] Omoracle ORA-01461 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Message-ID: <4C3C796D.1030003@web.de> Hello, I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: |create table test (hostname varchar2(100), message varchar2(4000)); |I found out that if I am only writing one syslog property to oracle it succeeds. My configuration: |(...) ################ #### ORACLE #### ################ $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt|i| | Any ideas? From rgerhards at hq.adiscon.com Tue Jul 13 16:46:47 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:46:47 +0200 Subject: [rsyslog] spoofing module configuration References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA4@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 09, 2010 11:43 PM > To: rsyslog-users > Subject: [rsyslog] spoofing module configuration > > in reading the spoofing module configuration it strikes me that the > defaults can be significantly improved. > > the common case for needing to so spoofing is that you are spoofing the > original source IP address > > so the current configuration equivalent commands > > $template spoofaddr, "%fromhost-ip%" > $ActionUDPSpoofSourceNameTemplate spoofaddr > > could be made the default (or call it RSYSLOG_spoofaddr to keep from > polluting the namespace) and the result would be far simpler for people > to > configure, becomging simply That's a good idea, and as so far it needs to be specified, we simply can not break existing configs. I'll see to add it ASAP (but I am on the road tomorrow and am now preparing for it). > > $modload omudpspoof > $ActionUDPSpoofTargetHost server.example.com > *.* :omudpspoof: > > it could be simplified even further if there was some way to specify > the > destination on the action line (like the @ and @@ functions do today, > could we use @S@ to indicate spoofing?) Actually, I would not like to do that, because that would merge the functionality into omfwd. Acutally, having tcp and udp in the same module is legacy and cause quite some problems in the past. I am short of splitting these two (it would also have been very useful if we were gone for a new config format in the near term). I think it is not much more burden and clearer to read if we retain a separate module type. But I am open to discussion, I could use @S@ as an alternative module designator, that would work with the current config system, but probably not extend into a new one (whatever we will end up with). > changing the defaults should have no problems with backwards > compatibility, full ack > adding/changing how the desitnation is specified could > break backward compatibility, but this is a very new piece of > functionality and the simplification may be worth it (what versions > have > this available?) 5.1.3 and above Rainer From david at lang.hm Tue Jul 13 19:29:30 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 10:29:30 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: On Tue, 13 Jul 2010, Rainer Gerhards wrote: > To add some of the less obvious things: support for multiple listeners going > to different outputs, in an easy to use way. Support for explicitely > specified concurrency (or serialization) for high-speed environments, support > for different queues, and tying of different queues to different object > classes (inputs, message processors, actions). Flexibility to support > configuration for even unexpected plugins that we may not even know about > (because some third party writes them and never publishes them). > > But I begin to agree that we, the community, as a whole have very different > needs. I have gotten the impression that it is probably a good idea to stop > the current effort and re-start it with a requirements definition. I have > tried to digest the discussions on config format we had over the year, but > sometimes it looks like the only consensus we have is that the current format > is ugly and hard to use. The solutions are very wide-ranging. I have even > briefly looked at syslog-ng, and seen a lot of the pain again that makes me > dislike that format (but I'll probably still have a closer look and will try > to write up my detailed position why I do not find buying into this format is > a good idea). > > All in all, I think the best way to re-start our thinking about the config > format is to set up a web site where we gather user feedback on > > a) what problems they have with the config format > (not what they just dislike, but real problems, an example > From myself: it is nearly impossible to get the sequence right > To bind inputs to the right rulesets AND use ruleset inclusion) > b) which alternatives they see > > With all this being on a web site, it may be possible to craft a better > decision in 6 to 9 month, assuming we were able to gain sufficient feedback > during that time. > > An alternative would be to create a config parser interface, so that > everybody could code up his favorite config language. However, this seems to > be impractical, as many of the ideas floating around (Lua, syslog-ng style) > require not just different config parsers, but a different rsyslog processing > core as well. Obviously a complete rewrite in the case of Lua, less for > syslog-ng, but still considerate. For the syslog-ng style we would need to > create named filters, something that I really find questionable. Also, we > would need to add an interim layer between inputs and rulesets, something > that eats performance. In any case, this are not config-parser only changes. > > Of course, I could just pick one of the alternatives. However, it doesn't > make sense to invest a couple of month to do the config system "right", if we > know that a lot of folks will still be unhappy after we have done this. one thing that's really good about the current rsyslog config is that it makes doing simple things simple, especially for people used to classic syslog. as you say, we need to say what the problems there are with the existing config format and look at how to solve those. We don't necessarily need to change everything. weaknesses that I know of inability to easily/clearly define if-then-else inability to easily/clearly define/use rulesets inability to easily have multiple conditions that go to the same destination (this can be implemented via rulesets, see above) unclear scope rules for config options inability to easily/clearly define per-input rules/filters (this is part of the scope problem above) I don't think that this requires an entirely new config language. I think that almost everything can be solved with a couple simple changes to the config language (although as we found when I proposed this on June 25 there are more drastic changes under the covers to check/correct/document what gets changed when a config option is processed) Ignoring for the moment the problem of changing how the config options are processed (and the fact that you would need to know what data structures are managed/created/modified) what does the following proposal _not_ do? (pasted in from the mail on June 25 since that's now quite a ways back in the archives ;-) I would propose the following (more or less in order of difficulty) introduce scoping whenever you see a "{" in the config file, save the current config options to a stack. when you see a "}" pop the config options from the stack (undoing any changes in between) introduce statement blocks change the parser so that wherever it currently allows one action make it accept a {} block of actions (treat them as if they were multiple actions with & as the selector) introduce named actions something like sub NAME to define and use NAME to use introduce if-then-else internally you could convert it to ruleset { if condition { block discard} { block } } introduct the ability to implcitly define a ruleset if an action is a condition (i.e. nested configutations) then implicitly create a new ruleset to resolve the nesting. with these capabilities available I think that this will allow for straightforward config files representing very complex configurations with very little change internally to rsyslog. I suspect that the result is going to have some bottlenecks in complex configurations due to all the different rulesets and the passing of messages between them, but once the capability is in place in the config file the implementation under the covers could change later to be better optimized. as far as the rsyslog config being hard to understand, I think there are two conditions here. 1. very simple configs where the fact that rsyslog can use a traditional syslog config file (with a header on it that seldom needs to change) is a huge advantage 2. complex configs where the inability to define scope and nest things is a major problem and makes the resulting config hard to write. David Lang From rgerhards at hq.adiscon.com Thu Jul 15 09:41:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:41:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Hi David, thanks for the well-crafted mail. My concerns for this proposal were (and are) mainly based on the "under the cover" changes. Other than that, I think you are right, except that it boils down to personal taste. Let me ignore the internal changes for now. Throwing in "{}" creates a very compact, ultra-brief config language. But it would definitely work. I just have to admit it does not fit my *personal* taste because it carries a lot of implicit scoping as well (like what exactly is meant to be scoped by the {} -- an action, or an input, or a ruleset...). But I think the semantics of this format are close to any other config format that fits rsyslog. So I think it is probably worth giving it a try, so that we make at least some progress. The only thing I really would like to change is to use "()" instead of "{}" because I would like to reserve "{}" for future use, where it may fit the user's expectation better than simple parenthesis. But I guess that's not really a problem. One thing though, that is on my feature list is that I would like to use a more standard parser, that means one that can becreated with lex and Bison. While the hand-crafted parser is fine, it always is more work to extend and enhance it. As the parser is no critical component, I'd prefer to use the simpler approach. However, I need to check if I can find a suitable grammar for this proposal. This also works on the assumption. I'd also just concentrate on actions for now. So to double-check a fairly simple config in that format would look as follows: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files ( $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; ) ============================================================== This is based on the second example in http://www.rsyslog.com/doc-rsyslog_high_database_rate.html I will probably also begin to look at the internal changes. As it looks, we need to make them in any case. So it doesn't hurt to start with them, even though there initially will be no external (user) visibility that they are made. But at first, I'll start looking at how this may be processed by a standard flex/bison parser. From the work I already did, I know this is not easy, but could probably work. Feedback appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 7:30 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > To add some of the less obvious things: support for multiple > listeners going > > to different outputs, in an easy to use way. Support for explicitely > > specified concurrency (or serialization) for high-speed environments, > support > > for different queues, and tying of different queues to different > object > > classes (inputs, message processors, actions). Flexibility to support > > configuration for even unexpected plugins that we may not even know > about > > (because some third party writes them and never publishes them). > > > > But I begin to agree that we, the community, as a whole have very > different > > needs. I have gotten the impression that it is probably a good idea > to stop > > the current effort and re-start it with a requirements definition. I > have > > tried to digest the discussions on config format we had over the > year, but > > sometimes it looks like the only consensus we have is that the > current format > > is ugly and hard to use. The solutions are very wide-ranging. I have > even > > briefly looked at syslog-ng, and seen a lot of the pain again that > makes me > > dislike that format (but I'll probably still have a closer look and > will try > > to write up my detailed position why I do not find buying into this > format is > > a good idea). > > > > All in all, I think the best way to re-start our thinking about the > config > > format is to set up a web site where we gather user feedback on > > > > a) what problems they have with the config format > > (not what they just dislike, but real problems, an example > > From myself: it is nearly impossible to get the sequence right > > To bind inputs to the right rulesets AND use ruleset inclusion) > > b) which alternatives they see > > > > With all this being on a web site, it may be possible to craft a > better > > decision in 6 to 9 month, assuming we were able to gain sufficient > feedback > > during that time. > > > > An alternative would be to create a config parser interface, so that > > everybody could code up his favorite config language. However, this > seems to > > be impractical, as many of the ideas floating around (Lua, syslog-ng > style) > > require not just different config parsers, but a different rsyslog > processing > > core as well. Obviously a complete rewrite in the case of Lua, less > for > > syslog-ng, but still considerate. For the syslog-ng style we would > need to > > create named filters, something that I really find questionable. > Also, we > > would need to add an interim layer between inputs and rulesets, > something > > that eats performance. In any case, this are not config-parser only > changes. > > > > Of course, I could just pick one of the alternatives. However, it > doesn't > > make sense to invest a couple of month to do the config system > "right", if we > > know that a lot of folks will still be unhappy after we have done > this. > > one thing that's really good about the current rsyslog config is that > it > makes doing simple things simple, especially for people used to classic > syslog. > > as you say, we need to say what the problems there are with the > existing > config format and look at how to solve those. We don't necessarily need > to > change everything. > > weaknesses that I know of > > inability to easily/clearly define if-then-else > > inability to easily/clearly define/use rulesets > > inability to easily have multiple conditions that go to the same > destination (this can be implemented via rulesets, see above) > > unclear scope rules for config options > > inability to easily/clearly define per-input rules/filters (this is > part > of the scope problem above) > > > I don't think that this requires an entirely new config language. I > think > that almost everything can be solved with a couple simple changes to > the > config language (although as we found when I proposed this on June 25 > there are more drastic changes under the covers to > check/correct/document > what gets changed when a config option is processed) > > > Ignoring for the moment the problem of changing how the config options > are > processed (and the fact that you would need to know what data > structures > are managed/created/modified) what does the following proposal _not_ > do? > > (pasted in from the mail on June 25 since that's now quite a ways back > in > the archives ;-) > > > > I would propose the following (more or less in order of difficulty) > > introduce scoping > > whenever you see a "{" in the config file, save the current config > options to a stack. when you see a "}" pop the config options from the > stack (undoing any changes in between) introduce statement blocks > change the parser so that wherever it currently allows one action > make > it accept a {} block of actions (treat them as if they were multiple > actions with & as the selector) > > introduce named actions > > something like sub NAME to define and use NAME to use > > introduce if-then-else > > internally you could convert it to > > ruleset { > if condition { > block > discard} > { block } } > > introduct the ability to implcitly define a ruleset > > if an action is a condition (i.e. nested configutations) then > implicitly > create a new ruleset to resolve the nesting. > > > with these capabilities available I think that this will allow for > straightforward config files representing very complex configurations > with > very little change internally to rsyslog. > > I suspect that the result is going to have some bottlenecks in complex > configurations due to all the different rulesets and the passing of > messages between them, but once the capability is in place in the > config > file the implementation under the covers could change later to be > better > optimized. > > as far as the rsyslog config being hard to understand, I think there > are > two conditions here. > > 1. very simple configs where the fact that rsyslog can use a > traditional > syslog config file (with a header on it that seldom needs to change) is > a > huge advantage > > 2. complex configs where the inability to define scope and nest things > is > a major problem and makes the resulting config hard to write. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 09:50:55 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 00:50:55 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were (and > are) mainly based on the "under the cover" changes. Other than that, I think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. But it > would definitely work. I just have to admit it does not fit my *personal* > taste because it carries a lot of implicit scoping as well (like what exactly > is meant to be scoped by the {} -- an action, or an input, or a ruleset...). > But I think the semantics of this format are close to any other config format > that fits rsyslog. So I think it is probably worth giving it a try, so that > we make at least some progress. The only thing I really would like to change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. sure, I suggested {} in part from habit as they are used to defien blocks in several languages while () tends to be used for parameters to a function, but this is a cosmetic change (and easy to tweak once a proof-of-concept parser is available) > One thing though, that is on my feature list is that I would like to use a > more standard parser, that means one that can becreated with lex and Bison. > While the hand-crafted parser is fine, it always is more work to extend and > enhance it. As the parser is no critical component, I'd prefer to use the > simpler approach. However, I need to check if I can find a suitable grammar > for this proposal. This also works on the assumption. I don't see this as a problem. It's work to define a parser, but I don't think that the current grammer is significantly harder to put into a lex/bison parser than any other (the exception being the implicit scoping rules) > I'd also just concentrate on actions for now. So to double-check a fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html looks sane to me. one question, does the comment really mean what it sounds like on this line? $ActionQueueType LinkedList # use asynchronous processing This makes it sound like you don't do async processing if you use the default queue type. I didn't think that that was the case. > I will probably also begin to look at the internal changes. As it looks, we > need to make them in any case. So it doesn't hurt to start with them, even > though there initially will be no external (user) visibility that they are > made. I agree, the changes that I think are going to be needed are as much documentation as they are functional changes. Makeing sure that we know what variables are changed by each config line that's possible, and making it so that these changes are done in a way that they can be swapped out for a different set of values as scope changes happen. David Lang > But at first, I'll start looking at how this may be processed by a standard > flex/bison parser. From the work I already did, I know this is not easy, but > could probably work. > > Feedback appreciated. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, July 13, 2010 7:30 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >> >>> To add some of the less obvious things: support for multiple >> listeners going >>> to different outputs, in an easy to use way. Support for explicitely >>> specified concurrency (or serialization) for high-speed environments, >> support >>> for different queues, and tying of different queues to different >> object >>> classes (inputs, message processors, actions). Flexibility to support >>> configuration for even unexpected plugins that we may not even know >> about >>> (because some third party writes them and never publishes them). >>> >>> But I begin to agree that we, the community, as a whole have very >> different >>> needs. I have gotten the impression that it is probably a good idea >> to stop >>> the current effort and re-start it with a requirements definition. I >> have >>> tried to digest the discussions on config format we had over the >> year, but >>> sometimes it looks like the only consensus we have is that the >> current format >>> is ugly and hard to use. The solutions are very wide-ranging. I have >> even >>> briefly looked at syslog-ng, and seen a lot of the pain again that >> makes me >>> dislike that format (but I'll probably still have a closer look and >> will try >>> to write up my detailed position why I do not find buying into this >> format is >>> a good idea). >>> >>> All in all, I think the best way to re-start our thinking about the >> config >>> format is to set up a web site where we gather user feedback on >>> >>> a) what problems they have with the config format >>> (not what they just dislike, but real problems, an example >>> From myself: it is nearly impossible to get the sequence right >>> To bind inputs to the right rulesets AND use ruleset inclusion) >>> b) which alternatives they see >>> >>> With all this being on a web site, it may be possible to craft a >> better >>> decision in 6 to 9 month, assuming we were able to gain sufficient >> feedback >>> during that time. >>> >>> An alternative would be to create a config parser interface, so that >>> everybody could code up his favorite config language. However, this >> seems to >>> be impractical, as many of the ideas floating around (Lua, syslog-ng >> style) >>> require not just different config parsers, but a different rsyslog >> processing >>> core as well. Obviously a complete rewrite in the case of Lua, less >> for >>> syslog-ng, but still considerate. For the syslog-ng style we would >> need to >>> create named filters, something that I really find questionable. >> Also, we >>> would need to add an interim layer between inputs and rulesets, >> something >>> that eats performance. In any case, this are not config-parser only >> changes. >>> >>> Of course, I could just pick one of the alternatives. However, it >> doesn't >>> make sense to invest a couple of month to do the config system >> "right", if we >>> know that a lot of folks will still be unhappy after we have done >> this. >> >> one thing that's really good about the current rsyslog config is that >> it >> makes doing simple things simple, especially for people used to classic >> syslog. >> >> as you say, we need to say what the problems there are with the >> existing >> config format and look at how to solve those. We don't necessarily need >> to >> change everything. >> >> weaknesses that I know of >> >> inability to easily/clearly define if-then-else >> >> inability to easily/clearly define/use rulesets >> >> inability to easily have multiple conditions that go to the same >> destination (this can be implemented via rulesets, see above) >> >> unclear scope rules for config options >> >> inability to easily/clearly define per-input rules/filters (this is >> part >> of the scope problem above) >> >> >> I don't think that this requires an entirely new config language. I >> think >> that almost everything can be solved with a couple simple changes to >> the >> config language (although as we found when I proposed this on June 25 >> there are more drastic changes under the covers to >> check/correct/document >> what gets changed when a config option is processed) >> >> >> Ignoring for the moment the problem of changing how the config options >> are >> processed (and the fact that you would need to know what data >> structures >> are managed/created/modified) what does the following proposal _not_ >> do? >> >> (pasted in from the mail on June 25 since that's now quite a ways back >> in >> the archives ;-) >> >> >> >> I would propose the following (more or less in order of difficulty) >> >> introduce scoping >> >> whenever you see a "{" in the config file, save the current config >> options to a stack. when you see a "}" pop the config options from the >> stack (undoing any changes in between) introduce statement blocks >> change the parser so that wherever it currently allows one action >> make >> it accept a {} block of actions (treat them as if they were multiple >> actions with & as the selector) >> >> introduce named actions >> >> something like sub NAME to define and use NAME to use >> >> introduce if-then-else >> >> internally you could convert it to >> >> ruleset { >> if condition { >> block >> discard} >> { block } } >> >> introduct the ability to implcitly define a ruleset >> >> if an action is a condition (i.e. nested configutations) then >> implicitly >> create a new ruleset to resolve the nesting. >> >> >> with these capabilities available I think that this will allow for >> straightforward config files representing very complex configurations >> with >> very little change internally to rsyslog. >> >> I suspect that the result is going to have some bottlenecks in complex >> configurations due to all the different rulesets and the passing of >> messages between them, but once the capability is in place in the >> config >> file the implementation under the covers could change later to be >> better >> optimized. >> >> as far as the rsyslog config being hard to understand, I think there >> are >> two conditions here. >> >> 1. very simple configs where the fact that rsyslog can use a >> traditional >> syslog config file (with a header on it that seldom needs to change) is >> a >> huge advantage >> >> 2. complex configs where the inability to define scope and nest things >> is >> a major problem and makes the resulting config hard to write. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 09:53:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:53:35 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> After writing this, it just hit me that we could stay within the current config notation by introducing $begin $name $end Constructs and don't change anything at the config language at all. The sample below could then be: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files $Begin action $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; $End action ============================================================== This would probably be possible to implement within the constraints of the current config parser. We could also add a directive $StrictScoping on to instruct rsyslog to disallow and $Action directives outside of scoped blocks (this could be good to guard against accidential global directives). That still requires reworking of the internals, but would not need a new (real) grammar, so it would be considerable less work. I still need to see how it would work with more complex configs, but assuming we have things like $Begin Ruleset $Begin Rule $Begin Input I think the same paradigm could probably be used for everything (and that than would eliminate the need for a new grammar). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 15, 2010 9:42 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were > (and > are) mainly based on the "under the cover" changes. Other than that, I > think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. > But it > would definitely work. I just have to admit it does not fit my > *personal* > taste because it carries a lot of implicit scoping as well (like what > exactly > is meant to be scoped by the {} -- an action, or an input, or a > ruleset...). > But I think the semantics of this format are close to any other config > format > that fits rsyslog. So I think it is probably worth giving it a try, so > that > we make at least some progress. The only thing I really would like to > change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. > > One thing though, that is on my feature list is that I would like to > use a > more standard parser, that means one that can becreated with lex and > Bison. > While the hand-crafted parser is fine, it always is more work to extend > and > enhance it. As the parser is no critical component, I'd prefer to use > the > simpler approach. However, I need to check if I can find a suitable > grammar > for this proposal. This also works on the assumption. > > I'd also just concentrate on actions for now. So to double-check a > fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > > I will probably also begin to look at the internal changes. As it > looks, we > need to make them in any case. So it doesn't hurt to start with them, > even > though there initially will be no external (user) visibility that they > are > made. > > But at first, I'll start looking at how this may be processed by a > standard > flex/bison parser. From the work I already did, I know this is not > easy, but > could probably work. > > Feedback appreciated. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > Sent: Tuesday, July 13, 2010 7:30 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] NEW rsyslog.conf format > > > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > > > To add some of the less obvious things: support for multiple > > listeners going > > > to different outputs, in an easy to use way. Support for > explicitely > > > specified concurrency (or serialization) for high-speed > environments, > > support > > > for different queues, and tying of different queues to different > > object > > > classes (inputs, message processors, actions). Flexibility to > support > > > configuration for even unexpected plugins that we may not even know > > about > > > (because some third party writes them and never publishes them). > > > > > > But I begin to agree that we, the community, as a whole have very > > different > > > needs. I have gotten the impression that it is probably a good idea > > to stop > > > the current effort and re-start it with a requirements definition. > I > > have > > > tried to digest the discussions on config format we had over the > > year, but > > > sometimes it looks like the only consensus we have is that the > > current format > > > is ugly and hard to use. The solutions are very wide-ranging. I > have > > even > > > briefly looked at syslog-ng, and seen a lot of the pain again that > > makes me > > > dislike that format (but I'll probably still have a closer look and > > will try > > > to write up my detailed position why I do not find buying into this > > format is > > > a good idea). > > > > > > All in all, I think the best way to re-start our thinking about the > > config > > > format is to set up a web site where we gather user feedback on > > > > > > a) what problems they have with the config format > > > (not what they just dislike, but real problems, an example > > > From myself: it is nearly impossible to get the sequence right > > > To bind inputs to the right rulesets AND use ruleset inclusion) > > > b) which alternatives they see > > > > > > With all this being on a web site, it may be possible to craft a > > better > > > decision in 6 to 9 month, assuming we were able to gain sufficient > > feedback > > > during that time. > > > > > > An alternative would be to create a config parser interface, so > that > > > everybody could code up his favorite config language. However, this > > seems to > > > be impractical, as many of the ideas floating around (Lua, syslog- > ng > > style) > > > require not just different config parsers, but a different rsyslog > > processing > > > core as well. Obviously a complete rewrite in the case of Lua, less > > for > > > syslog-ng, but still considerate. For the syslog-ng style we would > > need to > > > create named filters, something that I really find questionable. > > Also, we > > > would need to add an interim layer between inputs and rulesets, > > something > > > that eats performance. In any case, this are not config-parser only > > changes. > > > > > > Of course, I could just pick one of the alternatives. However, it > > doesn't > > > make sense to invest a couple of month to do the config system > > "right", if we > > > know that a lot of folks will still be unhappy after we have done > > this. > > > > one thing that's really good about the current rsyslog config is that > > it > > makes doing simple things simple, especially for people used to > classic > > syslog. > > > > as you say, we need to say what the problems there are with the > > existing > > config format and look at how to solve those. We don't necessarily > need > > to > > change everything. > > > > weaknesses that I know of > > > > inability to easily/clearly define if-then-else > > > > inability to easily/clearly define/use rulesets > > > > inability to easily have multiple conditions that go to the same > > destination (this can be implemented via rulesets, see above) > > > > unclear scope rules for config options > > > > inability to easily/clearly define per-input rules/filters (this is > > part > > of the scope problem above) > > > > > > I don't think that this requires an entirely new config language. I > > think > > that almost everything can be solved with a couple simple changes to > > the > > config language (although as we found when I proposed this on June 25 > > there are more drastic changes under the covers to > > check/correct/document > > what gets changed when a config option is processed) > > > > > > Ignoring for the moment the problem of changing how the config > options > > are > > processed (and the fact that you would need to know what data > > structures > > are managed/created/modified) what does the following proposal _not_ > > do? > > > > (pasted in from the mail on June 25 since that's now quite a ways > back > > in > > the archives ;-) > > > > > > > > I would propose the following (more or less in order of difficulty) > > > > introduce scoping > > > > whenever you see a "{" in the config file, save the current config > > options to a stack. when you see a "}" pop the config options from > the > > stack (undoing any changes in between) introduce statement blocks > > change the parser so that wherever it currently allows one action > > make > > it accept a {} block of actions (treat them as if they were multiple > > actions with & as the selector) > > > > introduce named actions > > > > something like sub NAME to define and use NAME to use > > > > introduce if-then-else > > > > internally you could convert it to > > > > ruleset { > > if condition { > > block > > discard} > > { block } } > > > > introduct the ability to implcitly define a ruleset > > > > if an action is a condition (i.e. nested configutations) then > > implicitly > > create a new ruleset to resolve the nesting. > > > > > > with these capabilities available I think that this will allow for > > straightforward config files representing very complex configurations > > with > > very little change internally to rsyslog. > > > > I suspect that the result is going to have some bottlenecks in > complex > > configurations due to all the different rulesets and the passing of > > messages between them, but once the capability is in place in the > > config > > file the implementation under the covers could change later to be > > better > > optimized. > > > > as far as the rsyslog config being hard to understand, I think there > > are > > two conditions here. > > > > 1. very simple configs where the fact that rsyslog can use a > > traditional > > syslog config file (with a header on it that seldom needs to change) > is > > a > > huge advantage > > > > 2. complex configs where the inability to define scope and nest > things > > is > > a major problem and makes the resulting config hard to write. > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 10:00:42 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:00:42 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > After writing this, it just hit me that we could stay within the current > config notation by introducing > > $begin > $end I have no problem with this. I view is as symatically eqivalent to the {}(), just more characters to type ;-) > $name I had even suggested NAME block and USE syntaxes the only question is if we need to explicitly state the type or if it's good enough to be able to just nest the scope. I think you can get away with just nesting the scope, but I could be wrong and if so defining the type is a fairly cheap way of working around the issue. > The sample below could then be: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > $Begin action > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > $End action > ============================================================== > > This would probably be possible to implement within the constraints of the > current config parser. We could also add a directive > > $StrictScoping on > > to instruct rsyslog to disallow and $Action directives outside of > scoped blocks (this could be good to guard against accidential global > directives). probably a good idea. > That still requires reworking of the internals, but would not need a new > (real) grammar, so it would be considerable less work. I still need to see > how it would work with more complex configs, but assuming we have things like > > $Begin Ruleset > $Begin Rule > $Begin Input > > I think the same paradigm could probably be used for everything (and that > than would eliminate the need for a new grammar). sounds good. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Thursday, July 15, 2010 9:42 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Hi David, >> >> thanks for the well-crafted mail. My concerns for this proposal were >> (and >> are) mainly based on the "under the cover" changes. Other than that, I >> think >> you are right, except that it boils down to personal taste. >> >> Let me ignore the internal changes for now. >> >> Throwing in "{}" creates a very compact, ultra-brief config language. >> But it >> would definitely work. I just have to admit it does not fit my >> *personal* >> taste because it carries a lot of implicit scoping as well (like what >> exactly >> is meant to be scoped by the {} -- an action, or an input, or a >> ruleset...). >> But I think the semantics of this format are close to any other config >> format >> that fits rsyslog. So I think it is probably worth giving it a try, so >> that >> we make at least some progress. The only thing I really would like to >> change >> is to use "()" instead of "{}" because I would like to reserve "{}" for >> future use, where it may fit the user's expectation better than simple >> parenthesis. But I guess that's not really a problem. >> >> One thing though, that is on my feature list is that I would like to >> use a >> more standard parser, that means one that can becreated with lex and >> Bison. >> While the hand-crafted parser is fine, it always is more work to extend >> and >> enhance it. As the parser is no critical component, I'd prefer to use >> the >> simpler approach. However, I need to check if I can find a suitable >> grammar >> for this proposal. This also works on the assumption. >> >> I'd also just concentrate on actions for now. So to double-check a >> fairly >> simple config in that format would look as follows: >> >> ============================================================== >> $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) >> $ModLoad imudp # network reception >> $UDPServerRun 514 # start a udp server at port 514 >> $ModLoad imuxsock # local message reception >> >> $WorkDirectory /rsyslog/work # default location for work (spool) files >> >> ( >> $ActionQueueType LinkedList # use asynchronous processing >> $ActionQueueFileName dbq # set file name, also enables disk mode >> $ActionResumeRetryCount -1 # infinite retries on insert failure >> # for PostgreSQL replace :ommysql: by :ompgsql: below: >> *.* :ommysql:hostname,dbname,userid,password; >> ) >> ============================================================== >> >> This is based on the second example in >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html >> >> I will probably also begin to look at the internal changes. As it >> looks, we >> need to make them in any case. So it doesn't hurt to start with them, >> even >> though there initially will be no external (user) visibility that they >> are >> made. >> >> But at first, I'll start looking at how this may be processed by a >> standard >> flex/bison parser. From the work I already did, I know this is not >> easy, but >> could probably work. >> >> Feedback appreciated. >> >> Rainer >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>> Sent: Tuesday, July 13, 2010 7:30 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >>> >>>> To add some of the less obvious things: support for multiple >>> listeners going >>>> to different outputs, in an easy to use way. Support for >> explicitely >>>> specified concurrency (or serialization) for high-speed >> environments, >>> support >>>> for different queues, and tying of different queues to different >>> object >>>> classes (inputs, message processors, actions). Flexibility to >> support >>>> configuration for even unexpected plugins that we may not even know >>> about >>>> (because some third party writes them and never publishes them). >>>> >>>> But I begin to agree that we, the community, as a whole have very >>> different >>>> needs. I have gotten the impression that it is probably a good idea >>> to stop >>>> the current effort and re-start it with a requirements definition. >> I >>> have >>>> tried to digest the discussions on config format we had over the >>> year, but >>>> sometimes it looks like the only consensus we have is that the >>> current format >>>> is ugly and hard to use. The solutions are very wide-ranging. I >> have >>> even >>>> briefly looked at syslog-ng, and seen a lot of the pain again that >>> makes me >>>> dislike that format (but I'll probably still have a closer look and >>> will try >>>> to write up my detailed position why I do not find buying into this >>> format is >>>> a good idea). >>>> >>>> All in all, I think the best way to re-start our thinking about the >>> config >>>> format is to set up a web site where we gather user feedback on >>>> >>>> a) what problems they have with the config format >>>> (not what they just dislike, but real problems, an example >>>> From myself: it is nearly impossible to get the sequence right >>>> To bind inputs to the right rulesets AND use ruleset inclusion) >>>> b) which alternatives they see >>>> >>>> With all this being on a web site, it may be possible to craft a >>> better >>>> decision in 6 to 9 month, assuming we were able to gain sufficient >>> feedback >>>> during that time. >>>> >>>> An alternative would be to create a config parser interface, so >> that >>>> everybody could code up his favorite config language. However, this >>> seems to >>>> be impractical, as many of the ideas floating around (Lua, syslog- >> ng >>> style) >>>> require not just different config parsers, but a different rsyslog >>> processing >>>> core as well. Obviously a complete rewrite in the case of Lua, less >>> for >>>> syslog-ng, but still considerate. For the syslog-ng style we would >>> need to >>>> create named filters, something that I really find questionable. >>> Also, we >>>> would need to add an interim layer between inputs and rulesets, >>> something >>>> that eats performance. In any case, this are not config-parser only >>> changes. >>>> >>>> Of course, I could just pick one of the alternatives. However, it >>> doesn't >>>> make sense to invest a couple of month to do the config system >>> "right", if we >>>> know that a lot of folks will still be unhappy after we have done >>> this. >>> >>> one thing that's really good about the current rsyslog config is that >>> it >>> makes doing simple things simple, especially for people used to >> classic >>> syslog. >>> >>> as you say, we need to say what the problems there are with the >>> existing >>> config format and look at how to solve those. We don't necessarily >> need >>> to >>> change everything. >>> >>> weaknesses that I know of >>> >>> inability to easily/clearly define if-then-else >>> >>> inability to easily/clearly define/use rulesets >>> >>> inability to easily have multiple conditions that go to the same >>> destination (this can be implemented via rulesets, see above) >>> >>> unclear scope rules for config options >>> >>> inability to easily/clearly define per-input rules/filters (this is >>> part >>> of the scope problem above) >>> >>> >>> I don't think that this requires an entirely new config language. I >>> think >>> that almost everything can be solved with a couple simple changes to >>> the >>> config language (although as we found when I proposed this on June 25 >>> there are more drastic changes under the covers to >>> check/correct/document >>> what gets changed when a config option is processed) >>> >>> >>> Ignoring for the moment the problem of changing how the config >> options >>> are >>> processed (and the fact that you would need to know what data >>> structures >>> are managed/created/modified) what does the following proposal _not_ >>> do? >>> >>> (pasted in from the mail on June 25 since that's now quite a ways >> back >>> in >>> the archives ;-) >>> >>> >>> >>> I would propose the following (more or less in order of difficulty) >>> >>> introduce scoping >>> >>> whenever you see a "{" in the config file, save the current config >>> options to a stack. when you see a "}" pop the config options from >> the >>> stack (undoing any changes in between) introduce statement blocks >>> change the parser so that wherever it currently allows one action >>> make >>> it accept a {} block of actions (treat them as if they were multiple >>> actions with & as the selector) >>> >>> introduce named actions >>> >>> something like sub NAME to define and use NAME to use >>> >>> introduce if-then-else >>> >>> internally you could convert it to >>> >>> ruleset { >>> if condition { >>> block >>> discard} >>> { block } } >>> >>> introduct the ability to implcitly define a ruleset >>> >>> if an action is a condition (i.e. nested configutations) then >>> implicitly >>> create a new ruleset to resolve the nesting. >>> >>> >>> with these capabilities available I think that this will allow for >>> straightforward config files representing very complex configurations >>> with >>> very little change internally to rsyslog. >>> >>> I suspect that the result is going to have some bottlenecks in >> complex >>> configurations due to all the different rulesets and the passing of >>> messages between them, but once the capability is in place in the >>> config >>> file the implementation under the covers could change later to be >>> better >>> optimized. >>> >>> as far as the rsyslog config being hard to understand, I think there >>> are >>> two conditions here. >>> >>> 1. very simple configs where the fact that rsyslog can use a >>> traditional >>> syslog config file (with a header on it that seldom needs to change) >> is >>> a >>> huge advantage >>> >>> 2. complex configs where the inability to define scope and nest >> things >>> is >>> a major problem and makes the resulting config hard to write. >>> >>> David Lang >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 10:08:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:08:58 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB0@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 15, 2010 10:01 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Thu, 15 Jul 2010, Rainer Gerhards wrote: > > > After writing this, it just hit me that we could stay within the > current > > config notation by introducing > > > > $begin > > $end > > I have no problem with this. I view is as symatically eqivalent to the > {}(), just more characters to type ;-) Jupp, but the big difference is that the current parser can handle that. Also, if we really stick with the language, I personally think this is more consistent with the rest of the language (but that's again an issue of personal taste). > > $name > > I had even suggested NAME block and USE syntaxes Ack, didn't mention it explicitely, but definitely kept it on my mind ;) > > the only question is if we need to explicitly state the type or if it's > good enough to be able to just nest the scope. I think you can get away > with just nesting the scope, but I could be wrong and if so defining > the > type is a fairly cheap way of working around the issue. Again a taste issue first: I think it is less confusing for a human to know what exactly the block defines. But there is also a hard argument: if I know it is an action, I can disallow input or global statements inside this block (and vice versa)! So we do not only get the scoping, but also the capability to not permit irrelevant statements within the scope. The only thing I need to change is add a type to each config statement (in the statement table), but this is not much work (given the fact that I need to change some internals in any way to support the scoping). Rainer > > > The sample below could then be: > > > > ============================================================== > > $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > > $ModLoad imudp # network reception > > $UDPServerRun 514 # start a udp server at port 514 > > $ModLoad imuxsock # local message reception > > > > $WorkDirectory /rsyslog/work # default location for work (spool) > files > > > > $Begin action > > $ActionQueueType LinkedList # use asynchronous processing > > $ActionQueueFileName dbq # set file name, also enables disk mode > > $ActionResumeRetryCount -1 # infinite retries on insert failure > > # for PostgreSQL replace :ommysql: by :ompgsql: below: > > *.* :ommysql:hostname,dbname,userid,password; > > $End action > > ============================================================== > > > > This would probably be possible to implement within the constraints > of the > > current config parser. We could also add a directive > > > > $StrictScoping on > > > > to instruct rsyslog to disallow and $Action directives > outside of > > scoped blocks (this could be good to guard against accidential global > > directives). > > probably a good idea. > > > That still requires reworking of the internals, but would not need a > new > > (real) grammar, so it would be considerable less work. I still need > to see > > how it would work with more complex configs, but assuming we have > things like > > > > $Begin Ruleset > > $Begin Rule > > $Begin Input > > > > I think the same paradigm could probably be used for everything (and > that > > than would eliminate the need for a new grammar). > > sounds good. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > >> Sent: Thursday, July 15, 2010 9:42 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> Hi David, > >> > >> thanks for the well-crafted mail. My concerns for this proposal were > >> (and > >> are) mainly based on the "under the cover" changes. Other than that, > I > >> think > >> you are right, except that it boils down to personal taste. > >> > >> Let me ignore the internal changes for now. > >> > >> Throwing in "{}" creates a very compact, ultra-brief config > language. > >> But it > >> would definitely work. I just have to admit it does not fit my > >> *personal* > >> taste because it carries a lot of implicit scoping as well (like > what > >> exactly > >> is meant to be scoped by the {} -- an action, or an input, or a > >> ruleset...). > >> But I think the semantics of this format are close to any other > config > >> format > >> that fits rsyslog. So I think it is probably worth giving it a try, > so > >> that > >> we make at least some progress. The only thing I really would like > to > >> change > >> is to use "()" instead of "{}" because I would like to reserve "{}" > for > >> future use, where it may fit the user's expectation better than > simple > >> parenthesis. But I guess that's not really a problem. > >> > >> One thing though, that is on my feature list is that I would like to > >> use a > >> more standard parser, that means one that can becreated with lex and > >> Bison. > >> While the hand-crafted parser is fine, it always is more work to > extend > >> and > >> enhance it. As the parser is no critical component, I'd prefer to > use > >> the > >> simpler approach. However, I need to check if I can find a suitable > >> grammar > >> for this proposal. This also works on the assumption. > >> > >> I'd also just concentrate on actions for now. So to double-check a > >> fairly > >> simple config in that format would look as follows: > >> > >> ============================================================== > >> $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > >> $ModLoad imudp # network reception > >> $UDPServerRun 514 # start a udp server at port 514 > >> $ModLoad imuxsock # local message reception > >> > >> $WorkDirectory /rsyslog/work # default location for work (spool) > files > >> > >> ( > >> $ActionQueueType LinkedList # use asynchronous processing > >> $ActionQueueFileName dbq # set file name, also enables disk mode > >> $ActionResumeRetryCount -1 # infinite retries on insert failure > >> # for PostgreSQL replace :ommysql: by :ompgsql: below: > >> *.* :ommysql:hostname,dbname,userid,password; > >> ) > >> ============================================================== > >> > >> This is based on the second example in > >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > >> > >> I will probably also begin to look at the internal changes. As it > >> looks, we > >> need to make them in any case. So it doesn't hurt to start with > them, > >> even > >> though there initially will be no external (user) visibility that > they > >> are > >> made. > >> > >> But at first, I'll start looking at how this may be processed by a > >> standard > >> flex/bison parser. From the work I already did, I know this is not > >> easy, but > >> could probably work. > >> > >> Feedback appreciated. > >> > >> Rainer > >> > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >>> Sent: Tuesday, July 13, 2010 7:30 PM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: > >>> > >>>> To add some of the less obvious things: support for multiple > >>> listeners going > >>>> to different outputs, in an easy to use way. Support for > >> explicitely > >>>> specified concurrency (or serialization) for high-speed > >> environments, > >>> support > >>>> for different queues, and tying of different queues to different > >>> object > >>>> classes (inputs, message processors, actions). Flexibility to > >> support > >>>> configuration for even unexpected plugins that we may not even > know > >>> about > >>>> (because some third party writes them and never publishes them). > >>>> > >>>> But I begin to agree that we, the community, as a whole have very > >>> different > >>>> needs. I have gotten the impression that it is probably a good > idea > >>> to stop > >>>> the current effort and re-start it with a requirements definition. > >> I > >>> have > >>>> tried to digest the discussions on config format we had over the > >>> year, but > >>>> sometimes it looks like the only consensus we have is that the > >>> current format > >>>> is ugly and hard to use. The solutions are very wide-ranging. I > >> have > >>> even > >>>> briefly looked at syslog-ng, and seen a lot of the pain again that > >>> makes me > >>>> dislike that format (but I'll probably still have a closer look > and > >>> will try > >>>> to write up my detailed position why I do not find buying into > this > >>> format is > >>>> a good idea). > >>>> > >>>> All in all, I think the best way to re-start our thinking about > the > >>> config > >>>> format is to set up a web site where we gather user feedback on > >>>> > >>>> a) what problems they have with the config format > >>>> (not what they just dislike, but real problems, an example > >>>> From myself: it is nearly impossible to get the sequence right > >>>> To bind inputs to the right rulesets AND use ruleset inclusion) > >>>> b) which alternatives they see > >>>> > >>>> With all this being on a web site, it may be possible to craft a > >>> better > >>>> decision in 6 to 9 month, assuming we were able to gain sufficient > >>> feedback > >>>> during that time. > >>>> > >>>> An alternative would be to create a config parser interface, so > >> that > >>>> everybody could code up his favorite config language. However, > this > >>> seems to > >>>> be impractical, as many of the ideas floating around (Lua, syslog- > >> ng > >>> style) > >>>> require not just different config parsers, but a different rsyslog > >>> processing > >>>> core as well. Obviously a complete rewrite in the case of Lua, > less > >>> for > >>>> syslog-ng, but still considerate. For the syslog-ng style we would > >>> need to > >>>> create named filters, something that I really find questionable. > >>> Also, we > >>>> would need to add an interim layer between inputs and rulesets, > >>> something > >>>> that eats performance. In any case, this are not config-parser > only > >>> changes. > >>>> > >>>> Of course, I could just pick one of the alternatives. However, it > >>> doesn't > >>>> make sense to invest a couple of month to do the config system > >>> "right", if we > >>>> know that a lot of folks will still be unhappy after we have done > >>> this. > >>> > >>> one thing that's really good about the current rsyslog config is > that > >>> it > >>> makes doing simple things simple, especially for people used to > >> classic > >>> syslog. > >>> > >>> as you say, we need to say what the problems there are with the > >>> existing > >>> config format and look at how to solve those. We don't necessarily > >> need > >>> to > >>> change everything. > >>> > >>> weaknesses that I know of > >>> > >>> inability to easily/clearly define if-then-else > >>> > >>> inability to easily/clearly define/use rulesets > >>> > >>> inability to easily have multiple conditions that go to the same > >>> destination (this can be implemented via rulesets, see above) > >>> > >>> unclear scope rules for config options > >>> > >>> inability to easily/clearly define per-input rules/filters (this is > >>> part > >>> of the scope problem above) > >>> > >>> > >>> I don't think that this requires an entirely new config language. I > >>> think > >>> that almost everything can be solved with a couple simple changes > to > >>> the > >>> config language (although as we found when I proposed this on June > 25 > >>> there are more drastic changes under the covers to > >>> check/correct/document > >>> what gets changed when a config option is processed) > >>> > >>> > >>> Ignoring for the moment the problem of changing how the config > >> options > >>> are > >>> processed (and the fact that you would need to know what data > >>> structures > >>> are managed/created/modified) what does the following proposal > _not_ > >>> do? > >>> > >>> (pasted in from the mail on June 25 since that's now quite a ways > >> back > >>> in > >>> the archives ;-) > >>> > >>> > >>> > >>> I would propose the following (more or less in order of difficulty) > >>> > >>> introduce scoping > >>> > >>> whenever you see a "{" in the config file, save the current > config > >>> options to a stack. when you see a "}" pop the config options from > >> the > >>> stack (undoing any changes in between) introduce statement blocks > >>> change the parser so that wherever it currently allows one > action > >>> make > >>> it accept a {} block of actions (treat them as if they were > multiple > >>> actions with & as the selector) > >>> > >>> introduce named actions > >>> > >>> something like sub NAME to define and use NAME to use > >>> > >>> introduce if-then-else > >>> > >>> internally you could convert it to > >>> > >>> ruleset { > >>> if condition { > >>> block > >>> discard} > >>> { block } } > >>> > >>> introduct the ability to implcitly define a ruleset > >>> > >>> if an action is a condition (i.e. nested configutations) then > >>> implicitly > >>> create a new ruleset to resolve the nesting. > >>> > >>> > >>> with these capabilities available I think that this will allow for > >>> straightforward config files representing very complex > configurations > >>> with > >>> very little change internally to rsyslog. > >>> > >>> I suspect that the result is going to have some bottlenecks in > >> complex > >>> configurations due to all the different rulesets and the passing of > >>> messages between them, but once the capability is in place in the > >>> config > >>> file the implementation under the covers could change later to be > >>> better > >>> optimized. > >>> > >>> as far as the rsyslog config being hard to understand, I think > there > >>> are > >>> two conditions here. > >>> > >>> 1. very simple configs where the fact that rsyslog can use a > >>> traditional > >>> syslog config file (with a header on it that seldom needs to > change) > >> is > >>> a > >>> huge advantage > >>> > >>> 2. complex configs where the inability to define scope and nest > >> things > >>> is > >>> a major problem and makes the resulting config hard to write. > >>> > >>> David Lang > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 15 10:14:19 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:14:19 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> While I think we alread settle fort he other alternative, there is one point I'D like to take (as it may be important for future discussions): > > One thing though, that is on my feature list is that I would like to > use a > > more standard parser, that means one that can becreated with lex and > Bison. > > While the hand-crafted parser is fine, it always is more work to > extend and > > enhance it. As the parser is no critical component, I'd prefer to use > the > > simpler approach. However, I need to check if I can find a suitable > grammar > > for this proposal. This also works on the assumption. > > I don't see this as a problem. It's work to define a parser, but I > don't > think that the current grammer is significantly harder to put into a > lex/bison parser than any other (the exception being the implicit > scoping > rules) A problem from the grammer PoV is that a traditional action line has no structure at all. It is anything from the first non-whitespace after the filter to the end of line. So here we need LF as a delimiter, while in all other cases, NL should be consider as whitespace and be discarded. You really can't specify this with a decent contextfree grammar, but Flex's substates most probably provide sufficient power to cover these "two languages in one" approach. But as I said ... this seem no longer be relevant to the current discussion, as we will probably stick with the current config system and its parser. Rainer From david at lang.hm Thu Jul 15 10:37:49 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:37:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > While I think we alread settle fort he other alternative, there is one point > I'D like to take (as it may be important for future discussions): > >>> One thing though, that is on my feature list is that I would like to >> use a >>> more standard parser, that means one that can becreated with lex and >> Bison. >>> While the hand-crafted parser is fine, it always is more work to >> extend and >>> enhance it. As the parser is no critical component, I'd prefer to use >> the >>> simpler approach. However, I need to check if I can find a suitable >> grammar >>> for this proposal. This also works on the assumption. >> >> I don't see this as a problem. It's work to define a parser, but I >> don't >> think that the current grammer is significantly harder to put into a >> lex/bison parser than any other (the exception being the implicit >> scoping >> rules) > > A problem from the grammer PoV is that a traditional action line has no > structure at all. It is anything from the first non-whitespace after the > filter to the end of line. So here we need LF as a delimiter, while in all > other cases, NL should be consider as whitespace and be discarded. interesting, I'm not sure that anyone else realized that a config option could be split over multiple lines. I'd lay good odds that you could say that NL/LF is the end of a configuration option in an upgrade without anyone noticing the change. > You really > can't specify this with a decent contextfree grammar, but Flex's substates > most probably provide sufficient power to cover these "two languages in one" > approach. > > But as I said ... this seem no longer be relevant to the current discussion, > as we will probably stick with the current config system and its parser. In the long run it's probably a useful thing to switch from the current parser to a lex/bison based parser. it makes it easier to be sure that you are sticking with the defined config language, and should make it easier to add new options, but it's not a requrement. David Lang From mrdemeanour at jackpot.uk.net Thu Jul 15 11:13:15 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Thu, 15 Jul 2010 10:13:15 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: <4C3ED12B.4080704@jackpot.uk.net> david at lang.hm wrote: > > interesting, I'm not sure that anyone else realized that a config > option could be split over multiple lines. I've banged my head on this (end-of-line comments). I believe the comments problem has been worked around now, but I still make sure that I don't try to use end-of-line comments anywhere in my configs, just in case. -- Jack. From joel.merrick at gmail.com Thu Jul 15 13:18:59 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 15 Jul 2010 12:18:59 +0100 Subject: [rsyslog] MySQL custom filters? Message-ID: Hi list, I'm trying to build a service to enable the quick searching of mail logs, for our support team to use. We get quite a lot of log generation (about 2G of mysql data a day) Searching these becomes really inefficient after a while, even though there's extra keys and indexes in the db. I'd like to try and parse the syslog event using rsyslog and get the message ID out of the payload and add it as an indexed field, which should speed up queries (so we can stitch together a full email transaction) Is this something rsyslog can do? I'm currently using the default db schema and loganalyzer 3.0.1 If not, no big deal, will have to write a custom parser and use a pipe to take the syslogs from rsyslog (perhaps?) I've also thought of multiplexing the logs to ramdisk and physical disk, although that throws up another set of problems. Cheers Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 07:43:31 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 22:43:31 -0700 (PDT) Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Thu, 15 Jul 2010, Joel Merrick wrote: > Hi list, > > I'm trying to build a service to enable the quick searching of mail > logs, for our support team to use. We get quite a lot of log > generation (about 2G of mysql data a day) > > Searching these becomes really inefficient after a while, even though > there's extra keys and indexes in the db. > > I'd like to try and parse the syslog event using rsyslog and get the > message ID out of the payload and add it as an indexed field, which > should speed up queries (so we can stitch together a full email > transaction) this shouldn't be _too_ hard, depending on where the message ID is in the messages you are logging just create your own template that writes the message ID as a separate field. David Lang > Is this something rsyslog can do? I'm currently using the default db > schema and loganalyzer 3.0.1 > > If not, no big deal, will have to write a custom parser and use a pipe > to take the syslogs from rsyslog (perhaps?) > > I've also thought of multiplexing the logs to ramdisk and physical > disk, although that throws up another set of problems. > > Cheers > Joel > > From rgerhards at hq.adiscon.com Fri Jul 16 08:53:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 08:53:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Thursday, July 15, 2010 11:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > david at lang.hm wrote: > > > > interesting, I'm not sure that anyone else realized that a config > > option could be split over multiple lines. > > I've banged my head on this (end-of-line comments). I believe the > comments problem has been worked around now, but I still make sure that > I don't try to use end-of-line comments anywhere in my configs, just in > case. That's an (one?) anomaly of the current parser. Thinking that it would be replaced in the medium to long term, I did not care about it. Looks like I now need to have a look ;) Rainer From rgerhards at hq.adiscon.com Fri Jul 16 09:11:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 09:11:20 +0200 Subject: [rsyslog] MySQL custom filters? References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB8@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 16, 2010 7:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] MySQL custom filters? > > On Thu, 15 Jul 2010, Joel Merrick wrote: > > > Hi list, > > > > I'm trying to build a service to enable the quick searching of mail > > logs, for our support team to use. We get quite a lot of log > > generation (about 2G of mysql data a day) > > > > Searching these becomes really inefficient after a while, even though > > there's extra keys and indexes in the db. > > > > I'd like to try and parse the syslog event using rsyslog and get the > > message ID out of the payload and add it as an indexed field, which > > should speed up queries (so we can stitch together a full email > > transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in > the > messages you are logging > > just create your own template that writes the message ID as a separate > field. If that's fast enough, you probably use regular expressions inside templates. Depending on the message content, you can possibly use field-based extraction (which is faster). If all that is too slow, you can write (or have written) a custom message formatter, where you have full control and power over what is done. So in short: ample of possibilities. :) Rainer From timo.bumke at bayerhealthcare.com Fri Jul 16 09:24:35 2010 From: timo.bumke at bayerhealthcare.com (timo.bumke at bayerhealthcare.com) Date: Fri, 16 Jul 2010 09:24:35 +0200 Subject: [rsyslog] Omoracle ORA-01461 Message-ID: Hello list, anybody using omoracle successfully and can help me with my problem? I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: create table test (hostname varchar2(100), message varchar2(4000)); I found out that if I am only writing one syslog property to oracle it succeeds. My failing configuration: $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt Freundliche Gr??e / Best regards Timo Bumke _________________________________________ B&R Unternehmensberatungs- und Vertriebsgesellschaft mbH Amsterdamer Str.230 50735 K?ln, Deutschland Vertragspartner der Bayer Schering Pharma AG Im Auftrag der Bayer Schering Pharma AG Geb?ude A001, EG, Raum 012 59192 Bergkamen, Deutschland Phone: +49 2307 65-3803 Email: timo.bumke at bayerhealthcare.com Web: http://www.bayerscheringpharma.de From mrdemeanour at jackpot.uk.net Fri Jul 16 11:32:34 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Fri, 16 Jul 2010 10:32:34 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> Message-ID: <4C402732.5030806@jackpot.uk.net> Rainer Gerhards wrote: >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> david at lang.hm wrote: >>> interesting, I'm not sure that anyone else realized that a config >>> option could be split over multiple lines. >> I've banged my head on this (end-of-line comments). I believe the >> comments problem has been worked around now, but I still make sure >> that I don't try to use end-of-line comments anywhere in my >> configs, just in case. > > That's an (one?) anomaly of the current parser. Thinking that it > would be replaced in the medium to long term, I did not care about > it. Looks like I now need to have a look ;) No big deal for me *now*, but it caused pain when I first ran into it. Anyway, I thought you'd addressed this - about a year ago, maybe? -- Jack. From rgerhards at hq.adiscon.com Fri Jul 16 11:50:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 11:50:16 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Friday, July 16, 2010 11:33 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Rainer Gerhards wrote: > >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> david at lang.hm wrote: > >>> interesting, I'm not sure that anyone else realized that a config > >>> option could be split over multiple lines. > >> I've banged my head on this (end-of-line comments). I believe the > >> comments problem has been worked around now, but I still make sure > >> that I don't try to use end-of-line comments anywhere in my > >> configs, just in case. > > > > That's an (one?) anomaly of the current parser. Thinking that it > > would be replaced in the medium to long term, I did not care about > > it. Looks like I now need to have a look ;) > > No big deal for me *now*, but it caused pain when I first ran into it. > Anyway, I thought you'd addressed this - about a year ago, maybe? I guess just mostly -- at least it boils down with actions themselves, where it is hard to handle due to the missing well-defined structure of the string. Rainer From joel.merrick at gmail.com Fri Jul 16 12:08:15 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Fri, 16 Jul 2010 11:08:15 +0100 Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Fri, Jul 16, 2010 at 6:43 AM, wrote: > On Thu, 15 Jul 2010, Joel Merrick wrote: > >> Hi list, >> >> I'm trying to build a service to enable the quick searching of mail >> logs, for our support team to use. We get quite a lot of log >> generation (about 2G of mysql data a day) >> >> Searching these becomes really inefficient after a while, even though >> there's extra keys and indexes in the db. >> >> I'd like to try and parse the syslog event using rsyslog and get the >> message ID out of the payload and add it as an indexed field, which >> should speed up queries (so we can stitch together a full email >> transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in the > messages you are logging > > just create your own template that writes the message ID as a separate > field. > The position of the message ID's are always pretty consistent but not exactly. I've got a PoC ruby daemon listening on a named pipe and regex'ing out the message ID's already. Shawn's very kindly told me about Solr, so I'm going to give that a whirl today. If I could get away from using the ruby daemon and use rsyslog properly, that'd be good.. however it's working and can easily handle the load The regexp in ruby I'm using is; \w{6}-\w{6}-\w{2} Could this be done for the templates? -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 19:57:18 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 16 Jul 2010 10:57:18 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang From rgerhards at hq.adiscon.com Fri Jul 16 20:08:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 20:08:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format Message-ID: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> In theorie yes, in practice eg inside a password for a db connection. ----- Urspr?ngliche Nachricht ----- Von: david at lang.hm Gesendet: Freitag, 16. Juli 2010 19:57 An: rsyslog-users Betreff: Re: [rsyslog] NEW rsyslog.conf format On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From david at lang.hm Sun Jul 18 00:45:46 2010 From: david at lang.hm (david at lang.hm) Date: Sat, 17 Jul 2010 15:45:46 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: > In theorie yes, in practice eg inside a password for a db connection. how hard would it be to allow quotes around the password? (if this ends up disallowing quotes in the password to the database, that's not too bad a cost) I'm trying to think of if there are some fairly minor changes that could be made that would make it significantly easier for a better parser to be written. changng the config is always a problem, but there are some problems that are much larger than others, and if a minor change would make it much easier to move to a standard parser it may be worth making the breakage in a 5.x or 6.x release (where the new capibilities are introduced so that people can see the advantage of the breakage) David Lang > ----- Urspr?ngliche Nachricht ----- > Von: david at lang.hm > Gesendet: Freitag, 16. Juli 2010 19:57 > An: rsyslog-users > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >>> Sent: Friday, July 16, 2010 11:33 AM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> Rainer Gerhards wrote: >>>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>>> >>>>> david at lang.hm wrote: >>>>>> interesting, I'm not sure that anyone else realized that a config >>>>>> option could be split over multiple lines. >>>>> I've banged my head on this (end-of-line comments). I believe the >>>>> comments problem has been worked around now, but I still make sure >>>>> that I don't try to use end-of-line comments anywhere in my >>>>> configs, just in case. >>>> >>>> That's an (one?) anomaly of the current parser. Thinking that it >>>> would be replaced in the medium to long term, I did not care about >>>> it. Looks like I now need to have a look ;) >>> >>> No big deal for me *now*, but it caused pain when I first ran into it. >>> Anyway, I thought you'd addressed this - about a year ago, maybe? >> >> I guess just mostly -- at least it boils down with actions themselves, where >> it is hard to handle due to the missing well-defined structure of the string. > > is a # outside of quotes ever valid in an action string? > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Jul 19 08:27:52 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 19 Jul 2010 08:27:52 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Sunday, July 18, 2010 12:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > In theorie yes, in practice eg inside a password for a db connection. > > how hard would it be to allow quotes around the password? (if this ends > up > disallowing quotes in the password to the database, that's not too bad > a > cost) > > I'm trying to think of if there are some fairly minor changes that > could > be made that would make it significantly easier for a better parser to > be > written. The real problem is the interface spec: whenever I change the syntax, I also (need to) change the interface spec. That is because the current spec says that everything from first non-whitespace after the filter up to LF needs to be passed to the output module. That's it... So even a minor change invalidates that interface. Given the fact that I know about at least three externally written plugins (which means probably more), I am hesitant to break that part of the spec, at least if I can avoid it. > changng the config is always a problem, but there are some problems > that > are much larger than others, and if a minor change would make it much > easier to move to a standard parser it may be worth making the breakage I agree, but only if unavoidable. As it currently looks, I think I will probably be able to generate a (decently complex) flex/bison parser that processes old and new-style (whatever it be) format. However, moving to flex/bison is considerable work, even if it were crystal-clear what we intend to do. So it sounds very appealing to me to stay within the constraints of the current parser and implement scoping with its help. That is still a lot of work, but much, much less than a full overhaul. Most importantly, it enables us to experimentally extend the config language, see how that works out in practice and *then* decide if we should really pursue that route. If so, we can than look at what exactly it takes to create a new parser subsystem. Of course, while extending the current system, we must keep an eye on potential "flex/bison grammars" and try not to introduce anything new that causes new problems. With the current proposal, I do not see any such problems. This gradual approach has the vast advantage that we get scoping into rsyslog at a far earlier time than when we did the full "right thing". However, the plugin interface will still be broken (I need the push/pop config ability plus config statement type designators), but at a far easier to fix level (from a plugin developer's PoV). > in > a 5.x or 6.x So doing this in a 6.x version sounds like a good thing, as it makes crystal-clear that some important things have changed. So I think you proposal is a very good one ;) Rainer > release (where the new capibilities are introduced so that > people can see the advantage of the breakage) > > David Lang > > > ----- Urspr?ngliche Nachricht ----- > > Von: david at lang.hm > > Gesendet: Freitag, 16. Juli 2010 19:57 > > An: rsyslog-users > > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > >>> Sent: Friday, July 16, 2010 11:33 AM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> Rainer Gerhards wrote: > >>>>> -----Original Message----- From: rsyslog- > bounces at lists.adiscon.com > >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog- > users > >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>>>> > >>>>> david at lang.hm wrote: > >>>>>> interesting, I'm not sure that anyone else realized that a > config > >>>>>> option could be split over multiple lines. > >>>>> I've banged my head on this (end-of-line comments). I believe the > >>>>> comments problem has been worked around now, but I still make > sure > >>>>> that I don't try to use end-of-line comments anywhere in my > >>>>> configs, just in case. > >>>> > >>>> That's an (one?) anomaly of the current parser. Thinking that it > >>>> would be replaced in the medium to long term, I did not care about > >>>> it. Looks like I now need to have a look ;) > >>> > >>> No big deal for me *now*, but it caused pain when I first ran into > it. > >>> Anyway, I thought you'd addressed this - about a year ago, maybe? > >> > >> I guess just mostly -- at least it boils down with actions > themselves, where > >> it is hard to handle due to the missing well-defined structure of > the string. > > > > is a # outside of quotes ever valid in an action string? > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Mon Jul 19 22:33:18 2010 From: sean at conman.org (Sean Conner) Date: Mon, 19 Jul 2010 16:33:18 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> Message-ID: <20100719203318.GB17467@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > If so, we can than look at what exactly it takes to create a new parser > subsystem. Of course, while extending the current system, we must keep an eye > on potential "flex/bison grammars" and try not to introduce anything new that > causes new problems. With the current proposal, I do not see any such > problems. The current parser obviously creates some internal structures used by the engine to run. Is this fully documented? If so, what's to keep someone from replacing the current parser with a completely different one that builds the same internal structures? Could you not have different configuration parsers? (issue: how to know which one to use; command line option perhaps? the first line describing which parsing module to use (and if missing, use the original one)?) Such a method might be beneficial to explore alternative configuration files. -spc (Just an idea ... ) From david at lang.hm Mon Jul 19 23:20:49 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Jul 2010 14:20:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100719203318.GB17467@brevard.conman.org> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> <20100719203318.GB17467@brevard.conman.org> Message-ID: On Mon, 19 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> If so, we can than look at what exactly it takes to create a new parser >> subsystem. Of course, while extending the current system, we must keep an eye >> on potential "flex/bison grammars" and try not to introduce anything new that >> causes new problems. With the current proposal, I do not see any such >> problems. > > The current parser obviously creates some internal structures used by the > engine to run. This is an incorrect assumption. the current parser creates some internal structures, but it also executes things immediatly > Is this fully documented? No, it's not fully documented because it's currently up to the individual module to do whatever it wants to do when it sees a config option. It can _do_ something, or it can create a variable that nothing else knows about, or it can change an existing variable. I initially made the same assumption, but Rainer has clarified this in these threads. David Lang > If so, what's to keep someone > from replacing the current parser with a completely different one that > builds the same internal structures? Could you not have different > configuration parsers? (issue: how to know which one to use; command line > option perhaps? the first line describing which parsing module to use (and > if missing, use the original one)?) Such a method might be beneficial to > explore alternative configuration files. > > -spc (Just an idea ... ) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From akozumpl at redhat.com Tue Jul 20 10:55:18 2010 From: akozumpl at redhat.com (Ales Kozumplik) Date: Tue, 20 Jul 2010 10:55:18 +0200 Subject: [rsyslog] log forwarding through unix sockets Message-ID: <4C456476.4010703@redhat.com> Hi list, I am using rsyslog to forward logs between KVM guest and host machines during the Fedora installation program (aka Anaconda). Details are described here: https://fedoraproject.org/wiki/Anaconda/Logging#Remote_logging_via_virtio, but in the gist: recent QEMU/KVM has a feature using which one can write to a character device on the guest end and read those data from a unix socket on the host end. We are tying to use this facility to forward the installation logs to the host. Two rsyslogd instances are involved in the process: the sending one on the guest end and the receiving one on the host end (which parses the incoming messages' headers and files the messages into different files). Unfortunately I've run into a couple of issues trying to set up the forwarding using this mechanism: 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to read data from SOCK_DGRAM. This has two consequences: first, to be able to attach rsyslog on the host end one first needs to copy the data between the two socket types, e.g. using socat. Second, messages longer than 1024 characters are sometimes split into two. The second message is thus missing the syslog header and the receiving rsyslogd doesn't know where to file it. Is there a recommended workaround for those things (maybe a parameter I overlooked in the docs tellling rsyslogd to use SOCK_STREAM)? 2) I seem to be unable to get the forwarding template right. For network forwarding (which is also supported in Anaconda), simply putting no explicit formatting does the trick: *.* @@ some.host The received logs can be matched for anything: severity, facility, hostname and programname. This is not the case when logs are forwarded through the character device: *.* /dev/virtio_ports/port_name Using the implicit formatting the receiving syslog won't parse the programname. I tried using the predefined ForwardFormat but then the receiving rsyslogd parsed hostname as the programname and the programname remains part of the final message. Is that the expected behavior? What worked for me in the end was creating a template based on the ForwardFormat but with the %HOSTNAME% part omitted: I can live with that for know since I know the message came from a certain socket so it can be only one host. Still: it seems weird there's no forwarding format provided that would retain 100% of the information parsable by another rsyslog reading from a socket. I'm probably just missing something? Thanks for any reply about this. Ales Kozumplik From rgerhards at hq.adiscon.com Tue Jul 20 15:40:17 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Jul 2010 15:40:17 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 19, 2010 11:21 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Mon, 19 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great Rainer Gerhards once stated: > >> > >> If so, we can than look at what exactly it takes to create a new > parser > >> subsystem. Of course, while extending the current system, we must > keep an eye > >> on potential "flex/bison grammars" and try not to introduce anything > new that > >> causes new problems. With the current proposal, I do not see any > such > >> problems. > > > > The current parser obviously creates some internal structures used > by the > > engine to run. > > This is an incorrect assumption. the current parser creates some > internal > structures, but it also executes things immediatly > > > Is this fully documented? > > No, it's not fully documented because it's currently up to the > individual > module to do whatever it wants to do when it sees a config option. It > can > _do_ something, or it can create a variable that nothing else knows > about, > or it can change an existing variable. > > I initially made the same assumption, but Rainer has clarified this in > these threads. David is absolutely right in his posting. But let me add some more explanation. Rsyslog's config parser was never "designed". We inherited it from sysklogd and it probably is one of the last remaining parts that actually have sysklogd heritage at all. It is not even a real parser, at least if you make some usual assumptions of what a language parser does. This all is part of the problem, and this also is the reason why it is considerable effort to change the way the config system operates. I'd really love to have what Sean assumes we have. This would be a big step into the right direction. But even if we had it, I don't think that would change the discussion. Even though loadable parsers could then be easily added, I doubt someone except me will ever write on. Look at the situation of message parsers and such -- while it is fairly simple to create one, most people are hesitant to do it (for output plugins it is even more simple, and there we see third parties!). A parser is not trivial, so I don't expect to see someone actually write one (vs. claim he would write one if the interface were there). I, on the other hand, have no motivation at all to write multiple parsers - just duplicated (aka wasted) effort. So the discussion about which parsers is the first (and thus potentially only) one is very vital. Just for the records: the current route probably is to stay with the current config system, introduce scoping and *then* think about how the system could be modified. Rainer From tbergfeld at hq.adiscon.com Wed Jul 21 15:06:02 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 21 Jul 2010 15:06:02 +0200 Subject: [rsyslog] rsyslog 5.5.6 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.6, a member of the devel branch. The new release provides exciting performance enhancements: on multicore-machines it can be many times faster than version 5.5.5 (which already was quite fast). Most importantly, the enhancement provides much better scalability, so adding many additional core gains much more speedup than with any previous version. A new concept of "strgen" modules has been implemented, which permit to use high speed C code as templates. Also, support for malformed "last message repated n times" messages, as emited by some syslogds, has been added in form of a custom message parser. There are also a couple of bugfixes and minor improvements. See ChangeLog for more details. ChangeLog: http://www.rsyslog.com/changelog-for-5-5-6-devel/ Download: http://www.rsyslog.com/rsyslog-5-5-6-devel As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From friedl at hq.adiscon.com Wed Jul 21 15:55:26 2010 From: friedl at hq.adiscon.com (Florian Riedl) Date: Wed, 21 Jul 2010 15:55:26 +0200 Subject: [rsyslog] New rsyslog website is live! Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Dear rsyslog folks, The Adiscon GmbH is proud to announce that today we have made the new rsyslog website live. If you find something missing or not working correctly, please let us know. Further, we are open to suggestions to make the new website even better. We will do some last finishing touches to it currently as well, therefore sometimes some things might not work correctly. Since we did not drag over the complete old content like old news releases, you can still get find it at http://old.rsyslog.com. We hope you have a good experience with the new website. Best regards, Florian Riedl Adiscon -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From lists at luigirosa.com Thu Jul 22 05:53:38 2010 From: lists at luigirosa.com (Luigi Rosa) Date: Thu, 22 Jul 2010 05:53:38 +0200 Subject: [rsyslog] New rsyslog website is live! In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Message-ID: <4C47C0C2.5010806@luigirosa.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Riedl said the following on 21/07/10 15:55: > If you find something missing or not working correctly, please let us know. The style of both Google ad does not display well on Firefox+Ubuntu The right coloumn of ad is too big, the row below the three boxes overlaps the other elements. http://luigirosa.com/rsyslog.png Ciao, luigi - -- / +--[Luigi Rosa]-- \ There is a greater darkness than the one we fight. It is the darkness of the soul that has lost its way. The war we fight is not against powers and principalities, it is against chaos and despair. Greater than the death of flesh is the death of hope, the death of dreams. Against this peril we can never surrender. The future is all around us, waiting, in moments of transition, to be born in moments of revelation. No one knows the shape of that future or where it will take us. We know only that it is always born in pain. --G'Kar, "Z'ha'dum" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHwL8ACgkQ3kWu7Tfl6ZSi1QCfUkQXhzdCRzcdu81gEp43bqCg N7oAnipWupEp16ILTl4omY5jdu9bncG+ =ELlp -----END PGP SIGNATURE----- From rgerhards at hq.adiscon.com Fri Jul 23 17:43:09 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Jul 2010 17:43:09 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FED@GRFEXC.intern.adiscon.com> For those interested: I have begun to implement action scoping. A snapshot with partial functionality is available at http://git.adiscon.com/?p=rsyslog.git;a=shortlog;h=refs/heads/newconf It does NOT yet include the necessary output plugin interface change (or updated plugins), but it implements $Begin action $End action $StrictScoping [on/off] -- off default So if you want to play a bit with it, feel free to do so. Note that it disallows global statements within action scope and in overall has somewhat better detection of user errors (these are easier to detect when scoping is used). Note that scoping is purely optional: if not enabled, it will not be used. So any current rsyslog.conf remains valid. I will see that I change the projects's output plugins next week, and will possibly then make an experimental release. I just thought I let all of you know. Rainer From david at lang.hm Sat Jul 24 06:57:26 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 23 Jul 2010 21:57:26 -0700 (PDT) Subject: [rsyslog] mark messages Message-ID: I have a server sending me bad data, so I implmented the following rule to trap log messaages where the hostname isn't an IP address or name :hostname, regex, "[a-zA-Z\.]" /file & ~ *.* /file2;fixformat unfortunantly it turns out that this also traps mark messages. the %rawmsg% for mark is just "-- MARK --" and apparently hostname is not populated (fromhost-ip is 127.0.0.1) I do have -x on the rsyslog command line, so it is not doing DNS resolution, but it should come up with either the local hostname or 127.0.0.1 as the hostname for locally generated messages. Either one of these would match my regex as being a 'normal' message This box is currently running 5.5.3 David Lang From rgerhards at hq.adiscon.com Mon Jul 26 14:18:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 14:18:20 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Hi David, I have just checked immark, it uses a function to log internal messages (that alone is questionable, but stems back to its history). However, this function should properly populate hostname, so it looks like something else is broken. Will check and keep you updated. Thanks for the info, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Jul 26 15:18:44 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:18:44 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF9@GRFEXC.intern.adiscon.com> David, I now checked > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% This is a special case where %rawmsg% does not contain everything. Internal messages generate the necessary in-memory structure, but do not try to emulate %rawmsg% in all its glory (but it may be worth thinking about that). HOWEVER, fromhost and fromhost-ip are properly populated. So the filter should work, assuming that the hostname actually matches the regex. I suggest that you use the canned RSYSLOG_DebugFormat template so that we can see what exactly is stored in your in-memory message representation. Rainer > for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:18:02 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:18:02 +0200 Subject: [rsyslog] Rsyslog Version Comparison Message-ID: <4C4D8B0A.8090503@kinzesberg.de> Hi folks, I have searched the new site for a comparison of the major version of rsyslog (3, 4, 5), but found nothing. Only information seems to be the change logs, but I would not like to parse through several dozen documents and work on a matrix for some hours, so ... Is there an overview document relating versions and features? Any hint or help is appreciated. Dirk From rgerhards at hq.adiscon.com Mon Jul 26 15:27:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:27:31 +0200 Subject: [rsyslog] Rsyslog Version Comparison References: <4C4D8B0A.8090503@kinzesberg.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> As far as I know, there is no such comparison. But I agree this would probably be very useful. I'll ask the web folks if they have time to generate such a page (maybe not with all details, but the more important features, at least for a start). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz > Sent: Monday, July 26, 2010 3:18 PM > To: rsyslog-users > Subject: [rsyslog] Rsyslog Version Comparison > > Hi folks, > > I have searched the new site for a comparison of the major version of > rsyslog (3, 4, 5), but found nothing. Only information seems to be the > change logs, but I would not like to parse through several dozen > documents and work on a matrix for some hours, so ... > > Is there an overview document relating versions and features? > > Any hint or help is appreciated. > > Dirk > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:35:25 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:35:25 +0200 Subject: [rsyslog] Rsyslog Version Comparison In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> References: <4C4D8B0A.8090503@kinzesberg.de> <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> Message-ID: <4C4D8F1D.8000507@kinzesberg.de> thanks a lot, that would be great! dirk Am 26.07.10 15:27, schrieb Rainer Gerhards: > As far as I know, there is no such comparison. But I agree this would > probably be very useful. I'll ask the web folks if they have time to generate > such a page (maybe not with all details, but the more important features, at > least for a start). > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz >> Sent: Monday, July 26, 2010 3:18 PM >> To: rsyslog-users >> Subject: [rsyslog] Rsyslog Version Comparison >> >> Hi folks, >> >> I have searched the new site for a comparison of the major version of >> rsyslog (3, 4, 5), but found nothing. Only information seems to be the >> change logs, but I would not like to parse through several dozen >> documents and work on a matrix for some hours, so ... >> >> Is there an overview document relating versions and features? >> >> Any hint or help is appreciated. >> >> Dirk >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Mon Jul 26 20:25:40 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 26 Jul 2010 11:25:40 -0700 (PDT) Subject: [rsyslog] mark messages In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 26 Jul 2010, Rainer Gerhards wrote: > Hi David, > > I have just checked immark, it uses a function to log internal messages (that > alone is questionable, but stems back to its history). However, this function > should properly populate hostname, so it looks like something else is broken. > Will check and keep you updated. you may need to explicitly check what happens when -x is provided. David Lang > Thanks for the info, > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Saturday, July 24, 2010 6:57 AM >> To: rsyslog-users >> Subject: [rsyslog] mark messages >> >> I have a server sending me bad data, so I implmented the following rule >> to >> trap log messaages where the hostname isn't an IP address or name >> >> :hostname, regex, "[a-zA-Z\.]" /file >> & ~ >> *.* /file2;fixformat >> >> unfortunantly it turns out that this also traps mark messages. >> >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname is >> not >> populated (fromhost-ip is 127.0.0.1) >> >> I do have -x on the rsyslog command line, so it is not doing DNS >> resolution, but it should come up with either the local hostname or >> 127.0.0.1 as the hostname for locally generated messages. Either one of >> these would match my regex as being a 'normal' message >> >> This box is currently running 5.5.3 >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Jul 27 09:29:28 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Jul 2010 09:29:28 +0200 Subject: [rsyslog] mark messages References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104002@GRFEXC.intern.adiscon.com> David, have you seen my other message where I asked to check all properties? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 26, 2010 8:26 PM > To: rsyslog-users > Subject: Re: [rsyslog] mark messages > > On Mon, 26 Jul 2010, Rainer Gerhards wrote: > > > Hi David, > > > > I have just checked immark, it uses a function to log internal > messages (that > > alone is questionable, but stems back to its history). However, this > function > > should properly populate hostname, so it looks like something else is > broken. > > Will check and keep you updated. > > you may need to explicitly check what happens when -x is provided. > > David Lang > > > > Thanks for the info, > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Saturday, July 24, 2010 6:57 AM > >> To: rsyslog-users > >> Subject: [rsyslog] mark messages > >> > >> I have a server sending me bad data, so I implmented the following > rule > >> to > >> trap log messaages where the hostname isn't an IP address or name > >> > >> :hostname, regex, "[a-zA-Z\.]" /file > >> & ~ > >> *.* /file2;fixformat > >> > >> unfortunantly it turns out that this also traps mark messages. > >> > >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname > is > >> not > >> populated (fromhost-ip is 127.0.0.1) > >> > >> I do have -x on the rsyslog command line, so it is not doing DNS > >> resolution, but it should come up with either the local hostname or > >> 127.0.0.1 as the hostname for locally generated messages. Either one > of > >> these would match my regex as being a 'normal' message > >> > >> This box is currently running 5.5.3 > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Tue Jul 27 13:51:21 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Tue, 27 Jul 2010 13:51:21 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors Message-ID: I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. I'm trying to use the rsyslog to send syslog messages to an existing oracle db. I'm facing these problems, and don't really know where to begin. I've setup the correct oracle environment during startup of the rsyslog and it got me errors seen below. I have done the same trying to build the rsyslog using "./configure --enable-oracle", then "make", "make install" with the oracle environment setup, but got same errors seen below. Can anyone help me solve this? errors while building rsyslog's plugin omoracle: make[2]: Entering directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' CC omoracle_la-omoracle.lo omoracle.c: In function ?prepare_statement?: omoracle.c:254: warning: pointer targets in passing argument 3 of ?OCIStmtPrepare? differ in signedness omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from incompatible pointer type omoracle.c: In function ?createInstance?: omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? differ in signedness omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? differ in signedness omoracle.c: In function ?log_detailed_err?: omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from incompatible pointer type omoracle.c: In function ?tryResume?: omoracle.c:461: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?startSession?: omoracle.c:481: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?parseSelectorAct?: omoracle.c:517: warning: implicit declaration of function ?cflineParseTemplateName? CCLD omoracle.la make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' Making all in tests syslog entries when starting rsyslog daemon: 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = /proc/kmsg started. 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: TNS:could not resolve the connect identifier specified 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle session 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line without actions will be discarded 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2124 ] Debug statements checking rsyslog's configuration: 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' 1494.718302000:2abb22fc5ac0: loading module '/usr/local/lib/rsyslog/omoracle.so' 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry -- Best regards! Damien From mrdemeanour at jackpot.uk.net Tue Jul 27 14:30:08 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 27 Jul 2010 13:30:08 +0100 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: References: Message-ID: <4C4ED150.4070603@jackpot.uk.net> Damjan ?iberna wrote: > I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 > and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. > I'm trying to use the rsyslog to send syslog messages to an existing oracle > db. I'm facing these problems, and don't really know where to begin. I've > setup the correct oracle environment during startup of the rsyslog and it > got me errors seen below. I have done the same trying to build the rsyslog > using "./configure --enable-oracle", then "make", "make install" with the > oracle environment setup, but got same errors seen below. > > Can anyone help me solve this? I'm very much not up-to-date on Oracle, and I've never used instantclient. I've never tried to use rsyslog with Oracle either. Inline remarks [below] may therefore be wide of the mark. However it looks to me that you have a problem with your Oracle connect string; a problem with your rsyslog config; and a problem with your ORACLE_HOME. > > > errors while building rsyslog's plugin omoracle: > > make[2]: Entering directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > CC omoracle_la-omoracle.lo > omoracle.c: In function ?prepare_statement?: > omoracle.c:254: warning: pointer targets in passing argument 3 of > ?OCIStmtPrepare? differ in signedness > omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from > incompatible pointer type > omoracle.c: In function ?createInstance?: > omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? > differ in signedness > omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? > differ in signedness > omoracle.c: In function ?log_detailed_err?: > omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from > incompatible pointer type > omoracle.c: In function ?tryResume?: > omoracle.c:461: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?startSession?: > omoracle.c:481: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?parseSelectorAct?: > omoracle.c:517: warning: implicit declaration of function > ?cflineParseTemplateName? > CCLD omoracle.la > make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > Making all in tests Those all look like warnings, not errors. Did the module get built? > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = > /proc/kmsg started. > 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" > swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: > TNS:could not resolve the connect identifier specified http://ora-12154.ora-code.com/ Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached. > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > session > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > without actions will be discarded Defective rsyslog.conf. > 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could > not interpret master config file '/etc/rsyslog.conf'. [try > http://www.rsyslog.com/e/2124 ] > > > Debug statements checking rsyslog's configuration: > > 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' > 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' > 1494.718302000:2abb22fc5ac0: loading module > '/usr/local/lib/rsyslog/omoracle.so' > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html The poster says: tora: symbol lookup error: /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: nltrc_entry [...] When I switch ORACLE_HOME to point to a full install of Oracle 10g, the problem goes away, and TOra launches normally. HTH, -- MrD. From damjanster at gmail.com Wed Jul 28 10:10:22 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 10:10:22 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: <4C4ED150.4070603@jackpot.uk.net> References: <4C4ED150.4070603@jackpot.uk.net> Message-ID: > > However it looks to me that you have a problem with your Oracle connect > string; a problem with your rsyslog config; and a problem with your > ORACLE_HOME. > The ORACLE_HOME, TNS_ADMIN, LD_LIBRARY_PATH variables get set just before the rsyslogd is run. ORACLE_HOME is set to the production installation of our database - not to instantclinet's home. > > > > > > errors while building rsyslog's plugin omoracle: > > > CCLD omoracle.la > > make[2]: Leaving directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > > Making all in tests > > Those all look like warnings, not errors. Did the module get built? > The module got built and installed. It's just not loading. > > > > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: > ORA-12154: > > TNS:could not resolve the connect identifier specified > > http://ora-12154.ora-code.com/ > This error is interesting in its own, but since the omoracle plugin doesn't get loaded the $Om... parameters get ignored - as I can see from the debug output running rsyslog. > > > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > > session > > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured > in > > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > > without actions will be discarded > > Defective rsyslog.conf. > Not 100% sure, but I believe this is due to omoracle not loading. > > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry > > > http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html > > The poster says: > tora: symbol lookup error: > /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: > nltrc_entry > [...] > When I switch ORACLE_HOME to point to a full install of Oracle 10g, > the problem goes away, and TOra launches normally. > An interesting point. As I've mentioned before, these variables are set like this: export LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.4/client64/lib export PATH=/ust/lib/oracle/10.2.0.4/client64:/usr/local/bin:$PATH export TNS_ADMIN=/usr/lib/oracle/10.2.0.4/client64 export ORAENV_ASK=NO export ORACLE_SID=dbase . oraenv unset ORAENV_ASK ORACLE_HOME gets set via oraenv to the production database path - not instantclient's. The database in question is verison 11.2G, but this should not be a problem. Any help is much apprechiated. From damjanster at gmail.com Wed Jul 28 15:35:51 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 15:35:51 +0200 Subject: [rsyslog] OmoracleStatement format Message-ID: I'm trying to get as much valuable info into our oracledb as possible for further analysis. This is what I came up with so far: $template OmoracleStatement,"INSERT INTO SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message)" $template TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost-ip%%syslogfacility%%syslogseverity%%msg%" *.* :omoracle:;TestStmt These statements don't really work well: 1. timestamp ~ timereported - there's no reference on the web site about how different options format the output. I'd love to have the full-form date&time format, but without the letter "T" in the middle, since Oracle doesn't know how to handle it. The above values string is a workaround, but I'm afraid it's too slow to process great amounts of entries. 2. hostname doesn't get written - I only get 127.0.0.1 3. hostip - only gets written when messages arrive from localhost: 127.0.0.1 4. facility - gets written correctly 5. severity - the %msg% value gets written into this column 6. message - always empty I'm trying to centralize syslog from all surrounding servers. Only the central server uses rsyslog, all the rest use the plain syslog daemon. Should I replace syslog with rsyslog on the surrounding servers to get this to work? Is there some place to get some better reference for the rsyslog strings and it's results? Is it possible to log the exact values that omoracle tries to commit to the database? -- Best regards! Damien From rgerhards at hq.adiscon.com Wed Jul 28 15:42:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 28 Jul 2010 15:42:22 +0200 Subject: [rsyslog] OmoracleStatement format References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> I have no idea on omoracle, but I can comment on the "normal" rsyslog stuff... > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Wednesday, July 28, 2010 3:36 PM > To: rsyslog-users > Subject: [rsyslog] OmoracleStatement format > > I'm trying to get as much valuable info into our oracledb as possible > for > further analysis. This is what I came up with so far: > > > $template OmoracleStatement,"INSERT INTO > SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES > (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY- > MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message) > " > $template > TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost- > ip%%syslogfacility%%syslogseverity%%msg%" > *.* :omoracle:;TestStmt > > These statements don't really work well: > 1. timestamp ~ timereported - there's no reference on the web site > about how > different options format the output. I'd love to have the full-form > date&time format, but without the letter "T" in the middle, since > Oracle > doesn't know how to handle it. The above values string is a workaround, > but > I'm afraid it's too slow to process great amounts of entries. I think it would be best to split the RFC3339 date via the property replacer (using start and end position) and then feed this to omoracle. The full doc on property replacer is here: http://www.rsyslog.com/doc/property_replacer.html > > 2. hostname doesn't get written - I only get 127.0.0.1 It would be useful to write a quick debug file *.* /var/log/debug.log;RSYSLOG_DebugFormat This shows what exactly is stored in which property and can probably used to solve the question what exactly happens. > > 3. hostip - only gets written when messages arrive from localhost: > 127.0.0.1 > > 4. facility - gets written correctly > > 5. severity - the %msg% value gets written into this column > > 6. message - always empty see 2. > I'm trying to centralize syslog from all surrounding servers. Only the > central server uses rsyslog, all the rest use the plain syslog daemon. > Should I replace syslog with rsyslog on the surrounding servers to get > this > to work? That's probably not necessary, but let's see the result of 2. > Is there some place to get some better reference for the rsyslog > strings and > it's results? see link above > > Is it possible to log the exact values that omoracle tries to commit to > the > database? you can write to a file with the same template you use for omoracle. But 2. should be sufficient. Rainer > > > -- > Best regards! > Damien > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Thu Jul 29 03:43:40 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Wed, 28 Jul 2010 21:43:40 -0400 Subject: [rsyslog] How to write to a local socket? Message-ID: I just configured a privilege-separated RSyslog instance, and it's running fine. To read the kernel message log, I'm running a second daemon instance as root, along the lines described in the wiki. Currently, my root instance forwards messages via UDP to unprivileged instance's localhost-only listener. It works, but I'm not entirely happy with it. I'd like to forward via a local UNIX domain socket, instead. I think I understand how to configure the 'imuxsock' module so my unprivileged instance reads from a non-standard socket location. But I can't figure out how to tell my root instance to forward via a local domain socket. Is this possible? If so, how? Ryan B. Lynch ryan.b.lynch at gmail.com From sledz at dresearch.de Thu Jul 29 09:17:00 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 09:17:00 +0200 Subject: [rsyslog] Buggy pipe behaviour Message-ID: <4C512AEC.9070301@dresearch.de> We need to configure a pipe to connect the output to a special application. Our configuration looks like this: ----->snip<-------- $ModLoad imuxsock $ModLoad imklog $ModLoad immark $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $RepeatedMsgReduction on *.* |/var/run/syslog2thinfs ... some other channels ----->snap<-------- The fifo is created and has sufficient rights. Now we can see the following behaviour: No receiver connected to the pipe, rsyslog writes messages into it Receiver is connected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (just a few) Receiver is reconnected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (more than the pipe capacity?) Receiver is reconnected, *some queued messages* are read (but only up to the pipe capacity?) After this *no more messages* reach the end of the pipe. Disconnect/reconnect the receiver makes no difference. -> bad :( I believe this is a bug. May be some messages get lost because there is no place for intermediate storage. But after reconnecting the receiver new messages should pass the pipe again. Right? We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour using the following shell snippets. Sender: ----->snip<-------- i=0;while true; do logger -t count $i; i=$(($i+1)); done ----->snap<-------- Receiver: ----->snip<-------- while true; do cat /var/run/syslog2thinfs ; done ----->snap<-------- Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 10:46:18 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 10:46:18 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> This sounds like intended behavior. When an action fails (pipe fails when nobody reads and it is tried to write to it), rsyslog retries the configured number of times and then suspends the action for the configured period (at least I think it is configurable, you need to look up the details). Only after this period the action is retried. If it fails again, it is re-suspended, but this time with a longer suspension period. This is done so that rsyslog does not spent a lot of time on actions known to be failing. >From what you wrote, I think your use case would probably better be served by omprog, but I may be wrong. If you think about this route, you need to know that someone requested the functionality, but was never seen when it was done ;) So the module is only barely tested. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 9:17 AM > To: rsyslog ML > Subject: [rsyslog] Buggy pipe behaviour > > We need to configure a pipe to connect the output to a special > application. Our configuration looks like this: > > ----->snip<-------- > $ModLoad imuxsock > $ModLoad imklog > $ModLoad immark > > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat > > $RepeatedMsgReduction on > > *.* |/var/run/syslog2thinfs > > ... some other channels > ----->snap<-------- > > The fifo is created and has sufficient rights. > > Now we can see the following behaviour: > > No receiver connected to the pipe, rsyslog writes messages into it > > Receiver is connected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (just a few) > > Receiver is reconnected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (more than the pipe capacity?) > > Receiver is reconnected, *some queued messages* are read (but only up > to the pipe capacity?) > > After this *no more messages* reach the end of the pipe. > Disconnect/reconnect the receiver makes no difference. -> bad :( > > I believe this is a bug. May be some messages get lost because there is > no place for intermediate storage. But after reconnecting the receiver > new messages should pass the pipe again. Right? > > We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour > using the following shell snippets. > > Sender: > ----->snip<-------- > i=0;while true; do logger -t count $i; i=$(($i+1)); done > ----->snap<-------- > > Receiver: > ----->snip<-------- > while true; do cat /var/run/syslog2thinfs ; done > ----->snap<-------- > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 12:33:26 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:33:26 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> Message-ID: <4C5158F6.3060702@dresearch.de> Am 29.07.2010 10:46, schrieb Rainer Gerhards: > This sounds like intended behavior. When an action fails (pipe fails when > nobody reads and it is tried to write to it), rsyslog retries the configured > number of times and then suspends the action for the configured period (at > least I think it is configurable, you need to look up the details). Only > after this period the action is retried. If it fails again, it is > re-suspended, but this time with a longer suspension period. This is done so > that rsyslog does not spent a lot of time on actions known to be failing. So you say, if i wait long enough the messages should receive the end of the pipe? Are there some related debug printouts i can search for? Can you give some hints to the related configuration parameters (URL or keyword). Unfortunately the manual is not very helpful here. > From what you wrote, I think your use case would probably better be served by > omprog, but I may be wrong. If you think about this route, you need to know > that someone requested the functionality, but was never seen when it was done > ;) So the module is only barely tested. Same wish. Where can i read more about omprog? Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 12:43:06 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:43:06 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 12:33 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > This sounds like intended behavior. When an action fails (pipe fails > when > > nobody reads and it is tried to write to it), rsyslog retries the > configured > > number of times and then suspends the action for the configured > period (at > > least I think it is configurable, you need to look up the details). > Only > > after this period the action is retried. If it fails again, it is > > re-suspended, but this time with a longer suspension period. This is > done so > > that rsyslog does not spent a lot of time on actions known to be > failing. > > So you say, if i wait long enough the messages should receive the end > of the pipe? Yes, that's what I assume. > > Are there some related debug printouts i can search for? Search for "suspend", that should bring up a couple of messages. > > Can you give some hints to the related configuration parameters (URL or > keyword). Unfortunately the manual is not very helpful here. See http://www.rsyslog.com/doc/rsyslog_conf_global.html quick check brings up that $ActionResumeRetryCount $ACtionREsumeInterval Is relevant > > > From what you wrote, I think your use case would probably better be > served by > > omprog, but I may be wrong. If you think about this route, you need > to know > > that someone requested the functionality, but was never seen when it > was done > > ;) So the module is only barely tested. > > Same wish. Where can i read more about omprog? I thought I had writen some doc before I learned that this work was not being used by the original requester. I just checked, but it does not seem so. So it is probably best to look at the source. Rainer > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 12:46:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:46:10 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> This may also be of interest: http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982. html Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 12:43 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 12:33 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > > This sounds like intended behavior. When an action fails (pipe > fails > > when > > > nobody reads and it is tried to write to it), rsyslog retries the > > configured > > > number of times and then suspends the action for the configured > > period (at > > > least I think it is configurable, you need to look up the details). > > Only > > > after this period the action is retried. If it fails again, it is > > > re-suspended, but this time with a longer suspension period. This > is > > done so > > > that rsyslog does not spent a lot of time on actions known to be > > failing. > > > > So you say, if i wait long enough the messages should receive the end > > of the pipe? > > Yes, that's what I assume. > > > > > Are there some related debug printouts i can search for? > > Search for "suspend", that should bring up a couple of messages. > > > > > Can you give some hints to the related configuration parameters (URL > or > > keyword). Unfortunately the manual is not very helpful here. > > See > http://www.rsyslog.com/doc/rsyslog_conf_global.html > > quick check brings up that > $ActionResumeRetryCount > $ACtionREsumeInterval > > Is relevant > > > > > > From what you wrote, I think your use case would probably better be > > served by > > > omprog, but I may be wrong. If you think about this route, you need > > to know > > > that someone requested the functionality, but was never seen when > it > > was done > > > ;) So the module is only barely tested. > > > > Same wish. Where can i read more about omprog? > > I thought I had writen some doc before I learned that this work was not > being > used by the original requester. I just checked, but it does not seem > so. So > it is probably best to look at the source. > > Rainer > > > > Regards, > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From joel.merrick at gmail.com Thu Jul 29 12:53:13 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 29 Jul 2010 11:53:13 +0100 Subject: [rsyslog] Problem with mysql template Message-ID: Hi all, I'm trying to create a very quick mail log searching solution. The idea is to pre-hash the database by using the last 2 alpha-numeric characters on the message id. This isn't inserting to the database and I can't think why.. I've already built the tables with the structure logs-aa.. logs-ZZ etc.. $template OurDBLog,"INSERT INTO logs-'%msg:R,ERE,1,NULL:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-([A-Za-z0-9]{2})--end%' (messageid, host, \ send_host, created_at, payload, subject) values \ ('%msg:R,ERE,0,ZERO:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-[A-Za-z0-9]{2}--end%','%HOSTNAME%', '%msg:R,ERE,0,ZERO:H=.*\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}]--end%', \ '%timegenerated:::date-mysql%', '%msg%', '%msg:R,ERE,1,ZERO:T="(.+)"--end%')",SQL Any idea? On a side note, how can I get extra verbosity out of rsyslog so I'm not blindly trying to insert and then check via mysql Cheers, Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From sledz at dresearch.de Thu Jul 29 12:58:21 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:58:21 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> Message-ID: <4C515ECD.6060109@dresearch.de> Am 29.07.2010 12:46, schrieb Rainer Gerhards: > This may also be of interest: > > http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982.html General Error Language file ./language/en/404error.php couldn't be opened. Please notify the board administrator or webmaster: alorbach at adiscon.com :( From sledz at dresearch.de Thu Jul 29 13:13:04 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 13:13:04 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <4C516240.3000200@dresearch.de> Am 29.07.2010 12:43, schrieb Rainer Gerhards: >>> This sounds like intended behavior. When an action fails >>> (pipe fails when nobody reads and it is tried to write to >>> it), rsyslog retries the configured number of times and >>> then suspends the action for the configured period (at >>> least I think it is configurable, you need to look up the >>> details). Only after this period the action is retried. >>> If it fails again, it is re-suspended, but this time with >>> a longer suspension period. This is done so that rsyslog >>> does not spent a lot of time on actions known to be failing. >> >> So you say, if i wait long enough the messages should receive >> the end of the pipe? > > Yes, that's what I assume. I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 and your assumption seems to be wrong. :( If the receiver is available again after about 20 seconds (while flooding syslog with the mentioned script) it reads the content of the pipe and nothing more. The debug log from rsyslogd endless says ----------->snip<---------------- 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start 1711.687992707:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1711.688016872:b6644b70: Message from UNIX socket: #3 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start 1713.688441799:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1713.688488314:b6644b70: Message from UNIX socket: #3 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. ----------->snap<---------------- So it seems that rsyslogd does not detect that the receiver is available again (as mentioned before this only occurs if the receiver is not available for a "longer" time - probably the time the pipe runs full). Steffen From rgerhards at hq.adiscon.com Thu Jul 29 13:16:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:16:16 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <4C516240.3000200@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> OK, then this seems to be a bug indeed. I suggest you file a bug report with bugzilla. Usually, I tend to forget about those things if they exist on the mailing list only :( When they are in bugzilla, I pick them as soon as I have time to do so. It would probably wise to include a link to the mailing list archive. I will try to look into this ASAP, but it may take some while as I am pretty busy right at the moment. Thanks, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 1:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > >>> This sounds like intended behavior. When an action fails > >>> (pipe fails when nobody reads and it is tried to write to > >>> it), rsyslog retries the configured number of times and > >>> then suspends the action for the configured period (at > >>> least I think it is configurable, you need to look up the > >>> details). Only after this period the action is retried. > >>> If it fails again, it is re-suspended, but this time with > >>> a longer suspension period. This is done so that rsyslog > >>> does not spent a lot of time on actions known to be failing. > >> > >> So you say, if i wait long enough the messages should receive > >> the end of the pipe? > > > > Yes, that's what I assume. > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 > and your assumption seems to be wrong. :( > > If the receiver is available again after about 20 seconds (while > flooding syslog with the mentioned script) it reads the content of the > pipe and nothing more. > > The debug log from rsyslogd endless says > > ----------->snip<---------------- > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > 1711.687992707:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1711.688016872:b6644b70: Message from UNIX socket: #3 > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > 1713.688441799:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1713.688488314:b6644b70: Message from UNIX socket: #3 > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > ----------->snap<---------------- > > So it seems that rsyslogd does not detect that the receiver is > available again (as mentioned before this only occurs if the receiver > is not available for a "longer" time - probably the time the pipe runs > full). > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 13:19:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:19:27 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> One more thing: it may be useful if you could send me (privately) a complete debug log. I've just taken a look at ompipe, and there is no indication why this bug should happen. If I see how things proceed, I may be able to solve it quickly. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 1:16 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > OK, then this seems to be a bug indeed. I suggest you file a bug report > with > bugzilla. Usually, I tend to forget about those things if they exist on > the > mailing list only :( When they are in bugzilla, I pick them as soon as > I have > time to do so. It would probably wise to include a link to the mailing > list > archive. > > I will try to look into this ASAP, but it may take some while as I am > pretty > busy right at the moment. > > Thanks, > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 1:13 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > > >>> This sounds like intended behavior. When an action fails > > >>> (pipe fails when nobody reads and it is tried to write to > > >>> it), rsyslog retries the configured number of times and > > >>> then suspends the action for the configured period (at > > >>> least I think it is configurable, you need to look up the > > >>> details). Only after this period the action is retried. > > >>> If it fails again, it is re-suspended, but this time with > > >>> a longer suspension period. This is done so that rsyslog > > >>> does not spent a lot of time on actions known to be failing. > > >> > > >> So you say, if i wait long enough the messages should receive > > >> the end of the pipe? > > > > > > Yes, that's what I assume. > > > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval > 30 > > and your assumption seems to be wrong. :( > > > > If the receiver is available again after about 20 seconds (while > > flooding syslog with the mentioned script) it reads the content of > the > > pipe and nothing more. > > > > The debug log from rsyslogd endless says > > > > ----------->snip<---------------- > > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > > 1711.687992707:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1711.688016872:b6644b70: Message from UNIX socket: #3 > > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > > 1713.688441799:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1713.688488314:b6644b70: Message from UNIX socket: #3 > > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > ----------->snap<---------------- > > > > So it seems that rsyslogd does not detect that the receiver is > > available again (as mentioned before this only occurs if the receiver > > is not available for a "longer" time - probably the time the pipe > runs > > full). > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Thu Jul 29 13:24:29 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Thu, 29 Jul 2010 13:24:29 +0200 Subject: [rsyslog] OmoracleStatement format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: > > I think it would be best to split the RFC3339 date via the property > replacer > (using start and end position) and then feed this to omoracle. > > The full doc on property replacer is here: > > http://www.rsyslog.com/doc/property_replacer.html I first thought I could replace some strings with regex, but I've got a fix from coworker to solve the issue like this: $template OmoracleStatement,"INSERT INTO SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" $template TestStmt,"%hostname%%timereported:0:10:date-rfc3339%%timereported:12:32:date-rfc3339%%fromhost-ip%%syslogfacility%%syslogseverity%%programname%%msg%" It works great now. > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > It would be useful to write a quick debug file > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > This shows what exactly is stored in which property and can probably used > to > solve the question what exactly happens. > It seems that the issue with timestamp was the cause of all the problems. The data got displaced for one colon. Not it works like a charm. Thanks for the help. From sledz at dresearch.de Thu Jul 29 14:05:10 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 14:05:10 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> Message-ID: <4C516E76.3080209@dresearch.de> On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > One more thing: it may be useful if you could send me (privately) a complete > debug log. I've just taken a look at ompipe, and there is no indication why > this bug should happen. If I see how things proceed, I may be able to solve > it quickly. Is on the way. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 15:00:01 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:00:01 +0200 Subject: [rsyslog] OmoracleStatement format References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104024@GRFEXC.intern.adiscon.com> Excellent, great to hear it is working now :) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Thursday, July 29, 2010 1:24 PM > To: rsyslog-users > Subject: Re: [rsyslog] OmoracleStatement format > > > > > I think it would be best to split the RFC3339 date via the property > > replacer > > (using start and end position) and then feed this to omoracle. > > > > The full doc on property replacer is here: > > > > http://www.rsyslog.com/doc/property_replacer.html > > > I first thought I could replace some strings with regex, but I've got a > fix > from coworker to solve the issue like this: > > $template OmoracleStatement,"INSERT INTO > SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES > (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" > > $template > TestStmt,"%hostname%%timereported:0:10:date- > rfc3339%%timereported:12:32:date-rfc3339%%fromhost- > ip%%syslogfacility%%syslogseverity%%programname%%msg%" > > It works great now. > > > > > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > > > It would be useful to write a quick debug file > > > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > > > This shows what exactly is stored in which property and can probably > used > > to > > solve the question what exactly happens. > > > > It seems that the issue with timestamp was the cause of all the > problems. > The data got displaced for one colon. Not it works like a charm. > > Thanks for the help. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 15:07:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:07:31 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Ah, OK, now I see clearly. Well, the "obvious" happens, but I didn't realize it myself: You set the retry count to -1, that is infinite. So messages are never discarded. When nobody is reading the pipe, a queue builds up. In the log, the queue capacity is simply exhausted. As it looks from the log, nobody seems to be reading the pipe, at least we consistently get error 11 back from the write API call. Can you confirm this (I may be wrong, just looking quickly). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 2:05 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > > One more thing: it may be useful if you could send me (privately) a > complete > > debug log. I've just taken a look at ompipe, and there is no > indication why > > this bug should happen. If I see how things proceed, I may be able to > solve > > it quickly. > > Is on the way. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 15:18:05 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 15:18:05 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Message-ID: <4C517F8D.9020405@dresearch.de> On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > You set the retry count to -1, that is infinite. So > messages are never discarded. When nobody is reading > the pipe, a queue builds up. In the log, the queue > capacity is simply exhausted. As it looks from the > log, nobody seems to be reading the pipe, at least > we consistently get error 11 back from the write API > call. As i wrote before *there is someone reading* the pipe. In another shell i run while true; do cat /var/run/syslog2thinfs ; done Also when i kill and restart the reader the behaviour still is the same. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 16:35:33 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 16:35:33 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Did you keep it running for more than 30 seconds after it has reached the stalled state? From the log, it looks like it were only roughly 9 seconds. As I said, I don'T see any more activity inside the debug log. But maybe it is just hidden. I suggest you restart the test and then wait for 5 minutes and se what happens. You may want to stop the producer after a few seconds, because messages are still sitting inside the queue and that makes looking at the log easier. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 3:18 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > > You set the retry count to -1, that is infinite. So > > messages are never discarded. When nobody is reading > > the pipe, a queue builds up. In the log, the queue > > capacity is simply exhausted. As it looks from the > > log, nobody seems to be reading the pipe, at least > > we consistently get error 11 back from the write API > > call. > > As i wrote before *there is someone reading* the pipe. > > In another shell i run > > while true; do cat /var/run/syslog2thinfs ; done > > Also when i kill and restart the reader the behaviour still is the > same. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Fri Jul 30 00:33:43 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Thu, 29 Jul 2010 18:33:43 -0400 Subject: [rsyslog] How to write to a local socket? In-Reply-To: References: Message-ID: On Wed, Jul 28, 2010 at 21:43, Ryan Lynch wrote: > I'd like to forward via a local UNIX domain socket, instead. I think I > understand how to configure the 'imuxsock' module so my unprivileged > instance reads from a non-standard socket location. But I can't figure > out how to tell my root instance to forward via a local domain socket. I didn't figure out a completely RSyslog-native method, but another poster's message pointed me toward 'socat' and 'omprog', which I have working, now. (It would be really nice if RSyslog could support this natively, though.) In case anyone else wants to set this up, maybe this will save you some effort. I'm also interested in any comments/criticisms about this method, I'd love to hear suggestions for better ways to make this work. Also, I rolled it all up into a Fedora/EL RPM spec, and I'll send it on to anyone who's interested--just ask. Setup steps: * Install the 'socat' utility. * Build RSyslog with the '--enable-omprog' ./configure flag. * Create two separate RSyslog config files, one for the 'root' instance (writes to the socket) and a second for the 'unprivileged' instance (reads from the socket). * Rewrite your RSyslog init script to start two separate daemon instances, one using each config file (and separate PID files, too). * Create the user 'rsyslogd' and the group 'rsyslogd'. * Set permissions/ownerships as needed to allow the user 'rsyslogd' to write to the file '/var/log/rsyslog.log' * Create an executable script called '/usr/libexec/rsyslogd/omprog_socat' that contains the lines: #!/bin/bash /usr/bin/socat -t0 -T0 -lydaemon -d - UNIX-SENDTO:/dev/log * The 'root' instance config file should contain (modifying the output actions to taste): $ModLoad imklog $ModLoad omprog $Template FwdViaUNIXSocket,"<%pri%>%syslogtag%%msg%" $ActionOMProgBinary /usr/libexec/rsyslogd/omprog_socat *.* :omprog:;FwdViaUNIXSocket * The 'unprivileged' instance config file should contain (modifying the output actions to taste): $ModLoad imuxsock $PrivDropToUser rsyslogd $PrivDropToGroup rsyslogd *.* /var/log/rsyslog.log The 'root' daemon can only accept input from the kernel message buffer, and nothing else (especially not the syslog socket (/dev/log) or any network sockets). The unprivileged user will handle all of local and network log messages. To merge the kernel logs into the same data channel as everything else, here's what happens: [During the RSyslog daemons' startup] A) At startup, the 'root' daemon's 'imklog' module starts listening for kernel messages (via '/prog/kmsg'), and its 'omprog' module starts an instance of 'socat' (called via the 'omprog_socat' wrapper), establishing a persistent one-way IO connection where 'omprog' pipes its output to the STDIN of 'socat'. (Note that this same 'socat' instance remains running throughout the life of the RSyslog daemon, handling everything 'omprog' outputs. Contrast this, efficiency-wise, against the built-in 'subshell' module [the '^/path/to/program' action], which runs a separate instance instance of the child program for each message.) B) At startup, the 'unprivileged' daemon's 'imuxsock' module opens the system logging socket ('/dev/log') and starts listening for incoming log messages from other programs. [During normal operation] 1) The kernel buffer produces a message string on '/proc/kmsg'. 2) The 'root' RSyslog daemon reads the message from '/proc/kmsg', assigning it the priority number of 'kern.info' and the string tag 'kernel'. 3) The 'root' daemon prepends the priority number and tag as a header to the message string, and then passes it to the 'omprog' module for output (via persistent pipe) to the running 'socat' instance. 4) The 'socat' instance receives the header-framed message and sends it to the system logging socket ('/dev/log'). 5) The 'unprivileged' RSyslog daemon reads the message from '/dev/log', assigning it the priority and tag given in the message header, plus all of the other properties (timestamp, hostname, etc.) a message object should have. 6) The 'unprivileged' daemon formats the message and writes it to the output file. The only real difference I can see in the forwarded messages is that the 'source' property is set to 'imuxsock' instead of 'imklog'. I don't think that's a real problem, though, since the priority and tag are still distinct. -Ryan From sledz at dresearch.de Fri Jul 30 08:18:28 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:18:28 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Message-ID: <4C526EB4.9000106@dresearch.de> Am 29.07.2010 16:35, schrieb Rainer Gerhards: > Did you keep it running for more than 30 seconds after > it has reached the stalled state? From the log, it looks > like it were only roughly 9 seconds. As I said, I don'T > see any more activity inside the debug log. But maybe it > is just hidden. > > I suggest you restart the test and then wait for 5 minutes > and se what happens. You may want to stop the producer > after a few seconds, because messages are still sitting > inside the queue and that makes looking at the log > easier. I've rerun the test: * start rsyslog * start receiver * start producer * stop and restart receiver after 5 sec -> OK * stop and restart receiver after 30 sec -> stall * stop producer * wait 10 min and call "logger test" -> still stalling :( I'll send the logfile to your personal address again. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:26:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:26:13 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 16:35, schrieb Rainer Gerhards: > > Did you keep it running for more than 30 seconds after > > it has reached the stalled state? From the log, it looks > > like it were only roughly 9 seconds. As I said, I don'T > > see any more activity inside the debug log. But maybe it > > is just hidden. > > > > I suggest you restart the test and then wait for 5 minutes > > and se what happens. You may want to stop the producer > > after a few seconds, because messages are still sitting > > inside the queue and that makes looking at the log > > easier. > > I've rerun the test: > > * start rsyslog > * start receiver > * start producer > * stop and restart receiver after 5 sec -> OK > * stop and restart receiver after 30 sec -> stall > * stop producer > * wait 10 min and call "logger test" -> still stalling :( Interesting -- I don't see any reprobing of the output. Unfortunately, the debug output does not really provide much insight of what is going on at the moment. I'll see if I can add some more instrumentation to try track this down. Not sure if I can do this today. Rainer > > I'll send the logfile to your personal address again. > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 08:30:11 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:30:11 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> Message-ID: <4C527173.9090805@dresearch.de> Am 30.07.2010 08:26, schrieb Rainer Gerhards: > Interesting -- I don't see any reprobing of the output. > Unfortunately, the debug output does not really provide > much insight of what is going on at the moment. I'll see > if I can add some more instrumentation to try track this > down. Not sure if I can do this today. Can you give some hints which source files/functions are primarily involved here? May be we can do a little code review. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:45:23 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:45:23 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> <4C527173.9090805@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > Interesting -- I don't see any reprobing of the output. > > Unfortunately, the debug output does not really provide > > much insight of what is going on at the moment. I'll see > > if I can add some more instrumentation to try track this > > down. Not sure if I can do this today. > > Can you give some hints which source files/functions are primarily > involved here? May be we can do a little code review. I'd start with ./action.[ch] and obviously ompipe itself. It may be useful to see what/how ompipe returns. You can also set debug mode to do a function trace (see debug doc), this requires --enable-rtinst. Rainer > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Fri Jul 30 08:46:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:46:57 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com><4C527173.9090805@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104033@GRFEXC.intern.adiscon.com> And if you don't know this already, this doc may be useful: http://download.rsyslog.com/design.pdf It is not totally up to date, but covers the most important ides (most importantly the engine state transitions). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Friday, July 30, 2010 8:45 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Friday, July 30, 2010 8:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > > Interesting -- I don't see any reprobing of the output. > > > Unfortunately, the debug output does not really provide > > > much insight of what is going on at the moment. I'll see > > > if I can add some more instrumentation to try track this > > > down. Not sure if I can do this today. > > > > Can you give some hints which source files/functions are primarily > > involved here? May be we can do a little code review. > > I'd start with ./action.[ch] and obviously ompipe itself. It may be > useful to > see what/how ompipe returns. You can also set debug mode to do a > function > trace (see debug doc), this requires --enable-rtinst. > > Rainer > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 14:52:55 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 14:52:55 +0200 Subject: [rsyslog] [PATCH] break potential infinite loop in actionDoRetry In-Reply-To: <4C527173.9090805@dresearch.de> References: <4C527173.9090805@dresearch.de> Message-ID: <1280494375-11930-1-git-send-email-sledz@dresearch.de> If a module always returns RS_RET_OK (like ompipe does) the actionDoRetry loop may not have leaved faked ACT_STATE_SUSP state in case iResumeOKinRow had ever reached a count of 1000. Signed-off-by: Steffen Sledz --- action.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/action.c b/action.c index 32a07dc..90ec1bf 100644 --- a/action.c +++ b/action.c @@ -508,6 +508,7 @@ static rsRetVal actionDoRetry(action_t *pThis, time_t ttNow) iRet = pThis->pMod->tryResume(pThis->pModData); if((pThis->iResumeOKinRow > 999) && (pThis->iResumeOKinRow % 1000 == 0)) { bTreatOKasSusp = 1; + pThis->iResumeOKinRow = 0; } else { bTreatOKasSusp = 0; } -- 1.6.4.2 From ryan.b.lynch at gmail.com Fri Jul 30 15:28:45 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 09:28:45 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <4C456476.4010703@redhat.com> References: <4C456476.4010703@redhat.com> Message-ID: On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > read data from SOCK_DGRAM. This has two consequences: first, to be able > to attach rsyslog on the host end one first needs to copy the data > between the two socket types, e.g. using socat. Second, messages longer > than 1024 characters are sometimes split into two. The second message is > thus missing the syslog header and the receiving rsyslogd doesn't know > where to file it. Is there a recommended workaround for those things > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > SOCK_STREAM)? I ran into a similar problem. Doesn't it seem wierd that RSyslog: - can write TO a pipe, but it can't natively read FROM a pipe. - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. The only protocols that Rsyslog can both read to AND write from are network sockets (UDP, TCP, RELP) and real files. Maybe everybody just uses UDP for local intra-daemon message routing? I guess real file I/O would work, too, but that seems kind of ugly to me (lots of needless I/O to a particularly slow subsystem). Or maybe there hasn't been much demand to support multiple local daemon instances with combined message processing. I decided to use the 'omprog' module to write via 'socat' to the '/dev/log' socket. I like your method, too. And thank you for mentioning 'socat', that's what gave me the idea to go in this direction, in the first place. > 2) I seem to be unable to get the forwarding template right. For network > forwarding (which is also supported in Anaconda), simply putting no > explicit formatting does the trick: > *.* @@ some.host > The received logs can be matched for anything: severity, facility, > hostname and programname. > > This is not the case when logs are forwarded through the character device: > *.* /dev/virtio_ports/port_name > > Using the implicit formatting the receiving syslog won't parse the > programname. > > I tried using the predefined ForwardFormat but then the receiving > rsyslogd parsed hostname as the programname and the programname remains > part of the final message. Is that the expected behavior? What worked > for me in the end was creating a template based on the ForwardFormat but > with the %HOSTNAME% part omitted: I can live with that for know since I > know the message came from a certain socket so it can be only one host. > Still: it seems weird there's no forwarding format provided that would > retain 100% of the information parsable by another rsyslog reading from > a socket. I'm probably just missing something? I don't think the problem is your forwarding format--I don't think it's possible for RSyslog to handle a HOSTNAME field, properly, in messages received via socket. Based on my own tests, I believe that 'imuxsock' and 'imudp' use different logic to parse incoming messages. 'imuxsock' always assumes that the hostname is the local host, so it doesn't have the conditional logic to differentiate between "forwarded" messages (which have an extra HOSTNAME field between the timestamp and tag) versus regular local messages (no HOSTNAME). This is a pretty reasonable assumption, really--the local UNIX socket doesn't traditionally have any way to receive messages forwarded from other hosts. Rainer could probably confirm this, or we could compare those two modules' sources. RSyslog is a fantastic piece of software, and its feature set has come a long way. But all of Rainer's excellent work has expanded our imaginations about what Syslog can do, and maybe our imaginations are advancing faster than he can code new features. -Ryan From sean at conman.org Sat Jul 31 01:05:20 2010 From: sean at conman.org (Sean Conner) Date: Fri, 30 Jul 2010 19:05:20 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: References: <4C456476.4010703@redhat.com> Message-ID: <20100730230520.GA21655@brevard.conman.org> It was thus said that the Great Ryan Lynch once stated: > On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > > read data from SOCK_DGRAM. This has two consequences: first, to be able > > to attach rsyslog on the host end one first needs to copy the data > > between the two socket types, e.g. using socat. Second, messages longer > > than 1024 characters are sometimes split into two. The second message is > > thus missing the syslog header and the receiving rsyslogd doesn't know > > where to file it. Is there a recommended workaround for those things > > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > > SOCK_STREAM)? > > I ran into a similar problem. Doesn't it seem wierd that RSyslog: > - can write TO a pipe, but it can't natively read FROM a pipe. > - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. > The only protocols that Rsyslog can both read to AND write from are > network sockets (UDP, TCP, RELP) and real files. > > Maybe everybody just uses UDP for local intra-daemon message routing? The default syslog() call uses a local UDP socket (usually '/dev/log') and there's no overhead a programmer has to do in order to call syslog() (I mean, a programm can call openlog(), but it's not mandatory). So programs (other than syslogd) use local Unix UDP socket. For talking to other syslog daemons, I think the typical scenario is to run one locally, and any forwarding is done via an actual network socket. I never thought of doing relaying to another Unix socket. I know in my case (at home) I send a copy of all logs to 239.255.0.1, which is a multicast address (local segment only) so that I can run other instances of syslogd (or in my case, my own syslogd) on that address (on any machine on the segment); I can even run multiple copies locally listening to that address without issue. Adding support for multicast addresses was simple (about 32 lines of code, but it also supports IPv6). > I guess real file I/O would work, too, but that seems kind of ugly to > me (lots of needless I/O to a particularly slow subsystem). Or maybe > there hasn't been much demand to support multiple local daemon > instances with combined message processing. I decided to use the > 'omprog' module to write via 'socat' to the '/dev/log' socket. One issue with using files is that you end up having to poll a file for input. Normally, when you read from files, reading 0 bytes means you've hit the end of the file (and read() doesn't block on end-of-file for actual files). In this case (and in the case if doing a 'tail -f') you have to keep reading the file for more input once you hit the end. In the case of 'tail -f' (and for this, I checked the actual source code) it just sleeps for a second everytime it reads 0 bytes from a file. > I like your method, too. And thank you for mentioning 'socat', that's > what gave me the idea to go in this direction, in the first place. > > > > 2) I seem to be unable to get the forwarding template right. For network > > forwarding (which is also supported in Anaconda), simply putting no > > explicit formatting does the trick: > > *.* @@ some.host > > The received logs can be matched for anything: severity, facility, > > hostname and programname. > > > > This is not the case when logs are forwarded through the character device: > > *.* /dev/virtio_ports/port_name > > > > Using the implicit formatting the receiving syslog won't parse the > > programname. > > > > I tried using the predefined ForwardFormat but then the receiving > > rsyslogd parsed hostname as the programname and the programname remains > > part of the final message. Is that the expected behavior? What worked > > for me in the end was creating a template based on the ForwardFormat but > > with the %HOSTNAME% part omitted: I can live with that for know since I > > know the message came from a certain socket so it can be only one host. > > Still: it seems weird there's no forwarding format provided that would > > retain 100% of the information parsable by another rsyslog reading from > > a socket. I'm probably just missing something? > > I don't think the problem is your forwarding format--I don't think > it's possible for RSyslog to handle a HOSTNAME field, properly, in > messages received via socket. I agree, but replace "rsyslog" with "any syslog" (it's why in my own syslogd I only send IP addresses and not hostnames). > Based on my own tests, I believe that 'imuxsock' and 'imudp' use > different logic to parse incoming messages. 'imuxsock' always assumes > that the hostname is the local host, so it doesn't have the > conditional logic to differentiate between "forwarded" messages (which > have an extra HOSTNAME field between the timestamp and tag) versus > regular local messages (no HOSTNAME). This is a pretty reasonable > assumption, really--the local UNIX socket doesn't traditionally have > any way to receive messages forwarded from other hosts. If that's the case, then I'm surprised; in my syslogd, all messages (reguardless of source) go through the same parsing engine (then again, I only handle RFC-3164 style messages). I handle messages from the local socket by setting the "hostname" to the actual socket filename; I could have used "localhost" but I felt the actual socket filename would be better in those rare instances where you had a chroot'ed program that wrote to its own "/dev/log" socket so one could see which chroot'ed environment the log message was generated under. -spc From ryan.b.lynch at gmail.com Sat Jul 31 04:23:33 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 22:23:33 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <20100730230520.GA21655@brevard.conman.org> References: <4C456476.4010703@redhat.com> <20100730230520.GA21655@brevard.conman.org> Message-ID: Hi, Sean, On Fri, Jul 30, 2010 at 19:05, Sean Conner wrote: > It was thus said that the Great Ryan Lynch once stated: >> Maybe everybody just uses UDP for local intra-daemon message routing? > > ?The default syslog() call uses a local UDP socket (usually '/dev/log') and > there's no overhead a programmer has to do in order to call syslog() (I > mean, a programm can call openlog(), but it's not mandatory). ?So programs > (other than syslogd) use local Unix UDP socket. When I wrote "UDP", I could have been clearer--I meant "UDP over a loopback IP connection", not over a local socket. That's the distinction: Are you calling sendto() to a listener on 127.0.01, or to a listener on /dev/log? The point here is that RSyslog cannot natively send its output to /dev/log (as far as I can tell). RSyslog can do IPC via a '*.* @127.0.0.1' action, but there's no corresponding '*.* @/dev/log' action, at least as far as I know. So if you want to forward messages between daemons, you HAVE to listen on the loopback IP, unless you're willing to use something like 'omprog' or pipe output, both of which require invoking an external program like 'socat' or creating a named pipe. (It works, but it's messier and more complicated--performance might be worse, too.) For Ales's KVM application, there may be a worse problem: His virtual machines might not have working network interfaces at all times, such as during provisioning/build. That's why the distinction of network socket vs. local socket matters--if you don't have any networking interfaces up, or you have security concerns about rogue local processes sending malicious traffic to the 127.0.0.1 listener, then the lack of a "send to local socket" capability makes life a little more difficult. -Ryan From rgerhards at hq.adiscon.com Thu Jul 1 08:27:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 01 Jul 2010 08:27:57 +0200 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: <1277965677.18305.13.camel@localhost> On Wed, 2010-06-30 at 17:00 -0400, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: > > > > Note that being an evolution, any currently existing rsyslog.conf would also > > be a valid new conf (via the *same* parser). I have not thought out the full > > semantics and thousand other things that need to be thought of -- this > > actually opened up a can of worms ;) However, I find the proposed format > > seems to be a good compromise between the need to preserve and the need to > > move on, and between the need for simplicity and the need for power. > > > > As such, before I invest even more time into that format, I'd like to get > > some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). Don't mistake "general programming language" via "config language for a specialised engine". Full ACK for "general programming language". > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints Don't think in terms of "constraints", but in terms of "options" and "levels of (programming) freedom". "Constraints" sounds like a bad thing from legacy. In fact, what I need is the ability to do some very special, high performance things ;) > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. OK, Lua again. I've now written up why I don't consider Lua (or any other general-purpose language) a vital alternative for use in rsyslog: http://blog.gerhards.net/2010/07/why-i-think-lua-is-no-solution-for.html Please look carefully at the arguments, especially the facts that a) I do like things like Lua, but not in this context b) Lua misses support for SIMD processing c) Lua does not permit to execute based in the inherent partial order of config statements > If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. Well, that's a primary difference: speed is on of the *prime* concerns in rsyslog. I have looked at your implementation. Of course, I could have saved myself roughly 3 to 4 years of work if I used the same approach -- and rsyslog would most probably not be the alternative to syslog-ng it currently is. Also, I question if the typical sysadmin will actually like the format that you promote. All of the examples really scared me away. I have quoted the replacement for a standard red hat syslog.conf after my signature so that the other list members can do their own judgment. Rainer Now the replacement for a standard Red Hat syslog.conf with syslogintr (taken from above-mentioned URL, file "readhat.lua" inside the offered tarball): -- *************************************************************** -- -- Copyright 2010 by Sean Conner. All Rights Reserved. -- -- This program is free software: you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation, either version 3 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program. If not, see . -- -- Comments, questions and criticisms can be sent to: sean at conman.org -- -- ****************************************************************** -- -- A file the duplicates a default install of RedHat and their syslog.conf -- file. All functions not labeled as "local" are called directly via the -- runtime engine. -- -- cleanup() - called when the daemon exits -- reload_signal() - called when the program recieves a SIGHUP -- log() - called each time the daemon receives a message -- -- This is provided as a means to replace syslogd with a drop in -- replacement, but with the ability to expand upon the functionality as -- required. -- -- ******************************************************************* function cleanup() messages:close() secure:close() maillog:close() cron:close() spooler:close() boot:close() end -- ********************************************************************* local function openfiles() messages = io.open("/var/log/messages","a") or io.stdout secure = io.open("/var/log/secure" ,"a") or io.stdout maillog = io.open("/var/log/maillog" ,"a") or io.stdout cron = io.open("/var/log/cron" ,"a") or io.stdout spooler = io.open("/var/log/spooler" ,"a") or io.stdout boot = io.open("/var/log/boot" ,"a") or io.stdout end openfiles() -- ********************************************************************* function reload_signal() cleanup() openfiles() end -- ********************************************************************* local function logfile(msg,file,flushp) local flushp = flushp or false if msg.remote == false then msg.host = "localhost" end file:write(string.format( "%s %s %s[%d]: %s\n", os.date("%b %d %H:%M:%S",msg.timestamp), msg.host, msg.program, msg.pid, msg.msg )) if flushp then file:flush() end end -- ****************************************************************** local function everybody(msg) local out = io.popen("/usr/bin/wall","w") logfile(msg,out) out:close() end -- ****************************************************************** function log(msg) if msg.level == 'info' or msg.level == 'notice' or msg.level == 'warn' or msg.level == 'err' or msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then if msg.facility ~= 'mail' and msg.facility ~= 'auth2' and msg.facility ~= 'cron' and msg.facility ~= 'local6' then logfile(msg,messages) end end if msg.facility == 'auth2' then logfile(msg,secure) end if msg.facility == 'mail' then logfile(msg,maillog,true) end if msg.facility == 'cron' then logfile(msg,cron) end if msg.level == 'emerg' then everybody(msg) end if msg.facility == 'uucp' or msg.facility == 'news' then if msg.level == 'crit' or msg.level == 'alert' or msg.level == 'emerg' then logfile(msg,spooler) end end if msg.facility == 'local7' then logfile(msg,boot) end end -- ******************************************************************** From raja.rhel5 at gmail.com Thu Jul 1 10:10:31 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 13:40:31 +0530 Subject: [rsyslog] rsyslog Message-ID: hi, I have configured rsylog and mysql server..everything working fine. But i found after examining it for 1 week, all the logs are consuming lot of space.so i decided not to delete all the logs in database? how can i do it? how to redirect only important logs...kern,errors,warnings...? Thanks in advance. raja antony From tomasz.glowacki at pseinfo.pl Thu Jul 1 10:37:44 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 10:37:44 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 Message-ID: <8610433990.20100701103744@pseinfo.pl> Hi everyone, Web forum seems dead for a while, so I decided to post to mailing list. I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to a files based on facility and some simple forwarding using omudpspoof. That is all I have plus generic system logging. Default as much as it can be ;) rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while 5.5.0 seems to work quite normal but with CPU load for the process reaching 99%. This is simple Pentium III 833 machine. I did some sort of debuging. I disabled /dev/xconsole section, immark module as sugested. No change at all. Then, ran rsyslogd with -d and there were no errors at all, normal initialization and no further messages at all. After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of the files started to grow about 1-2 megabytes every few seconds with something like that: clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 this is tail from that rapidly growing file. How can I solve this? What kind of information should I provide to solve the problem? :) I'm open and ready for further debugging. Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with the same config besides that it doesn't support omudpspoof module, so forwarding of messages is quite useless.. -- Best regards, Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl From david at lang.hm Thu Jul 1 11:06:03 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:06:03 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: I ran into this same problem and finally discovered that it was because there were two sets of rsyslog modules, the old ubuntu defaults and the ones I compiled. the wrong ones were being found and problems resulted. you may find that you have files in /usr/lib/rsyslog and in /usr/local/lib/rsyslog delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. rsyslog needs to eventually gain the ability to version the modules and report when the wrong version module is loaded. But at the moment this is not available. David Lang On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Date: Thu, 1 Jul 2010 10:37:44 +0200 > From: utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi everyone, > > Web forum seems dead for a while, so I decided to post to mailing > list. > > I'm having problem running rsyslogd 5.4.0 and 5.5.0 compiled under > Ubuntu 10.04 x86. I'm using quite basic configuration: just logging to > a files based on facility and some simple forwarding using omudpspoof. > That is all I have plus generic system logging. Default as much as it > can be ;) > > rsyslogd is hogging my CPU. 5.4.0 doesn't even log a message, while > 5.5.0 seems to work quite normal but with CPU load for the process > reaching 99%. This is simple Pentium III 833 machine. > > I did some sort of debuging. I disabled /dev/xconsole section, immark > module as sugested. No change at all. > > Then, ran rsyslogd with -d and there were no errors at all, normal > initialization and no further messages at all. > > After all I did strace -ff -o /tmp/sysl.txt rsyslog -d -c4, and one of > the files started to grow about 1-2 megabytes every few seconds with > something like that: > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) = -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 > > this is tail from that rapidly growing file. > > How can I solve this? What kind of information should I provide to > solve the problem? :) I'm open and ready for further debugging. > > Distributed with Ubuntu 10.04 rsyslogd 4.2.0 is working just fine with > the same config besides that it doesn't support omudpspoof module, so > forwarding of messages is quite useless.. > > > > -- > Best regards, > Tomasz G?owacki mailto:tomasz.glowacki at pseinfo.pl > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 1 11:08:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 02:08:15 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100630210008.GA12179@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100630210008.GA12179@brevard.conman.org> Message-ID: On Wed, 30 Jun 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > You need to be very careful when creating your own language. I did that > once (created my own langauge, back in college, just for fun) and recently > benchmarked it against commonly used scripting languages today and the > results were horrible---mine was the slowest tested (Perl, Lua, Python; I > was afraid of testing Ruby in fear to losing there too). That's an issue to > watch out for---a slow interpreter (or particularly bad internal code > representation). one key thing is that this language is not a script to be executed as logs come in, it's a config file that will get read in to configure rsyslog internals (compiiled into the rsyslog internal function calls effectivly) no off-the-shelf language is fast enough for the data rates that rsyslog is able to reach today. David Lang > Sure, now you're just adding an "if ... then ... [else ...]" construct > now, but as people get used to this, there might be calls for additional > functionality, like variables (why can't I declare file paths as constants > in one location, etc etc) and pretty soon you'll have a fully blown > programming language (maybe not this year, maybe not next, but some day). > That's a second issue to watch out for---feeping creaturism. > > Other than that, I don't really have much to say about the syntax. I know > you're trying to work within an existing framework so you do have some > contraints and I've certainly seen (and worked) with worse configuration > files (sendmail.cf comes to mind). > > One last thing though, in looking over your proposed syntax for > RainerScript I see that's it already is awfully close to Lua: > > ruleset remote10515 { > if pri("mail.*") then { > action(type="omfile" file="/var/log/remote10514") > action(use="dynfile") > action(type="udpfwd" action.execonlyonce="5sec" > target="192.168.1.2" port="514") > } > action(type="udpfwd" target="192.168.1.3" > action.previousfailed="on") > action(type="omfile" file="/var/log/catchall") > if $severity == 'error' and $msg contains 'Link 2' then > action(type="ommail" server="192.168.1.3" > from="someone at example.net" > to="ops at example.net" > subject="###error \"detected\"###") > } > > could be translated into Lua as: > > function remote10515() > if pri("mail.*") then > action { type="omfile" , file="/var/log/remote10514" } > action { use="dynfile" } > action { > type = "udpfwd" , > action = { execonlyonce="5sec" }, > target = "192.168.1.2", > port = 514 > } > end > > action { > type="udpfwd" , > target="192.168.1.3" , > action = { previousfailed = true } > } > action { type="omfile" , file="/var/log/catchall" } > if severity == 'error' and string.find(msg,'Link 2') then > action { > type="ommail", > server="192.168.1.3", > from="someone at example.net", > to="ops at example.net", > subject=[[###error "detected"###]] > } > end > end > > It's a shame you're rejecting Lua---it's considered one of the fastested > scripting languages and dead simple to embed. If you would like to see what > could be done with Lua, you might want to check out my own syslogd I wrote > that embeds Lua: > > http://www.conman.org/software/syslogintr/ > > There is a speed hit (about 35%) in using Lua vs. straight C, but so far, > speed hasn't been an issue in what I do. > > -spc (which includes the processing of multiple thin logs into one fat > log) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From tomasz.glowacki at pseinfo.pl Thu Jul 1 11:57:33 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 11:57:33 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <6410167759.20100701115733@pseinfo.pl> Witam, Thursday, July 1, 2010, 11:06:03 AM, you wrote: > I ran into this same problem and finally discovered that it was because > there were two sets of rsyslog modules, the old ubuntu defaults and the > ones I compiled. the wrong ones were being found and problems resulted. > you may find that you have files in /usr/lib/rsyslog and in > /usr/local/lib/rsyslog > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu package. > rsyslog needs to eventually gain the ability to version the modules and > report when the wrong version module is loaded. But at the moment this is > not available. I don't think it is a good solution. If I compile 5.5.0 with --prefix=/my/directory and then make install is done to that directory rsyslogd should read libs from there (and in fact - is doing that because omudpspoof module is working). Not from /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. Why rsyslogd is searching for other libs elsewhere than in it's install directory? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Dzia? Sieci tel. (022) 3401597, (601) 672872 From rgerhards at hq.adiscon.com Thu Jul 1 13:55:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 13:55:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 11:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 11:06:03 AM, you wrote: > > > I ran into this same problem and finally discovered that it was > because > > there were two sets of rsyslog modules, the old ubuntu defaults and > the > > ones I compiled. the wrong ones were being found and problems > resulted. > > > you may find that you have files in /usr/lib/rsyslog and in > > /usr/local/lib/rsyslog > > > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > package. > > > rsyslog needs to eventually gain the ability to version the modules > and > > report when the wrong version module is loaded. But at the moment > this is > > not available. > > I don't think it is a good solution. > > If I compile 5.5.0 with --prefix=/my/directory and then make install > is done to that directory rsyslogd should read libs from there (and in > fact - is doing that because omudpspoof module is working). Not from > /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > > Why rsyslogd is searching for other libs elsewhere than in it's > install directory? It depends on how you configure the running system (not the build system). There is a command line switch as well as a config directive that tells form where to load modules. Distros usually set their defaults with these directives. To the root question: this may be caused by a bug. I suggest that you check out the current master branch, it may work (which would be an indication of a bug). I did some changes to the code, and I had the impression that what you report could actually something that happens with the older codebase (5.5.5 in this view being "older" ;)). HTH Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 14:51:43 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 14:51:43 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <6410167759.20100701115733@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> Message-ID: <235067282.20100701145143@pseinfo.pl> Witam, Thursday, July 1, 2010, 1:55:58 PM, you wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) >> Sent: Thursday, July 01, 2010 11:58 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 >> >> Witam, >> >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: >> >> > I ran into this same problem and finally discovered that it was >> because >> > there were two sets of rsyslog modules, the old ubuntu defaults and >> the >> > ones I compiled. the wrong ones were being found and problems >> resulted. >> >> > you may find that you have files in /usr/lib/rsyslog and in >> > /usr/local/lib/rsyslog >> >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu >> package. >> >> > rsyslog needs to eventually gain the ability to version the modules >> and >> > report when the wrong version module is loaded. But at the moment >> this is >> > not available. >> >> I don't think it is a good solution. >> >> If I compile 5.5.0 with --prefix=/my/directory and then make install >> is done to that directory rsyslogd should read libs from there (and in >> fact - is doing that because omudpspoof module is working). Not from >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. >> >> Why rsyslogd is searching for other libs elsewhere than in it's >> install directory? > It depends on how you configure the running system (not the build system). > There is a command line switch as well as a config directive that tells form > where to load modules. Distros usually set their defaults with these > directives. Ok, which command line switch do you mean? And which config directive? :) I'll try to clarify: where from rsyslogd is getting it's libs by default? (as manual page says: " prefix/lib/rsyslog Default directory for rsyslogd modules. The prefix is specified during compilation (e.g. /usr/local)." I would like to know if rsyslogd is REALLY getting it's libs from prefix path. Just not to mess my system completly. > To the root question: this may be caused by a bug. I suggest that you check > out the current master branch, it may work (which would be an indication of a > bug). I did some changes to the code, and I had the impression that what you > report could actually something that happens with the older codebase (5.5.5 > in this view being "older" ;)). I'll try that but rather as my "last resort".... I would love to see 5.4.0 or 5.5.5 working properly here.... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 14:55:08 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 14:55:08 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 2:52 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 1:55:58 PM, you wrote: > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > >> Sent: Thursday, July 01, 2010 11:58 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > >> > >> Witam, > >> > >> Thursday, July 1, 2010, 11:06:03 AM, you wrote: > >> > >> > I ran into this same problem and finally discovered that it was > >> because > >> > there were two sets of rsyslog modules, the old ubuntu defaults > and > >> the > >> > ones I compiled. the wrong ones were being found and problems > >> resulted. > >> > >> > you may find that you have files in /usr/lib/rsyslog and in > >> > /usr/local/lib/rsyslog > >> > >> > delete the wrong ones (probably /usr/lib/rsyslog is the ubuntu > >> package. > >> > >> > rsyslog needs to eventually gain the ability to version the > modules > >> and > >> > report when the wrong version module is loaded. But at the moment > >> this is > >> > not available. > >> > >> I don't think it is a good solution. > >> > >> If I compile 5.5.0 with --prefix=/my/directory and then make install > >> is done to that directory rsyslogd should read libs from there (and > in > >> fact - is doing that because omudpspoof module is working). Not from > >> /usr/lib/rsyslog. Or maybye I'm wrong somewhere... correct me. > >> > >> Why rsyslogd is searching for other libs elsewhere than in it's > >> install directory? > > > It depends on how you configure the running system (not the build > system). > > There is a command line switch as well as a config directive that > tells form > > where to load modules. Distros usually set their defaults with these > > directives. > > Ok, which command line switch do you mean? And which config directive? > :) I'll check the doc as soon as I have time to do so... Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:16:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:16:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com> <235067282.20100701145143@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> Message-ID: <1989837614.20100701151634@pseinfo.pl> Hi, Thursday, July 1, 2010, 2:55:08 PM, you wrote: > I'll check the doc as soon as I have time to do so... If you meant $ModDir that doesn't change much... -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:18:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:18:35 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:17 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Hi, > > Thursday, July 1, 2010, 2:55:08 PM, you wrote: > > > > I'll check the doc as soon as I have time to do so... > > If you meant $ModDir that doesn't change much... Ah, yes, that's the name of it. The startup option is probably something like -m or -M. The simplest thing probably is to check your startup script (wherever that is located on your distro). Rainer From marc.schiffbauer at mightycare.de Thu Jul 1 15:04:04 2010 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 1 Jul 2010 15:04:04 +0200 Subject: [rsyslog] rsyslog In-Reply-To: References: Message-ID: <201007011504.04602.marc.schiffbauer@mightycare.de> Hi raja, read the docs on the homepage. you can select what to put into the database in the same way as you select what goes into which logfile. for deletin old log you will have to issue a SQL command uisng a mysql client (DELETE FROM WHERE <= ) -marc On Thursday 01 July 2010 10:10:31 Raja antony wrote: > hi, > > I have configured rsylog and mysql server..everything working fine. > > But i found after examining it for 1 week, all the logs are consuming lot > of space.so i decided not to delete all the logs in database? > > how can i do it? > > how to redirect only important logs...kern,errors,warnings...? > > Thanks in advance. > raja antony > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux :: Virtualization Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/impressum From tomasz.glowacki at pseinfo.pl Thu Jul 1 15:24:34 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 15:24:34 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com> <1989837614.20100701151634@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> Message-ID: <1987371782.20100701152434@pseinfo.pl> Witam, Thursday, July 1, 2010, 3:18:35 PM, you wrote: > Ah, yes, that's the name of it. The startup option is probably something like > -m or -M. The simplest thing probably is to check your startup script > (wherever that is located on your distro). Yep, -M. Tried that too. So, I could be sure that this is not version conflict. Forcing loading from exact path does the same as default - CPU hog on 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From rgerhards at hq.adiscon.com Thu Jul 1 15:26:21 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 15:26:21 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Glowacki, Tomasz (INFO) > Sent: Thursday, July 01, 2010 3:25 PM > To: rsyslog-users > Subject: Re: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 > > Witam, > > Thursday, July 1, 2010, 3:18:35 PM, you wrote: > > > Ah, yes, that's the name of it. The startup option is probably > something like > > -m or -M. The simplest thing probably is to check your startup script > > (wherever that is located on your distro). > > Yep, -M. Tried that too. So, I could be sure that this is not version > conflict. Forcing loading from exact path does the same as default - > CPU hog on 99% That's what I suspected... So we need to see if it is already fixed or not (master branch). If not, we need to look at the debug log and try to find out what is going on. Rainer From tomasz.glowacki at pseinfo.pl Thu Jul 1 16:33:58 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Thu, 1 Jul 2010 16:33:58 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> Message-ID: <518726404.20100701163358@pseinfo.pl> Hi, Thursday, July 1, 2010, 3:26:21 PM, you wrote: > That's what I suspected... > So we need to see if it is already fixed or not (master branch). If not, we > need to look at the debug log and try to find out what is going on. Ok, that's my next try. But, I think I'm getting close to the goal. When I comment: $PrivDropToUser syslog $PrivDropToGroup adm and run the rsyslogd via sudo - it's running perfect with no CPU hog. It runs as root then. Uncommenting that gives CPU hog but running as user syslog. I've checked file priviledges and they're ok, same as directories, wherever rsyslogd needs to read/write. As I said, 4.2.0 running on the same config, same priviledge level works well. -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From james at linux-source.org Thu Jul 1 17:00:23 2010 From: james at linux-source.org (James Corteciano) Date: Thu, 1 Jul 2010 23:00:23 +0800 Subject: [rsyslog] PHP error logs In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F3E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F40@GRFEXC.intern.adiscon.com> Message-ID: Hi Rainer, The following are my settings in remote php server. [/etc/rsyslog.conf] $ModLoad imfile $InputFileName /var/log/php/example.com/error_log $InputFileTag example.com.php.error: $InputFileStateFile stat-example.com $InputFileSeverity error $InputFileFacility local6 $InputRunFileMonitor $InputFilePollingInterval 1 local6.* @192.168.10.125 The problem is it takes 10 seconds to received the php error logs on central syslog server. How can I speed up the receiving of logs on syslog server? Do I need to add/modify on any settings? Thanks. Regards, James On Wed, Jun 30, 2010 at 8:22 PM, Rainer Gerhards wrote: > Hi James, > > well, after imfile reads the messages, they *are* already present in > rsyslog > and so they are in the syslog server. It is not a push model but rather a > pull model (the syslog server pulls the messages from the file instead of > them being pushed to it). > > If you mean how to forward them to a remote server: that's business as > usual, > so you can just do > > *.* @remote-server > > ..or use any other forwarding action. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > Sent: Wednesday, June 30, 2010 1:43 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] PHP error logs > > > > Hi Rainer, > > > > How to push the logs to syslog server? > > > > On Wed, Jun 30, 2010 at 4:49 PM, Rainer Gerhards > > wrote: > > > > > Hi James, > > > > > > if I understood you correctly, imfile may be your friend: > > > > > > http://www.rsyslog.com/doc-imfile.html > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of James Corteciano > > > > Sent: Wednesday, June 30, 2010 5:32 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] PHP error logs > > > > > > > > Hi All, > > > > > > > > I know this is out of topic here in mailing list but I couldn't get > > > > into php > > > > mailing list. > > > > > > > > Anyone have try to log php errors and forwarded it to centralized > > > > rsyslog > > > > server? I can received logs locally from /var/log/messages > > (specified > > > > from > > > > /etc/php.ini) but I want to forward it to centralized log. > > > > > > > > Thanks. > > > > > > > > Regards, > > > > James > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 1 19:02:36 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 1 Jul 2010 10:02:36 -0700 (PDT) Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <518726404.20100701163358@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl><6410167759.20100701115733@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F47@GRFEXC.intern.adiscon.com><235067282.20100701145143@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F49@GRFEXC.intern.adiscon.com><1989837614.20100701151634@pseinfo.pl><9B6E2A8877C38245BFB15CC491A11DA7103F4B@GRFEXC.intern.adiscon.com> <1987371782.20100701152434@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F4C@GRFEXC.intern.adiscon.com> <518726404.20100701163358@pseinfo.pl> Message-ID: On Thu, 1 Jul 2010, utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= wrote: > Hi, > > Thursday, July 1, 2010, 3:26:21 PM, you wrote: > > >> That's what I suspected... > >> So we need to see if it is already fixed or not (master branch). If not, we >> need to look at the debug log and try to find out what is going on. > > Ok, that's my next try. But, I think I'm getting close to the > goal. > > When I comment: > $PrivDropToUser syslog > $PrivDropToGroup adm > > and run the rsyslogd via sudo - it's running perfect with no CPU hog. > It runs as root then. > > Uncommenting that gives CPU hog but running as user syslog. I've > checked file priviledges and they're ok, same as directories, wherever > rsyslogd needs to read/write. > > As I said, 4.2.0 running on the same config, same priviledge level works well. when I had this problem, logging *.* somewhere showed me 200,000 logs/sec being generated by an error message saying that rsyslog was not allowed to read something. do you have anything similar in your logs? David Lang From epiphani at gmail.com Thu Jul 1 19:14:12 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Thu, 1 Jul 2010 13:14:12 -0400 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <8610433990.20100701103744@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> Message-ID: 2010/7/1 G?owacki, Tomasz (INFO) : > > clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0 > write(1, "9500.585805743:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0 > write(1, "9500.586203967:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0 > write(1, "9500.586596069:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0 > write(1, "9500.586991581:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0 > write(1, "9500.587383376:", 15) ? ? ? ? = -1 EINVAL (Invalid argument) > write(1, "b776db70: ", 10) ? ? ? ? ? ? ?= -1 EINVAL (Invalid argument) > write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument) > clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0 This looks like a bug. Can you provide a list of your environment variables on startup? This looks like debug logs are trying to be sent to stdout - which is failing because stdout is closed (as it should be for a daemonized application). Something somewhere has flipped debugging information on, and yet still forked the process off of the terminal. Configuring the app this way should be impossible - if its something in configuration... if not, its just a bug where debug is being properly activated after a fork. -Aaron From rgerhards at hq.adiscon.com Thu Jul 1 20:11:39 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 1 Jul 2010 20:11:39 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 References: <8610433990.20100701103744@pseinfo.pl> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> > This looks like debug logs are trying to be sent to stdout - which is > failing because stdout is closed (as it should be for a daemonized > application). Something somewhere has flipped debugging information > on, and yet still forked the process off of the terminal. Configuring > the app this way should be impossible - if its something in > configuration... if not, its just a bug where debug is being properly > activated after a fork. Good catch! I was so preoccupied with the known issue of action error not being properly acted on by the transaction processor, I did not notice the actual data. A full debug log should help to find out what is going on. Thanks! Rainer From raja.rhel5 at gmail.com Fri Jul 2 07:59:49 2010 From: raja.rhel5 at gmail.com (Raja antony) Date: Thu, 1 Jul 2010 22:59:49 -0700 Subject: [rsyslog] Raja antony wants to chat Message-ID: ----------------------------------------------------------------------- Raja antony wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI You'll need to click this link to be able to chat with Raja antony. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with Raja antony, visit: http://mail.google.com/mail/a-bcb4da2131-1d3ef99aea-eBgpI6PU67VjvQGgadlwGpUL4mI Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From tomasz.glowacki at pseinfo.pl Fri Jul 2 09:57:04 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 09:57:04 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <661878047.20100702095704@pseinfo.pl> Witam, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Is your list allowing attachments? Or pasting huge amount of debug here? -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 14:00:55 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 14:00:55 +0200 Subject: [rsyslog] high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> Message-ID: <1571565725.20100702140055@pseinfo.pl> Hi, Thursday, July 1, 2010, 8:11:39 PM, you wrote: > Good catch! I was so preoccupied with the known issue of action error not > being properly acted on by the transaction processor, I did not notice the > actual data. A full debug log should help to find out what is going on. Here it is, debug: http://pastebin.com/RXQim1yh it ends just after dropping priviledges. No more messages appear. CPU is at 99% -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From tomasz.glowacki at pseinfo.pl Fri Jul 2 16:42:12 2010 From: tomasz.glowacki at pseinfo.pl (=?utf-8?Q?G=C5=82owacki=2C_Tomasz_ ?= (INFO)) Date: Fri, 2 Jul 2010 16:42:12 +0200 Subject: [rsyslog] [solved] - high CPU usage on 5.5.5 and 5.4.0 In-Reply-To: <1571565725.20100702140055@pseinfo.pl> References: <8610433990.20100701103744@pseinfo.pl> <9B6E2A8877C38245BFB15CC491A11DA7103F50@GRFEXC.intern.adiscon.com> <1571565725.20100702140055@pseinfo.pl> Message-ID: <585116747.20100702164212@pseinfo.pl> Witam, Friday, July 2, 2010, 2:00:55 PM, you wrote: > Here it is, debug: > http://pastebin.com/RXQim1yh > it ends just after dropping priviledges. No more messages appear. CPU > is at 99% Ok, problem is gone now. If the config directive KLogPath was set to: $KLogPath /var/run/rsyslog/kmsg CPU has been hogged. Changing it to /proc/kmsg solved the problem completly. There were no file at /var/run/rsyslog/kmsg created during daemon start. Why? I dunno. The problem is described shortly at: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/401433 -- Best regards, G?owacki, Tomasz (INFO) mailto:tomasz.glowacki at pseinfo.pl From P at draigBrady.com Tue Jul 6 14:52:44 2010 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Tue, 06 Jul 2010 13:52:44 +0100 Subject: [rsyslog] TCP connections not being closed Message-ID: <4C33271C.70805@draigBrady.com> I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 server on debian. Eventually the server exhausts it's connections as there are multiple connections from each client. Taking 1 client in particular: server# lsof -n -i at 10.132.8.1 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME rsyslogd 29775 root 325u IPv4 81017793 TCP 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) rsyslogd 29775 root 515u IPv4 81085917 TCP 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) rsyslogd 29775 root 531u IPv4 81187589 TCP 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) rsyslogd 29775 root 568u IPv4 81263960 TCP 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) rsyslogd 29775 root 570u IPv4 81275186 TCP 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) rsyslogd 29775 root 573u IPv4 81300023 TCP 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) rsyslogd 29775 root 574u IPv4 81412888 TCP 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) rsyslogd 29775 root 588u IPv4 81503100 TCP 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) rsyslogd 29775 root 591u IPv4 81559427 TCP 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) rsyslogd 29775 root 593u IPv4 81593574 TCP 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) rsyslogd 29775 root 595u IPv4 81624236 TCP 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) rsyslogd 29775 root 599u IPv4 81631713 TCP 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) rsyslogd 29775 root 601u IPv4 81641244 TCP 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) rsyslogd 29775 root 603u IPv4 82260661 TCP 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) rsyslogd 29775 root 684u IPv4 84358985 TCP 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) rsyslogd 29775 root 699u IPv4 84499197 TCP 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) rsyslogd 29775 root 701u IPv4 84557429 TCP 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) rsyslogd 29775 root 714u IPv4 86973034 TCP 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) rsyslogd 29775 root 823u IPv4 88591917 TCP 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) rsyslogd 29775 root 999u IPv4 90314222 TCP 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) rsyslogd 29775 root 1003u IPv4 125443032 TCP 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) server# ssh 10.132.8.1 lsof -n -i :514 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsyslogd 1595 root 8u IPv4 59789 0t0 TCP 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) So you can see that the client has only 1 connection open, while the server has many. Could the server be changed to close connections old connections to a particular IP? I guess that would have issues for NATing, or perhaps the server could just timeout the TCP connections after a period of inactivity? Any ideas appreciated. cheers, P?draig. For my own reference, these seem closely related: http://kb.monitorware.com/post5056.html http://bugzilla.adiscon.com/show_bug.cgi?id=190 From ktm at rice.edu Tue Jul 6 15:04:51 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:04:51 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C33271C.70805@draigBrady.com> References: <4C33271C.70805@draigBrady.com> Message-ID: <20100706130451.GI341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 01:52:44PM +0100, P??draig Brady wrote: > I've a 400 rsyslog-4.4.2-1.fc12.i686 clients connecting to a 4.6.2-1 > server on debian. Eventually the server exhausts it's connections as > there are multiple connections from each client. > > Taking 1 client in particular: > > server# lsof -n -i at 10.132.8.1 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > rsyslogd 29775 root 325u IPv4 81017793 TCP > 10.132.253.51:shell->10.132.8.1:33554 (ESTABLISHED) > rsyslogd 29775 root 515u IPv4 81085917 TCP > 10.132.253.51:shell->10.132.8.1:42570 (ESTABLISHED) > rsyslogd 29775 root 531u IPv4 81187589 TCP > 10.132.253.51:shell->10.132.8.1:52954 (ESTABLISHED) > rsyslogd 29775 root 568u IPv4 81263960 TCP > 10.132.253.51:shell->10.132.8.1:58950 (ESTABLISHED) > rsyslogd 29775 root 570u IPv4 81275186 TCP > 10.132.253.51:shell->10.132.8.1:45307 (ESTABLISHED) > rsyslogd 29775 root 573u IPv4 81300023 TCP > 10.132.253.51:shell->10.132.8.1:49261 (ESTABLISHED) > rsyslogd 29775 root 574u IPv4 81412888 TCP > 10.132.253.51:shell->10.132.8.1:44849 (ESTABLISHED) > rsyslogd 29775 root 588u IPv4 81503100 TCP > 10.132.253.51:shell->10.132.8.1:51290 (ESTABLISHED) > rsyslogd 29775 root 591u IPv4 81559427 TCP > 10.132.253.51:shell->10.132.8.1:55079 (ESTABLISHED) > rsyslogd 29775 root 593u IPv4 81593574 TCP > 10.132.253.51:shell->10.132.8.1:51555 (ESTABLISHED) > rsyslogd 29775 root 595u IPv4 81624236 TCP > 10.132.253.51:shell->10.132.8.1:42867 (ESTABLISHED) > rsyslogd 29775 root 599u IPv4 81631713 TCP > 10.132.253.51:shell->10.132.8.1:39681 (ESTABLISHED) > rsyslogd 29775 root 601u IPv4 81641244 TCP > 10.132.253.51:shell->10.132.8.1:46118 (ESTABLISHED) > rsyslogd 29775 root 603u IPv4 82260661 TCP > 10.132.253.51:shell->10.132.8.1:51732 (ESTABLISHED) > rsyslogd 29775 root 684u IPv4 84358985 TCP > 10.132.253.51:shell->10.132.8.1:51261 (ESTABLISHED) > rsyslogd 29775 root 699u IPv4 84499197 TCP > 10.132.253.51:shell->10.132.8.1:39875 (ESTABLISHED) > rsyslogd 29775 root 701u IPv4 84557429 TCP > 10.132.253.51:shell->10.132.8.1:56892 (ESTABLISHED) > rsyslogd 29775 root 714u IPv4 86973034 TCP > 10.132.253.51:shell->10.132.8.1:47320 (ESTABLISHED) > rsyslogd 29775 root 823u IPv4 88591917 TCP > 10.132.253.51:shell->10.132.8.1:47729 (ESTABLISHED) > rsyslogd 29775 root 999u IPv4 90314222 TCP > 10.132.253.51:shell->10.132.8.1:34290 (ESTABLISHED) > rsyslogd 29775 root 1003u IPv4 125443032 TCP > 10.132.253.51:shell->10.132.8.1:46721 (ESTABLISHED) > > server# ssh 10.132.8.1 lsof -n -i :514 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > rsyslogd 1595 root 8u IPv4 59789 0t0 TCP > 10.132.8.1:45219->10.132.253.51:shell (ESTABLISHED) > > So you can see that the client has only 1 connection open, while the > server has many. Could the server be changed to close connections old > connections to a particular IP? I guess that would have issues for > NATing, or perhaps the server could just timeout the TCP connections > after a period of inactivity? > > Any ideas appreciated. > > cheers, > P??draig. > > For my own reference, these seem closely related: > http://kb.monitorware.com/post5056.html > http://bugzilla.adiscon.com/show_bug.cgi?id=190 Attempts to ameliorate these types of problems by kludging the server always end badly. I do not know anything about the RELP protocol, but it sounds like the client has a bug as well as possibly the server. Does it happen without RELP? If not, can you run without RELP? If not, you may need to get out the debugger. :) Cheers, Ken From P at draigBrady.com Tue Jul 6 15:16:24 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 14:16:24 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706130451.GI341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> Message-ID: <4C332CA8.8030301@draigBrady.com> On 06/07/10 14:04, Kenneth Marshall wrote: > Attempts to ameliorate these types of problems by kludging the > server always end badly. I do not know anything about the RELP > protocol, but it sounds like the client has a bug as well as > possibly the server. True. I've not looked into why the client is not tearing down connections, but in practice the clients can always just disappear. > Does it happen without RELP? If not, can > you run without RELP? If not, you may need to get out the > debugger. :) Unless it's enabled by default I've no mention of "relp" in my client configs. I'm using plain TCP I think. cheers, P?draig. From ktm at rice.edu Tue Jul 6 15:53:58 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 08:53:58 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C332CA8.8030301@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> Message-ID: <20100706135358.GK341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 02:16:24PM +0100, P?draig Brady wrote: > On 06/07/10 14:04, Kenneth Marshall wrote: > > Attempts to ameliorate these types of problems by kludging the > > server always end badly. I do not know anything about the RELP > > protocol, but it sounds like the client has a bug as well as > > possibly the server. > > True. I've not looked into why the client is not tearing down connections, > but in practice the clients can always just disappear. > > > Does it happen without RELP? If not, can > > you run without RELP? If not, you may need to get out the > > debugger. :) > > Unless it's enabled by default I've no mention of "relp" > in my client configs. I'm using plain TCP I think. > > cheers, > P?draig. > Are you certain you are not having a problem with some intervening firewall/IPtables network filtering. Poorly configured, they can cause the TCP network stack shutdown to fail because they block packets that should be passed for a correct shutdown. Regards, Ken From P at draigBrady.com Tue Jul 6 16:12:18 2010 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 06 Jul 2010 15:12:18 +0100 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <20100706135358.GK341@aart.is.rice.edu> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> Message-ID: <4C3339C2.6000800@draigBrady.com> On 06/07/10 14:53, Kenneth Marshall wrote: > Are you certain you are not having a problem with some > intervening firewall/IPtables network filtering. Poorly > configured, they can cause the TCP network stack shutdown > to fail because they block packets that should be passed > for a correct shutdown. Clients and server are on the same LAN. I've just done this on the 400+ clients: /etc/init.d/rsyslog restart There were about 20 stale connections left on the server. cheers, P?draig. From ktm at rice.edu Tue Jul 6 16:54:45 2010 From: ktm at rice.edu (Kenneth Marshall) Date: Tue, 6 Jul 2010 09:54:45 -0500 Subject: [rsyslog] TCP connections not being closed In-Reply-To: <4C3339C2.6000800@draigBrady.com> References: <4C33271C.70805@draigBrady.com> <20100706130451.GI341@aart.is.rice.edu> <4C332CA8.8030301@draigBrady.com> <20100706135358.GK341@aart.is.rice.edu> <4C3339C2.6000800@draigBrady.com> Message-ID: <20100706145445.GL341@aart.is.rice.edu> On Tue, Jul 06, 2010 at 03:12:18PM +0100, P?draig Brady wrote: > On 06/07/10 14:53, Kenneth Marshall wrote: > > Are you certain you are not having a problem with some > > intervening firewall/IPtables network filtering. Poorly > > configured, they can cause the TCP network stack shutdown > > to fail because they block packets that should be passed > > for a correct shutdown. > > Clients and server are on the same LAN. > I've just done this on the 400+ clients: > /etc/init.d/rsyslog restart > There were about 20 stale connections left on the server. > > cheers, > P?draig. > Are the clients/server running any type of firewall software or IPtables? Being on the same LAN will not prevent problems if they are running such software and it is misconfigured. Ken From tbergfeld at hq.adiscon.com Wed Jul 7 13:41:32 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 7 Jul 2010 13:41:32 +0200 Subject: [rsyslog] rsyslog 4.6.3 (v4-stable) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F73@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.6.3, a member of the v4-stable branch. This is a bug-fixing release which contains an improved testbench and a new configure option that permits to disable and enable an extended testbench. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article463.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-205.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From joe at joetify.com Wed Jul 7 18:29:31 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 09:29:31 -0700 Subject: [rsyslog] logging hostnames Message-ID: I have a couple services (haproxy and homegrown erlang stuff) that log directly to my rsyslog server. With these services I found that they log the reverse DNS rather than the hostname but with the logs that come from actual rsyslog clients they show up as one would expect with the real hostname, like what is returned from the "hostname" command. I've tried a few different things with "-x" and fromhost vs hostname and can't seem to get anything other than either an IP or a rDNS. Any suggestions? Do I need to include more information in the messages I send to rsyslog or perhaps adjust a config? Thanks. -Joe Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From david at lang.hm Wed Jul 7 19:27:37 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 10:27:37 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > I have a couple services (haproxy and homegrown erlang stuff) that log > directly to my rsyslog server. With these services I found that they log > the reverse DNS rather than the hostname but with the logs that come > from actual rsyslog clients they show up as one would expect with the > real hostname, like what is returned from the "hostname" command. I've > tried a few different things with "-x" and fromhost vs hostname and > can't seem to get anything other than either an IP or a rDNS. Any > suggestions? Do I need to include more information in the messages I > send to rsyslog or perhaps adjust a config? probably what is happening is that your server is not sending a properly formatted syslog message to rsyslog, so it is figuring out the info itself. try setting up a format with %raw% in it (the raw message that rsyslog receives) and look at it. it _should_ be in the format HH:MM:SS hostname syslogtag message I suspect that you are not getting the data in that format so rsyslog isn't recognising the hostname from the syslog message, so is having to fall back on IP address or reverse DNS. David Lang From joe at joetify.com Wed Jul 7 19:42:37 2010 From: joe at joetify.com (Joe Williams) Date: Wed, 7 Jul 2010 10:42:37 -0700 Subject: [rsyslog] logging hostnames In-Reply-To: References: Message-ID: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> David, Thanks, I think you're right: <14>Jul 2 21:25:38 HOSTNAME log message vs <149>customer:[<0.20341.5496>] IPADDR log message The latter is the message that our server is sending. -Joe On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > On Wed, 7 Jul 2010, Joe Williams wrote: > >> I have a couple services (haproxy and homegrown erlang stuff) that log >> directly to my rsyslog server. With these services I found that they log >> the reverse DNS rather than the hostname but with the logs that come >> from actual rsyslog clients they show up as one would expect with the >> real hostname, like what is returned from the "hostname" command. I've >> tried a few different things with "-x" and fromhost vs hostname and >> can't seem to get anything other than either an IP or a rDNS. Any >> suggestions? Do I need to include more information in the messages I >> send to rsyslog or perhaps adjust a config? > > probably what is happening is that your server is not sending a properly > formatted syslog message to rsyslog, so it is figuring out the info > itself. > > try setting up a format with %raw% in it (the raw message that rsyslog > receives) and look at it. > > it _should_ be in the format > > HH:MM:SS hostname syslogtag message > > I suspect that you are not getting the data in that format so rsyslog > isn't recognising the hostname from the syslog message, so is having to > fall back on IP address or reverse DNS. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Name: Joseph A. Williams Email: joe at joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe From pkrash at exegy.com Wed Jul 7 22:14:18 2010 From: pkrash at exegy.com (Paul Krash) Date: Wed, 7 Jul 2010 20:14:18 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error Message-ID: Hello! I have recently tried to parse syslog messages by %hostname% using the $RuleSet module. I have seen this work in Centos with no probs. Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf (from the all in one conf file found on Centos). I am getting the error that a module is missing? Is this an Ubuntu special, where a module is not compiled in the distro? I tried to compile from src, and got the same error. How can I get and enable the Module for rulesets? Thanks in advance, PKrash DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" error in /var/log/messages: Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 94 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 109 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 110 Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, line 112 Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] From david at lang.hm Thu Jul 8 03:21:52 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:21:52 -0700 (PDT) Subject: [rsyslog] logging hostnames In-Reply-To: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: On Wed, 7 Jul 2010, Joe Williams wrote: > David, > > Thanks, I think you're right: > > <14>Jul 2 21:25:38 HOSTNAME log message > > vs > > <149>customer:[<0.20341.5496>] IPADDR log message > > The latter is the message that our server is sending. yep, there's no timestamp or hostname in the message. This is a failry common way to malform syslog messages, and the standard thing to do is to use the current time as the timestamp and use the IP address (or reverse DNS lookup) as the hostname if you can get the srver to change it's log format you should start seeing the hostname correctly, short of this you have to settle for what you can get from the IP address. David Lang > -Joe > > > On Jul 7, 2010, at 10:27 AM, david at lang.hm wrote: > >> On Wed, 7 Jul 2010, Joe Williams wrote: >> >>> I have a couple services (haproxy and homegrown erlang stuff) that log >>> directly to my rsyslog server. With these services I found that they log >>> the reverse DNS rather than the hostname but with the logs that come >>> from actual rsyslog clients they show up as one would expect with the >>> real hostname, like what is returned from the "hostname" command. I've >>> tried a few different things with "-x" and fromhost vs hostname and >>> can't seem to get anything other than either an IP or a rDNS. Any >>> suggestions? Do I need to include more information in the messages I >>> send to rsyslog or perhaps adjust a config? >> >> probably what is happening is that your server is not sending a properly >> formatted syslog message to rsyslog, so it is figuring out the info >> itself. >> >> try setting up a format with %raw% in it (the raw message that rsyslog >> receives) and look at it. >> >> it _should_ be in the format >> >> HH:MM:SS hostname syslogtag message >> >> I suspect that you are not getting the data in that format so rsyslog >> isn't recognising the hostname from the syslog message, so is having to >> fall back on IP address or reverse DNS. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > Name: Joseph A. Williams > Email: joe at joetify.com > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Jul 8 03:24:17 2010 From: david at lang.hm (david at lang.hm) Date: Wed, 7 Jul 2010 18:24:17 -0700 (PDT) Subject: [rsyslog] $RuleSet parameter yields 3003 error In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Paul Krash wrote: > Hello! > > I have recently tried to parse syslog messages by %hostname% using the $RuleSet > module. I have seen this work in Centos with no probs. > > Now I have split out the rule set conf to /etc/rsyslog.d/50-default.conf > (from the all in one conf file found on Centos). > > I am getting the error that a module is missing? > > Is this an Ubuntu special, where a module is not compiled in the distro? I think it's most likely a problem where ubuntu just ships too old a version. It shipps 4.2.0 and I think rulesets were introduced later than that. > I tried to compile from src, and got the same error. did you uninstall the ubuntu default first? if not then you may be conflicting with it's modules (in /usr/lib/rsyslog where your modules probably went into usr/local/lib/rsyslog) David Lang > How can I get and enable the Module for rulesets? > > Thanks in advance, > > PKrash > > > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=10.04 > DISTRIB_CODENAME=lucid > DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS" > > error in /var/log/messages: > > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 94 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 109 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 110 > Jul 7 15:00:59 watcher rsyslogd-3003: invalid or yet-unknown config file > command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] > Jul 7 15:00:59 watcher rsyslogd: the last error occured in /etc/rsyslog.conf, > line 112 > Jul 7 15:00:59 watcher rsyslogd-2123: CONFIG ERROR: could not interpret master > config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2123 ] > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 8 09:37:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 8 Jul 2010 09:37:22 +0200 Subject: [rsyslog] logging hostnames References: <799E1B2F-22F3-4C6B-8E2B-6BF48EECAB6A@joetify.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F79@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 08, 2010 3:22 AM > To: rsyslog-users > Subject: Re: [rsyslog] logging hostnames > > On Wed, 7 Jul 2010, Joe Williams wrote: > > > David, > > > > Thanks, I think you're right: > > > > <14>Jul 2 21:25:38 HOSTNAME log message > > > > vs > > > > <149>customer:[<0.20341.5496>] IPADDR log message > > > > The latter is the message that our server is sending. > > yep, there's no timestamp or hostname in the message. This is a failry > common way to malform syslog messages, and the standard thing to do is > to > use the current time as the timestamp and use the IP address (or > reverse > DNS lookup) as the hostname > > if you can get the srver to change it's log format you should start > seeing > the hostname correctly, short of this you have to settle for what you > can > get from the IP address. David is absolutely right, but I would like to mention that a way to address such things (if you can use the IPADDR from the log message) is to write a custom message parser. Rsyslog has recently enhanced to provide this facility for solving such common malformed message issues. If you can not write one yourself, Adiscon offers to write message parsers for little money (provided the parser is contributed back to the project). As a side-note, my hope is that over time we will get a set of parsers that address most of the malformed messages we see... Rainer From pkrash at exegy.com Thu Jul 8 15:10:28 2010 From: pkrash at exegy.com (Paul Krash) Date: Thu, 8 Jul 2010 13:10:28 +0000 (UTC) Subject: [rsyslog] $RuleSet parameter yields 3003 error References: Message-ID: lang.hm> writes: > I think it's most likely a problem where ubuntu just ships too old a > version. It shipps 4.2.0 and I think rulesets were introduced later than > that. AHA! Thanks for the important tip! Confirmed, 4.2.0 is shipped with Ubuntu Lucid (10.04). 5.4 is shipped with Centos 5.4 The one instance that Centos is more modern than another distro... :-) > did you uninstall the ubuntu default first? if not then you may be > conflicting with it's modules (in /usr/lib/rsyslog where your modules > probably went into usr/local/lib/rsyslog) Yes, I did. I was depending on dpkg to purge all the files installed, possibly incorrect backout script from the Ubuntu package maintainer. I'll try from source again. Is there a specific ./configure option to include the ruleset module? Thanks in advance! PKrash From david at lang.hm Fri Jul 9 23:42:58 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 9 Jul 2010 14:42:58 -0700 (PDT) Subject: [rsyslog] spoofing module configuration Message-ID: in reading the spoofing module configuration it strikes me that the defaults can be significantly improved. the common case for needing to so spoofing is that you are spoofing the original source IP address so the current configuration equivalent commands $template spoofaddr, "%fromhost-ip%" $ActionUDPSpoofSourceNameTemplate spoofaddr could be made the default (or call it RSYSLOG_spoofaddr to keep from polluting the namespace) and the result would be far simpler for people to configure, becomging simply $modload omudpspoof $ActionUDPSpoofTargetHost server.example.com *.* :omudpspoof: it could be simplified even further if there was some way to specify the destination on the action line (like the @ and @@ functions do today, could we use @S@ to indicate spoofing?) changing the defaults should have no problems with backwards compatibility, adding/changing how the desitnation is specified could break backward compatibility, but this is a very new piece of functionality and the simplification may be worth it (what versions have this available?) David Lang From Jon.Combe at telindus.co.uk Mon Jul 12 15:55:41 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 14:55:41 +0100 Subject: [rsyslog] Last message repeated n times problem Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> I see from a previous post (http://lists.adiscon.net/pipermail/rsyslog/2010-February/003416.html) that this has come up before but there was no answer previously. I have rsyslogd (the latest, version 5.4) installed and running on a host configured to accept remote syslog messages. I have another server configured to send it's syslog messages to the host running rsyslog. I have rsyslog configured to store its entries in a MySQL database using the supplied rsyslog MySQL module. What I find is that most of the messages come through as expected. For example:- *************************** 3. row *************************** ID: 163941 CustomerID: NULL ReceivedAt: 2010-07-12 14:42:38 DeviceReportedTime: 2010-07-12 14:42:38 Facility: 10 Priority: 6 FromHost: 10.167.3.18 Message: pam_unix(sshd:session): session closed for user root NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: sshd[7809]: EventLogType: NULL GenericFileName: NULL SystemID: NULL However each time I get a "Last message repeated X times" message I see corrupted entries in the database:- *************************** 2. row *************************** ID: 163942 CustomerID: NULL ReceivedAt: 2010-07-12 14:43:15 DeviceReportedTime: 2010-07-12 14:43:15 Facility: 3 Priority: 3 FromHost: last Message: repeated 5 times NTSeverity: NULL Importance: NULL EventSource: NULL EventUser: NULL EventCategory: NULL EventID: NULL EventBinaryData: NULL MaxAvailable: NULL CurrUsage: NULL MinUsage: NULL MaxUsage: NULL InfoUnitID: 1 SysLogTag: message EventLogType: NULL GenericFileName: NULL SystemID: NULL You can see that the message text has been incorrectly split across the fields message, FromHost and SysLogTag. I have run a tcpdump and here are the two relevant packets:- 14:42:38.985098 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 111: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 97) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 69 Facility authpriv (10), Severity info (6) Msg: sshd[7809]: pam_unix(sshd:session): session closed for user root\012 0x0000: 3c38 363e 7373 6864 5b37 3830 395d 3a20 0x0010: 7061 6d5f 756e 6978 2873 7368 643a 7365 0x0020: 7373 696f 6e29 3a20 7365 7373 696f 6e20 0x0030: 636c 6f73 6564 2066 6f72 2075 7365 7220 0x0040: 726f 6f74 0a 0x0000: 4500 0061 0000 4000 3f11 20ec 0aa7 0312 E..a.. at .?....... 0x0010: 0aa7 0241 0202 0202 004d 5dc8 3c38 363e ...A.....M].<86> 0x0020: 7373 6864 5b37 3830 395d 3a20 7061 6d5f sshd[7809]:.pam_ 0x0030: 756e 6978 2873 7368 643a 7365 7373 696f unix(sshd:sessio 0x0040: 6e29 3a20 7365 7373 696f 6e20 636c 6f73 n):.session.clos 0x0050: 6564 2066 6f72 2075 7365 7220 726f 6f74 ed.for.user.root 0x0060: 0a . 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp sum ok] SYSLOG, length: 34 Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 0x0020: 730a 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 E..>.. at .?.!..... 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e ...A.....*.D<27> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 last.message.rep 0x0030: 6561 7465 6420 3520 7469 6d65 730a eated.5.times. In both cases it seems to me that the IP address of the sender has been included in the packet (0a a7 03 12) which translates as the IP 10.167.3.18 which is the sender. Is this an rsyslog issue? Is it a known problem? Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 16:50:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 16:50:10 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> [snip] Well, as you can see: > 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > sum ok] SYSLOG, length: 34 > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > 0x0020: 730a > 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > E..>.. at .?.!..... > 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > ...A.....*.D<27> > 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > last.message.rep > 0x0030: 6561 7465 6420 3520 7469 6d65 730a > eated.5.times. > the message is totally malformed. > In both cases it seems to me that the IP address of the sender has been > included in the packet (0a a7 03 12) which translates as the IP > 10.167.3.18 which is the sender. > > Is this an rsyslog issue? Is it a known problem? The sender must be fixed to emit correct format. It is a known problem with some senders (sysklogd namely), but we have not yet provided a work-around for it because that causes unnecessary performance loss on the rsyslog side. However, thinking now about it, a special message parser module could be used to solve that situation. That way, only those that actually have this problem would need to bear the cost of the work-around. Let me think a bit about this... > Thanks. > Jon. > > This email is private No, it isn't -- it was sent to a public mailing list and is probably archived on a myriad of sites by now. Please note that as of the ToS of the mailing list, we do not accept any liability. It would be decent to tell your mail folks to turn off this disclaimer for list-directed mail. Thanks! Rainer > and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Jon.Combe at telindus.co.uk Mon Jul 12 17:19:13 2010 From: Jon.Combe at telindus.co.uk (Jon Combe) Date: Mon, 12 Jul 2010 16:19:13 +0100 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > >the message is totally malformed. Rainer, Thanks for the reply. I'm no expert on the format I'm afraid but I have looked at the RFC http://tools.ietf.org/search/rfc5424 You're correct that the sender is using sysklogd. Would you be able to tell me how it is malformed? I can see that something (tcpdump?) has parsed the message here:- Facility daemon (3), Severity error (3) Msg: last message repeated 5 times\012 Reading the RFC it says the header should be PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID Where pri are enclosed in < and > (which is the <27> in the above), followed by a space and then the version, which can be NIL, followed by timestamp (which can also be NIL), followed by hostname (also NIL permitted), APP NAME (also NIL is permitted), PROCID (also NIL permitted), MSGID (also NIL permitted) and then after the header is the actual message. So my understanding of the RFC is that the only field required in the header is , which is present. I'm not clear on whether the spaces are required or not or only if the optional fields are present. The only difference I see between the valid packet I sent and this one is that the valid packet has "sshd[7809]:" at the start of the message - is this the APP-NAME field from the header perhaps? I realise from the RFC that many of these fields are listed as SHOULD be provided Thanks. Jon. This email is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information contained in it. We use reasonable endeavours to virus scan all emails leaving the Company but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communications through our network is reserved by us. Telindus Limited is a company registered in England and Wales under number 02020395. The registered office is Centurion, Riverside Way, Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. From rgerhards at hq.adiscon.com Mon Jul 12 17:22:43 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Jul 2010 17:22:43 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F95@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Jon Combe > Sent: Monday, July 12, 2010 5:19 PM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 > > You're correct that the sender is using sysklogd. Would you be able to > tell me how it is malformed? I can see that something (tcpdump?) has > parsed the message here:- > > Facility daemon (3), Severity error (3) > Msg: last message repeated 5 times\012 > > Reading the RFC it says the header should be > > PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID > > Where pri are enclosed in < and > (which is the <27> in the above), > followed by a space and then the version, which can be NIL, followed by > timestamp (which can also be NIL), followed by hostname (also NIL > permitted), APP NAME (also NIL is permitted), PROCID (also NIL > permitted), MSGID (also NIL permitted) and then after the header is the > actual message. > > So my understanding of the RFC is that the only field required in the > header is , which is present. I'm not clear on whether the spaces > are required or not or only if the optional fields are present. Spaces are required, VERSION can not be NILVALUE and NILVALUE is defined as "-". ;) Rainer > > The only difference I see between the valid packet I sent and this one > is that the valid packet has "sshd[7809]:" at the start of the message > - is this the APP-NAME field from the header perhaps? I realise from > the RFC that many of these fields are listed as SHOULD be provided > > Thanks. > Jon. > > This email is private and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this email or any information contained in it. We use reasonable > endeavours to virus scan all emails leaving the Company but no warranty > is given that this email and any attachments are virus free. You should > undertake your own virus checking. The right to monitor email > communications through our network is reserved by us. > > Telindus Limited is a company registered in England and Wales under > number 02020395. The registered office is Centurion, Riverside Way, > Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From chs7490 at gmail.com Mon Jul 12 23:33:36 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 06:33:36 +0900 Subject: [rsyslog] kernel messages on usb flash drive Message-ID: Hi everyone I want to write kernel meesage,which is generally recorded at /var/log/messages, at usb flash memory. It goes well when the kernel mesage recording file is specified on hard disk, but it does not on usb flash memory. What I have worked on is as below. -- >mkdir /var/log/hm >mount /dev/sdb /var/log/hm (I checked that usb flash memory is mounted.) >vi /etc/rsyslog.conf I changed *.info;mail.none;authpriv.none;cron.none /var/log/messages to *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages -- When the kernel message recording place is specified on hard disk (such as /var/log/messages2), it records well. However, it does not record on usb flash memory Please let me know if there is something that I have to revise or add thanks in advance, Cheon. From david at lang.hm Mon Jul 12 23:52:05 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 14:52:05 -0700 (PDT) Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: On Tue, 13 Jul 2010, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- >> mkdir /var/log/hm > >> mount /dev/sdb /var/log/hm > (I checked that usb flash memory is mounted.) > >> vi /etc/rsyslog.conf > > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory when you say it doesn't record on the USB flash, what is happening? do you get errors or do you find that the data is still written to the hard drive? My guess is that it's being written to the hard drive because the USB stick is no mounted yet when rsyslog starts, so the file that it has open is on the hard drive and not the flash drive. you need to start rsyslog after the flash drive is mounted, and then stop rsyslog before you unmount it to make sure the data is written to it. David Lang From rory at ooma.com Mon Jul 12 23:43:05 2010 From: rory at ooma.com (Rory Toma) Date: Mon, 12 Jul 2010 14:43:05 -0700 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: <4C3B8C69.6080001@ooma.com> What filesystem is on your USB drive? If you just plugged something in, it's likely FAT32, and you may be seeing performance issues if you have a lot of messages. I assume you can write files by hand to this drive? On 7/12/10 2:33 PM, Hongseok Cheon wrote: > Hi everyone > > > I want to write kernel meesage,which is generally recorded at > /var/log/messages, at usb flash memory. > It goes well when the kernel mesage recording file is specified on hard > disk, but it does not on usb flash memory. > > What I have worked on is as below. > > -- > >> mkdir /var/log/hm >> > >> mount /dev/sdb /var/log/hm >> > (I checked that usb flash memory is mounted.) > > >> vi /etc/rsyslog.conf >> > I changed > *.info;mail.none;authpriv.none;cron.none /var/log/messages > to > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > -- > > When the kernel message recording place is specified on hard disk (such as > /var/log/messages2), it records well. However, it does not record on usb > flash memory > > Please let me know if there is something that I have to revise or add > > thanks in advance, > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Jul 13 00:25:21 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 15:25:21 -0700 (PDT) Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 12 Jul 2010, Rainer Gerhards wrote: > [snip] > Well, as you can see: >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp >> sum ok] SYSLOG, length: 34 >> Facility daemon (3), Severity error (3) >> Msg: last message repeated 5 times\012 >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 >> 0x0020: 730a >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 >> E..>.. at .?.!..... >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e >> ...A.....*.D<27> >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 >> last.message.rep >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a >> eated.5.times. >> > the message is totally malformed. > >> In both cases it seems to me that the IP address of the sender has been >> included in the packet (0a a7 03 12) which translates as the IP >> 10.167.3.18 which is the sender. >> >> Is this an rsyslog issue? Is it a known problem? > > The sender must be fixed to emit correct format. It is a known problem with > some senders (sysklogd namely), but we have not yet provided a work-around > for it because that causes unnecessary performance loss on the rsyslog side. > However, thinking now about it, a special message parser module could be used > to solve that situation. That way, only those that actually have this problem > would need to bear the cost of the work-around. Let me think a bit about > this... if I'm understanding this correctly the filter seems like it would be pretty simple. accept the message as being potentially well formed IFF (if and only if) it meets the following criteria. 1. has a valid tag 2. characters 4, 7, 16 are ' ' 3. characters 10,13 are ':' this isn't absolute proof that this is a valid timestamp, but it's pretty good and very quick to check in C. if not, it can't possibly be a valid message, set the timestamp (current time) and hostname (based on the source IP in the packet). then check the word staring at position 17 to see if it is made up of characters that mean it could be a hostname (a-zA-Z0-9.-) if not, it can't possibly be a valid hostname, set the hostname (based on the source IP in the packet) now, if something passes this test but has other garbage in the hostname field, that will take system specific fixups. In this case, after the tests I describe you would still have the syslog tag of 'last' and the message 'message repeated 5 times' that would need to be fixed by a filter that checked for 'last message repeated' and put it all in the message (filling in a dummy or blank syslog tag) there are unfortunantly a bunch of such filters that are needed. now that they are easy to create we can hopefully get a bunch of them done so that only the people who need them bother with them. one question on stackable filters. how much overhead is there in putting the tests in separate filters as opposed to in one filter? for example, take 3 tests 1. 'message forwarded from hostname' -> hostname 2. 'last message repeated' -> move to message body 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN what would the impact be of having each of these as separate filters vs one filter with configurable tests? (i.e. is there a noticable overhead in stacking the filters) David Lang >> Thanks. >> Jon. >> >> This email is private > > No, it isn't -- it was sent to a public mailing list and is probably archived > on a myriad of sites by now. Please note that as of the ToS of the mailing > list, we do not accept any liability. It would be decent to tell your mail > folks to turn off this disclaimer for list-directed mail. Thanks! > > Rainer > >> and may be confidential and is for the intended >> recipient only. If misdirected, please notify us by telephone and >> confirm that it has been deleted from your system and any copies >> destroyed. If you are not the intended recipient you are strictly >> prohibited from using, printing, copying, distributing or disseminating >> this email or any information contained in it. We use reasonable >> endeavours to virus scan all emails leaving the Company but no warranty >> is given that this email and any attachments are virus free. You should >> undertake your own virus checking. The right to monitor email >> communications through our network is reserved by us. >> >> Telindus Limited is a company registered in England and Wales under >> number 02020395. The registered office is Centurion, Riverside Way, >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From sean at conman.org Tue Jul 13 02:50:37 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 20:50:37 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> Message-ID: <20100713005037.GB3089@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > But my overall assumption is that we stick what we currently have, but > > extend > > it in a way that provides scoping and do so in a way the provides as > > many > > usable interim steps as possible (without adding major work just for > > those > > steps). I hope this covers the spirit of our discussion. > > I tried very hard the past days to get a grammar together that is an > evolution from what we currently have. I did not yet succeed fully (thus I > have no formal grammar to show), but I think I made some progress. > > So please let me come back and present a config sample: > > http://download.rsyslog.com/rainerscript2_rsyslog.conf > > It actually is three configs in one file > > a) a standard rsyslog.conf in mixed new and old format > b) a standard rsyslog.conf in new format, only > c) a complex rsyslog.conf (not really working) in new format > > [partitioned by (just) comments] > > Note that being an evolution, any currently existing rsyslog.conf would also > be a valid new conf (via the *same* parser). I have not thought out the full > semantics and thousand other things that need to be thought of -- this > actually opened up a can of worms ;) However, I find the proposed format > seems to be a good compromise between the need to preserve and the need to > move on, and between the need for simplicity and the need for power. > > As such, before I invest even more time into that format, I'd like to get > some feedback on what you folks think ;) Okay, take number two. After reading the various comments about my last message (using Lua---rejected for various reasons) what it sounds like you want is a more declaritive syntax---a mapping of input to output. Have you considered a syntax like Haskel or Erlang? There functions are declared by pattern matching input parameters and thus, you tend not to see many (if any) if statements (okay, I checked a sizable Erlang program I have, and it does use 'case' in a few spots, but not many). The original syslog.conf file has what I mean to some degree, with a syntax like: mail.* @maillogprocessinghost mail.warn /some/log/file cron.* /some/other/logfile Since most of what you want to do is based off the input message, how about extending this style of syntax to more than just the facility/priority pair? Since host, program, facility, priority and message are typically the most interesting fields (at least, in my experience), perhaps a syntax that includes matching those as well would work. Something like: # order is host, program, facility, priority, msg ( * , * , mail , (warn err crit alert emerg) , *) => file("/var/log/mail.log") # the above is the same as the traditional syslog syntax of # mail.warn /var/log/mail.log # log cron messages to logs based off the hostname ( * , * , cron , * , * ) => file("/var/log/{host}/cron.log") # define a list of values routers = { ip1 ip2 ip3 ip4 } # use said list in a pattern matching rule # the msg field uses a regex ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*Neighbor Down)/ ) => email( ... ) ( {routers} , * , local2 , * , /(OSPF%-5%-ADJCHG.*LOADING to FULL)/ ) => email( ... ) # feed SSH failed logins to external program, to block repeated attemts # ~"blah" will check for the existance of "blah" somewhere in the string # log all SSH information to a file ( localhost , sshd , auth2 , info , ~"Fail password for" ) => exec( ... ) ( * , sshd , auth2 , * , * ) => file( ... ) # auth messages go offsite, never locally, everything else # gets logged locally, except for *.debug, which gets relayed # to development machines for processing ( * , * , auth , * , * ) => relay(secure) ( * , * , !auth , !debug , * ) => file(...) ( * , * , !auth , debug , * ) => relay(dev) Seldom used fields can be explicitely checked ( * , * , * , * , * , relay = A) => ... No if statements in sight, just a series of patterns and actions when said pattern is matched. You also have "variables" and a way to reference them, and I left the syntax for actions vague intentionally. -spc (Just an idea ... ) From sean at conman.org Tue Jul 13 03:09:26 2010 From: sean at conman.org (Sean Conner) Date: Mon, 12 Jul 2010 21:09:26 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra> <9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> Message-ID: <20100713010926.GC3089@brevard.conman.org> It was thus said that the Great Jon Combe once stated: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > > >the message is totally malformed. > > Rainer, > > Thanks for the reply. > > I'm no expert on the format I'm afraid but I have looked at the RFC > http://tools.ietf.org/search/rfc5424 The format being sent is documented in RFC-3164, in which the only mandatory field is PRI---it's up the the receiving end to make sense of the rest of the message. It appears that in your case rsyslogd is mis-interpreting the incoming message. -spc From david at lang.hm Tue Jul 13 06:29:45 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 12 Jul 2010 21:29:45 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713005037.GB3089@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: On Mon, 12 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >>> But my overall assumption is that we stick what we currently have, but >>> extend >>> it in a way that provides scoping and do so in a way the provides as >>> many >>> usable interim steps as possible (without adding major work just for >>> those >>> steps). I hope this covers the spirit of our discussion. >> >> I tried very hard the past days to get a grammar together that is an >> evolution from what we currently have. I did not yet succeed fully (thus I >> have no formal grammar to show), but I think I made some progress. >> >> So please let me come back and present a config sample: >> >> http://download.rsyslog.com/rainerscript2_rsyslog.conf >> >> It actually is three configs in one file >> >> a) a standard rsyslog.conf in mixed new and old format >> b) a standard rsyslog.conf in new format, only >> c) a complex rsyslog.conf (not really working) in new format >> >> [partitioned by (just) comments] >> >> Note that being an evolution, any currently existing rsyslog.conf would also >> be a valid new conf (via the *same* parser). I have not thought out the full >> semantics and thousand other things that need to be thought of -- this >> actually opened up a can of worms ;) However, I find the proposed format >> seems to be a good compromise between the need to preserve and the need to >> move on, and between the need for simplicity and the need for power. >> >> As such, before I invest even more time into that format, I'd like to get >> some feedback on what you folks think ;) > > Okay, take number two. > > After reading the various comments about my last message (using > Lua---rejected for various reasons) what it sounds like you want is a more > declaritive syntax---a mapping of input to output. Have you considered a > syntax like Haskel or Erlang? There functions are declared by pattern > matching input parameters and thus, you tend not to see many (if any) if > statements (okay, I checked a sizable Erlang program I have, and it does use > 'case' in a few spots, but not many). > > The original syslog.conf file has what I mean to some degree, with a > syntax like: > > mail.* @maillogprocessinghost > mail.warn /some/log/file > cron.* /some/other/logfile > > Since most of what you want to do is based off the input message, how > about extending this style of syntax to more than just the facility/priority > pair? Since host, program, facility, priority and message are typically the > most interesting fields (at least, in my experience), perhaps a syntax that > includes matching those as well would work. Something like: this is the approach that rsyslog took with the old config file. the problem is that we are now getting capibilities that can't easily be represented this way David Lang From chs7490 at gmail.com Tue Jul 13 06:49:34 2010 From: chs7490 at gmail.com (Hongseok Cheon) Date: Tue, 13 Jul 2010 13:49:34 +0900 Subject: [rsyslog] kernel messages on usb flash drive In-Reply-To: References: Message-ID: 2010/7/13 > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > Hi everyone > > > > > > I want to write kernel meesage,which is generally recorded at > > /var/log/messages, at usb flash memory. > > It goes well when the kernel mesage recording file is specified on hard > > disk, but it does not on usb flash memory. > > > > What I have worked on is as below. > > > > -- > >> mkdir /var/log/hm > > > >> mount /dev/sdb /var/log/hm > > (I checked that usb flash memory is mounted.) > > > >> vi /etc/rsyslog.conf > > > > I changed > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > to > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > -- > > > > When the kernel message recording place is specified on hard disk (such > as > > /var/log/messages2), it records well. However, it does not record on usb > > flash memory > > when you say it doesn't record on the USB flash, what is happening? > do you > get errors or do you find that the data is still written to the hard > drive? > ==> I can see following message through 'dmesg' cmd. SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts i don't know what the message means. I cannot find the data on the hard drive. > > My guess is that it's being written to the hard drive because the USB > stick is no mounted yet when rsyslog starts, so the file that it has open > is on the hard drive and not the flash drive. > you need to start rsyslog after the flash drive is mounted, and then stop > rsyslog before you unmount it to make sure the data is written to it. > ==> after the usb stick is mounted, i restarted rsyslog. But nothing is changed T.T when i try to write kenel messages to usb flash drive, I can see kernel messages using 'dmesg' cmd, but they are not written to the flash drive or hard drive. Cheon. From sean at conman.org Tue Jul 13 08:27:22 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 02:27:22 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> Message-ID: <20100713062722.GA3959@brevard.conman.org> It was thus said that the Great david at lang.hm once stated: > On Mon, 12 Jul 2010, Sean Conner wrote: > > > Since most of what you want to do is based off the input message, how > > about extending this style of syntax to more than just the facility/priority > > pair? Since host, program, facility, priority and message are typically the > > most interesting fields (at least, in my experience), perhaps a syntax that > > includes matching those as well would work. Something like: > > > > this is the approach that rsyslog took with the old config file. > > the problem is that we are now getting capibilities that can't easily be > represented this way Such as? That's one reason why I took the approach I did in my syslogd (which uses Lua)---if the configuration file is going to be complex anyway, why not just write a syslog filter in Lua and be done with it? I know why Rainer is rejecting Lua (and by extension, even his own RanierScript), but the current method is obviously not working, because the topic keeps coming up as mroe and more use cases come into being. So perhaps the question to ask is not what the configuration file looks like, but rather, what, exactly, is rsyslogd expected to do? Just route messages from sources to destinations and nothing more? Or do people want logic in the processing? (My guess is "Yes"---and that's what is causing problems with the configuration file). -spc From rgerhards at hq.adiscon.com Tue Jul 13 09:08:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:08:50 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com><35171DEA6A652C41B8C22EA89AE9E6F49908182291@tuk1mx3.telindus.intra> <20100713010926.GC3089@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> > The format being sent is documented in RFC-3164, in which the only > mandatory field is PRI No, not even PRI ;) > ---it's up the the receiving end to make sense of > the > rest of the message. It appears that in your case rsyslogd is > mis-interpreting the incoming message. Technically speaking, RFC3164 is not a standard, because it is an informational document. I have elaborated about its implications in: http://www.rsyslog.com/doc-syslog_parsing.html So if we follow your view, we simply need to accept anything as being valid, and as such we do never know which information is contained inside a message (just ask yourself the question how you know what the sender meant in this case. Message is "hostname junk" Was this intended to mean MSG = "hostname junk" or was it intended to mean hostname="hostname", MSG="junk" -- or something else? As I already wrote, we can potentially handle the "last message repeated ..." case, but only at a performance toll (we need to do a full message compare). I do not consider this acceptable as a general case. But crafting a parser module probably makes a lot of sense (thankfully we have this capability now). Rainer From david at lang.hm Tue Jul 13 09:10:57 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 00:10:57 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100713062722.GA3959@brevard.conman.org> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com> <20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: On Tue, 13 Jul 2010, Sean Conner wrote: > It was thus said that the Great david at lang.hm once stated: >> On Mon, 12 Jul 2010, Sean Conner wrote: >> >>> Since most of what you want to do is based off the input message, how >>> about extending this style of syntax to more than just the facility/priority >>> pair? Since host, program, facility, priority and message are typically the >>> most interesting fields (at least, in my experience), perhaps a syntax that >>> includes matching those as well would work. Something like: >> >> >> >> this is the approach that rsyslog took with the old config file. >> >> the problem is that we are now getting capibilities that can't easily be >> represented this way > > Such as? > > That's one reason why I took the approach I did in my syslogd (which uses > Lua)---if the configuration file is going to be complex anyway, why not just > write a syslog filter in Lua and be done with it? I know why Rainer is > rejecting Lua (and by extension, even his own RanierScript), but the current > method is obviously not working, because the topic keeps coming up as mroe > and more use cases come into being. > > So perhaps the question to ask is not what the configuration file looks > like, but rather, what, exactly, is rsyslogd expected to do? Just route > messages from sources to destinations and nothing more? Or do people want > logic in the processing? (My guess is "Yes"---and that's what is causing > problems with the configuration file). if-then-else logic in the processing, sending things to the same output based on different logic, subsets of rules that only get evaluated if earlier conditions are true, allowing some outputs to queue while not others. just as a few of them earlier in this thread some of the examples that Rainer gave give some hints of this. David Lang From rgerhards at hq.adiscon.com Tue Jul 13 09:16:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:16:32 +0200 Subject: [rsyslog] kernel messages on usb flash drive References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F98@GRFEXC.intern.adiscon.com> All I can say is that rsyslog just calls the usual open() API. You may run it in debug mode to see what the OS returns when trying to open the file on the USB drive. From rsyslog's POV, all files are equal, no matter where they reside. Of course, this means the filesystem must be mounted (as David pointed out). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Hongseok Cheon > Sent: Tuesday, July 13, 2010 6:50 AM > To: rsyslog-users > Subject: Re: [rsyslog] kernel messages on usb flash drive > > 2010/7/13 > > > On Tue, 13 Jul 2010, Hongseok Cheon wrote: > > > > > Hi everyone > > > > > > > > > I want to write kernel meesage,which is generally recorded at > > > /var/log/messages, at usb flash memory. > > > It goes well when the kernel mesage recording file is specified on > hard > > > disk, but it does not on usb flash memory. > > > > > > What I have worked on is as below. > > > > > > -- > > >> mkdir /var/log/hm > > > > > >> mount /dev/sdb /var/log/hm > > > (I checked that usb flash memory is mounted.) > > > > > >> vi /etc/rsyslog.conf > > > > > > I changed > > > *.info;mail.none;authpriv.none;cron.none /var/log/messages > > > to > > > *.info;mail.none;authpriv.none;cron.none /var/log/hm/messages > > > -- > > > > > > When the kernel message recording place is specified on hard disk > (such > > as > > > /var/log/messages2), it records well. However, it does not record > on usb > > > flash memory > > > > when you say it doesn't record on the USB flash, what is happening? > > > > > > do you > > get errors or do you find that the data is still written to the hard > > drive? > > > ==> > I can see following message through 'dmesg' cmd. > SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts > i don't know what the message means. > > I cannot find the data on the hard drive. > > > > > > > > > My guess is that it's being written to the hard drive because the USB > > stick is no mounted yet when rsyslog starts, so the file that it has > open > > is on the hard drive and not the flash drive. > > > > you need to start rsyslog after the flash drive is mounted, and then > stop > > rsyslog before you unmount it to make sure the data is written to it. > > > > ==> > after the usb stick is mounted, i restarted rsyslog. But nothing is > changed > T.T > > > when i try to write kenel messages to usb flash drive, > I can see kernel messages using 'dmesg' cmd, but they are not written > to > the flash drive or hard drive. > > > Cheon. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:31:32 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:31:32 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 9:11 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great david at lang.hm once stated: > >> On Mon, 12 Jul 2010, Sean Conner wrote: > >> > >>> Since most of what you want to do is based off the input message, > how > >>> about extending this style of syntax to more than just the > facility/priority > >>> pair? Since host, program, facility, priority and message are > typically the > >>> most interesting fields (at least, in my experience), perhaps a > syntax that > >>> includes matching those as well would work. Something like: > >> > >> > >> > >> this is the approach that rsyslog took with the old config file. > >> > >> the problem is that we are now getting capibilities that can't > easily be > >> represented this way > > > > Such as? > > > > That's one reason why I took the approach I did in my syslogd (which > uses > > Lua)---if the configuration file is going to be complex anyway, why > not just > > write a syslog filter in Lua and be done with it? I know why Rainer > is > > rejecting Lua (and by extension, even his own RanierScript), but the > current > > method is obviously not working, because the topic keeps coming up as > mroe > > and more use cases come into being. > > > > So perhaps the question to ask is not what the configuration file > looks > > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > > messages from sources to destinations and nothing more? Or do people > want > > logic in the processing? (My guess is "Yes"---and that's what is > causing > > problems with the configuration file). > > if-then-else logic in the processing, sending things to the same output > based on different logic, subsets of rules that only get evaluated if > earlier conditions are true, allowing some outputs to queue while not > others. > > just as a few of them > > earlier in this thread some of the examples that Rainer gave give some > hints of this. To add some of the less obvious things: support for multiple listeners going to different outputs, in an easy to use way. Support for explicitely specified concurrency (or serialization) for high-speed environments, support for different queues, and tying of different queues to different object classes (inputs, message processors, actions). Flexibility to support configuration for even unexpected plugins that we may not even know about (because some third party writes them and never publishes them). But I begin to agree that we, the community, as a whole have very different needs. I have gotten the impression that it is probably a good idea to stop the current effort and re-start it with a requirements definition. I have tried to digest the discussions on config format we had over the year, but sometimes it looks like the only consensus we have is that the current format is ugly and hard to use. The solutions are very wide-ranging. I have even briefly looked at syslog-ng, and seen a lot of the pain again that makes me dislike that format (but I'll probably still have a closer look and will try to write up my detailed position why I do not find buying into this format is a good idea). All in all, I think the best way to re-start our thinking about the config format is to set up a web site where we gather user feedback on a) what problems they have with the config format (not what they just dislike, but real problems, an example From myself: it is nearly impossible to get the sequence right To bind inputs to the right rulesets AND use ruleset inclusion) b) which alternatives they see With all this being on a web site, it may be possible to craft a better decision in 6 to 9 month, assuming we were able to gain sufficient feedback during that time. An alternative would be to create a config parser interface, so that everybody could code up his favorite config language. However, this seems to be impractical, as many of the ideas floating around (Lua, syslog-ng style) require not just different config parsers, but a different rsyslog processing core as well. Obviously a complete rewrite in the case of Lua, less for syslog-ng, but still considerate. For the syslog-ng style we would need to create named filters, something that I really find questionable. Also, we would need to add an interim layer between inputs and rulesets, something that eats performance. In any case, this are not config-parser only changes. Of course, I could just pick one of the alternatives. However, it doesn't make sense to invest a couple of month to do the config system "right", if we know that a lot of folks will still be unhappy after we have done this. Rainer From rgerhards at hq.adiscon.com Tue Jul 13 09:40:25 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:40:25 +0200 Subject: [rsyslog] Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 12:25 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > On Mon, 12 Jul 2010, Rainer Gerhards wrote: > > > [snip] > > Well, as you can see: > >> 14:43:15.483698 88:43:e1:41:15:3f > 00:0c:29:a2:86:f1, ethertype > IPv4 > >> (0x0800), length 76: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], > >> proto: UDP (17), length: 62) 10.167.3.18.514 > 10.167.2.65.514: [udp > >> sum ok] SYSLOG, length: 34 > >> Facility daemon (3), Severity error (3) > >> Msg: last message repeated 5 times\012 > >> 0x0000: 3c32 373e 6c61 7374 206d 6573 7361 6765 > >> 0x0010: 2072 6570 6561 7465 6420 3520 7469 6d65 > >> 0x0020: 730a > >> 0x0000: 4500 003e 0000 4000 3f11 210f 0aa7 0312 > >> E..>.. at .?.!..... > >> 0x0010: 0aa7 0241 0202 0202 002a df44 3c32 373e > >> ...A.....*.D<27> > >> 0x0020: 6c61 7374 206d 6573 7361 6765 2072 6570 > >> last.message.rep > >> 0x0030: 6561 7465 6420 3520 7469 6d65 730a > >> eated.5.times. > >> > > the message is totally malformed. > > > >> In both cases it seems to me that the IP address of the sender has > been > >> included in the packet (0a a7 03 12) which translates as the IP > >> 10.167.3.18 which is the sender. > >> > >> Is this an rsyslog issue? Is it a known problem? > > > > The sender must be fixed to emit correct format. It is a known > problem with > > some senders (sysklogd namely), but we have not yet provided a work- > around > > for it because that causes unnecessary performance loss on the > rsyslog side. > > However, thinking now about it, a special message parser module could > be used > > to solve that situation. That way, only those that actually have this > problem > > would need to bear the cost of the work-around. Let me think a bit > about > > this... > > if I'm understanding this correctly the filter seems like it would be > pretty simple. > > accept the message as being potentially well formed IFF (if and only > if) > it meets the following criteria. > > 1. has a valid tag > > 2. characters 4, 7, 16 are ' ' > > 3. characters 10,13 are ':' > > this isn't absolute proof that this is a valid timestamp, but it's > pretty > good and very quick to check in C. > That's definitely a way to go. Unfortunately, pmrfc3164 already does a lot of guesswork for other cases where things are malformed (just as an example, there are devices that put an additional space in front of the date, invalidating all the offsets you give...). The problem is that in a strict sense, RFC3164 does not demand anything. So there are lots of things that are mutually exclusive. In the current parser, I try to weigh importance of occurrence and performance. So the most prominent cases are probably handled, conflicting less common cases not. "last message repeated n times" is pretty useless, so it has low priority. I have also a "performance filter" on my mind, that means I do only those things that seem reasonable. However, the whole idea of introducing message parsers was to solve exactly that problem. So I think it is natural to write a new message parser rather than try (and probably fail) to fiddle even more with the 3164 parser, which already is overwhelmed with guesswork. For "last message...", I would need to do a full string compare, anything else would be incompatible with the already-existing guesswork in pmrfc3164. Rainer > if not, it can't possibly be a valid message, set the timestamp > (current > time) and hostname (based on the source IP in the packet). > > then check the word staring at position 17 to see if it is made up of > characters that mean it could be a hostname (a-zA-Z0-9.-) > > if not, it can't possibly be a valid hostname, set the hostname (based > on > the source IP in the packet) > > > now, if something passes this test but has other garbage in the > hostname > field, that will take system specific fixups. In this case, after the > tests I describe you would still have the syslog tag of 'last' and the > message 'message repeated 5 times' > > that would need to be fixed by a filter that checked for 'last message > repeated' and put it all in the message (filling in a dummy or blank > syslog tag) > > there are unfortunantly a bunch of such filters that are needed. now > that > they are easy to create we can hopefully get a bunch of them done so > that > only the people who need them bother with them. > > one question on stackable filters. > > how much overhead is there in putting the tests in separate filters > as > opposed to in one filter? > > for example, take 3 tests > > 1. 'message forwarded from hostname' -> hostname > > 2. 'last message repeated' -> move to message body > > 3. 'hostname : %PIXN-NNNN' -> syslogtag= %PIXN-NNNN > > what would the impact be of having each of these as separate filters vs > one filter with configurable tests? (i.e. is there a noticable overhead > in > stacking the filters) > > David Lang > > >> Thanks. > >> Jon. > >> > >> This email is private > > > > No, it isn't -- it was sent to a public mailing list and is probably > archived > > on a myriad of sites by now. Please note that as of the ToS of the > mailing > > list, we do not accept any liability. It would be decent to tell your > mail > > folks to turn off this disclaimer for list-directed mail. Thanks! > > > > Rainer > > > >> and may be confidential and is for the intended > >> recipient only. If misdirected, please notify us by telephone and > >> confirm that it has been deleted from your system and any copies > >> destroyed. If you are not the intended recipient you are strictly > >> prohibited from using, printing, copying, distributing or > disseminating > >> this email or any information contained in it. We use reasonable > >> endeavours to virus scan all emails leaving the Company but no > warranty > >> is given that this email and any attachments are virus free. You > should > >> undertake your own virus checking. The right to monitor email > >> communications through our network is reserved by us. > >> > >> Telindus Limited is a company registered in England and Wales under > >> number 02020395. The registered office is Centurion, Riverside Way, > >> Watchmoor Park, Blackwater Valley Road, Camberley, Surrey, GU15 3YA. > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 09:44:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 09:44:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org> <20100713062722.GA3959@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9B@GRFEXC.intern.adiscon.com> > So perhaps the question to ask is not what the configuration file > looks > like, but rather, what, exactly, is rsyslogd expected to do? Just > route > messages from sources to destinations and nothing more? Or do people > want > logic in the processing? (My guess is "Yes"---and that's what is > causing > problems with the configuration file). You still miss the point that performance is *very* critical. Also, audit-gradness for the routing process is critical. It's not just about flow-of-control. You need to be able to configure all these properties for various use cases. Rainer From sean at conman.org Tue Jul 13 09:46:39 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 03:46:39 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> References: <20100713010926.GC3089@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> Message-ID: <20100713074639.GB23556@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > The format being sent is documented in RFC-3164, in which the only > > mandatory field is PRI > > No, not even PRI ;) Yes, you are correct. I misspoke 8-) > > ---it's up the the receiving end to make sense of > > the > > rest of the message. It appears that in your case rsyslogd is > > mis-interpreting the incoming message. > > Technically speaking, RFC3164 is not a standard, because it is an > informational document. I have elaborated about its implications in: > > http://www.rsyslog.com/doc-syslog_parsing.html > > So if we follow your view, we simply need to accept anything as being valid, > and as such we do never know which information is contained inside a message > (just ask yourself the question how you know what the sender meant in this > case. Message is > > "hostname junk" > > Was this intended to mean MSG = "hostname junk" or was it intended to mean > hostname="hostname", MSG="junk" -- or something else? In my own project, I treat it as MSG = "hostname junk" with a facility of USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, because of the wide variance I've encountered in parsing syslog messages, when I send out a message, I use the IP address as the hostname (I find the IP address (either v4 or v6) to be unambigious and easier to find than a hostname), and anything else in that portion (up to a colon) as the program name (one exception: anything in square brackets is a process id). The entire parser routine is 210 lines of C (including a ton of comments) and it works enough for my tastes (and if I come across somethign that doesn't parse right, I still have the raw log to check against). Adding RFC-5424 parsing support would be easy, but I don't have anything generating RFC-5424 records (well, I suppose my program could relay in RFC-5424 format ... ) -spc From rgerhards at hq.adiscon.com Tue Jul 13 10:15:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:15:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com> <20100713074639.GB23556@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 9:47 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > > The format being sent is documented in RFC-3164, in which the > only > > > mandatory field is PRI > > > > No, not even PRI ;) > > Yes, you are correct. I misspoke 8-) > > > > ---it's up the the receiving end to make sense of > > > the > > > rest of the message. It appears that in your case rsyslogd is > > > mis-interpreting the incoming message. > > > > Technically speaking, RFC3164 is not a standard, because it is an > > informational document. I have elaborated about its implications in: > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > So if we follow your view, we simply need to accept anything as being > valid, > > and as such we do never know which information is contained inside a > message > > (just ask yourself the question how you know what the sender meant in > this > > case. Message is > > > > "hostname junk" > > > > Was this intended to mean MSG = "hostname junk" or was it intended to > mean > > hostname="hostname", MSG="junk" -- or something else? > > In my own project, I treat it as MSG = "hostname junk" with a > facility of > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, > because of the wide variance I've encountered in parsing syslog > messages, > when I send out a message, I use the IP address as the hostname (I find > the > IP address (either v4 or v6) to be unambigious and easier to find than > a > hostname), and anything else in that portion (up to a colon) as the > program > name (one exception: anything in square brackets is a process id). That's the well known approach, which means you do not really interpret the message. Also, it makes your project unsuitable for NAT environments and relay chains. This, as a side-note, where some of the reasons why syslog standardization started. Even 10 years ago, people where quite unsatisfied with these problems. > > The entire parser routine is 210 lines of C (including a ton of > comments) > and it works enough for my tastes (and if I come across somethign that > doesn't parse right, I still have the raw log to check against). %rawmsg% Rainer > Adding > RFC-5424 parsing support would be easy, but I don't have anything > generating > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > format > ... ) > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:16:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:16:22 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Oh, yes, you got me here. So please elaborate how you parse "<13>hostname junk" ;) Rainer > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 10:30:15 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 10:30:15 +0200 Subject: [rsyslog] Last message repeated n times problem References: <20100713010926.GC3089@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F97@GRFEXC.intern.adiscon.com><20100713074639.GB23556@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Spc, well, on second thought: rather than (somewhat) heatedly discussing the pros and cons of various parser modes: Wouldn't it make sense if you turn your code into a parser module and contribute that to the project? So users could decide what they prefer. I think that would be truly in the spirit of open source. I will happily accept such a contribution! (It is always great to have freedom of choice). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, July 13, 2010 10:16 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Sean Conner > > Sent: Tuesday, July 13, 2010 9:47 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Last message repeated n times problem > > > > It was thus said that the Great Rainer Gerhards once stated: > > > > The format being sent is documented in RFC-3164, in which the > > only > > > > mandatory field is PRI > > > > > > No, not even PRI ;) > > > > Yes, you are correct. I misspoke 8-) > > > > > > ---it's up the the receiving end to make sense of > > > > the > > > > rest of the message. It appears that in your case rsyslogd is > > > > mis-interpreting the incoming message. > > > > > > Technically speaking, RFC3164 is not a standard, because it is an > > > informational document. I have elaborated about its implications > in: > > > > > > http://www.rsyslog.com/doc-syslog_parsing.html > > > > > > So if we follow your view, we simply need to accept anything as > being > > valid, > > > and as such we do never know which information is contained inside > a > > message > > > (just ask yourself the question how you know what the sender meant > in > > this > > > case. Message is > > > > > > "hostname junk" > > > > > > Was this intended to mean MSG = "hostname junk" or was it intended > to > > mean > > > hostname="hostname", MSG="junk" -- or something else? > > > > In my own project, I treat it as MSG = "hostname junk" with a > > facility of > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > Also, > > because of the wide variance I've encountered in parsing syslog > > messages, > > when I send out a message, I use the IP address as the hostname (I > find > > the > > IP address (either v4 or v6) to be unambigious and easier to find > than > > a > > hostname), and anything else in that portion (up to a colon) as the > > program > > name (one exception: anything in square brackets is a process id). > > That's the well known approach, which means you do not really interpret > the > message. Also, it makes your project unsuitable for NAT environments > and > relay chains. This, as a side-note, where some of the reasons why > syslog > standardization started. Even 10 years ago, people where quite > unsatisfied > with these problems. > > > > > The entire parser routine is 210 lines of C (including a ton of > > comments) > > and it works enough for my tastes (and if I come across somethign > that > > doesn't parse right, I still have the raw log to check against). > > %rawmsg% > > Rainer > > Adding > > RFC-5424 parsing support would be easy, but I don't have anything > > generating > > RFC-5424 records (well, I suppose my program could relay in RFC-5424 > > format > > ... ) > > > > -spc > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Tue Jul 13 11:09:04 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:09:04 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9D@GRFEXC.intern.adiscon.com> Message-ID: <20100713090904.GA18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > > > > In my own project, I treat it as MSG = "hostname junk" with a > > > facility of > > > USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). > > Oh, yes, you got me here. So please elaborate how you parse > > "<13>hostname junk" > > ;) It's be interpreted as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: notice (this is priority---I call it level) msg: hostname junk If instead it was: <15>hostname junk my program would parse it as: version: 0 (here, that means RFC-3164) host: (whatever originally sent the message) relay: (same as above, as it obviously wasn't relayed) timestamp: (when it was received) logtimestatmp: (same as above, since it is missing a timestamp) program: "" pid: 0 facility: user level: debug msg: hostname junk -spc (At least it's consistent 8-) From sean at conman.org Tue Jul 13 11:18:54 2010 From: sean at conman.org (Sean Conner) Date: Tue, 13 Jul 2010 05:18:54 -0400 Subject: [rsyslog] Last message repeated n times problem In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> Message-ID: <20100713091854.GB18093@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > Spc, > > well, on second thought: rather than (somewhat) heatedly discussing the pros > and cons of various parser modes: Wouldn't it make sense if you turn your > code into a parser module and contribute that to the project? So users could > decide what they prefer. I think that would be truly in the spirit of open > source. I will happily accept such a contribution! (It is always great to > have freedom of choice). Which code? My 210 lines of parser? Or a module to toss the message to some Lua code? -spc From rgerhards at hq.adiscon.com Tue Jul 13 11:31:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 11:31:35 +0200 Subject: [rsyslog] Last message repeated n times problem References: <9B6E2A8877C38245BFB15CC491A11DA7103F9C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F9E@GRFEXC.intern.adiscon.com> <20100713091854.GB18093@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103F9F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Sean Conner > Sent: Tuesday, July 13, 2010 11:19 AM > To: rsyslog-users > Subject: Re: [rsyslog] Last message repeated n times problem > > It was thus said that the Great Rainer Gerhards once stated: > > Spc, > > > > well, on second thought: rather than (somewhat) heatedly discussing > the pros > > and cons of various parser modes: Wouldn't it make sense if you turn > your > > code into a parser module and contribute that to the project? So > users could > > decide what they prefer. I think that would be truly in the spirit of > open > > source. I will happily accept such a contribution! (It is always > great to > > have freedom of choice). > > Which code? My 210 lines of parser? I think we were talking about the parser here ;) So, yes, I asked you to turn your parser into a parsing module and contribute it to the project. That makes probably an awful lot of more sense than to discuss what *would* be better. Thinking about it, that discussion probably took more time than it would have taken to create a parser module for "last message...". So if you have running code that you think works (at least in some cases) better than the provided parsers, the most natural thing would be to contribute that code and help to grow the project. > Or a module to toss the message > to > some Lua code? Well, if you can do that (as an output module, I assume), I'd definitely would accept that as a contribution as well. Rainer > > -spc > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Jul 13 16:21:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:21:46 +0200 Subject: [rsyslog] pmlastmsg available - workaround for: Last message repeated n times problem References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Hi all, > That's definitely a way to go. Unfortunately, pmrfc3164 already does a > lot of > guesswork for other cases where things are malformed (just as an > example, > there are devices that put an additional space in front of the date, > invalidating all the offsets you give...). > > The problem is that in a strict sense, RFC3164 does not demand > anything. So > there are lots of things that are mutually exclusive. In the current > parser, > I try to weigh importance of occurrence and performance. So the most > prominent cases are probably handled, conflicting less common cases > not. > "last message repeated n times" is pretty useless, so it has low > priority. I > have also a "performance filter" on my mind, that means I do only those > things that seem reasonable. > > However, the whole idea of introducing message parsers was to solve > exactly > that problem. So I think it is natural to write a new message parser > rather > than try (and probably fail) to fiddle even more with the 3164 parser, > which > already is overwhelmed with guesswork. For "last message...", I would > need to > do a full string compare, anything else would be incompatible with the > already-existing guesswork in pmrfc3164. > > Rainer I have crafted the new message parser I spoke about this morning. The module is called "pmlastmsg" and available via the git master branch right now. The commit is here (you notice it is not much code, if you ignore the macros and preprocessor statements): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=73ebadd5980f91079416a14b a6463d576ecb6207 Doc, with the typical usage sample, is available here: http://www.rsyslog.com/doc-pmlastmsg.html This parser module should solve the "last message repeated n times" problem for all future ;) Rainer From timo.bumke at web.de Tue Jul 13 16:34:21 2010 From: timo.bumke at web.de (Timo Bumke) Date: Tue, 13 Jul 2010 16:34:21 +0200 Subject: [rsyslog] Omoracle ORA-01461 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> References: <35171DEA6A652C41B8C22EA89AE9E6F499081821F5@tuk1mx3.telindus.intra><9B6E2A8877C38245BFB15CC491A11DA7103F94@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103F9A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FA2@GRFEXC.intern.adiscon.com> Message-ID: <4C3C796D.1030003@web.de> Hello, I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: |create table test (hostname varchar2(100), message varchar2(4000)); |I found out that if I am only writing one syslog property to oracle it succeeds. My configuration: |(...) ################ #### ORACLE #### ################ $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt|i| | Any ideas? From rgerhards at hq.adiscon.com Tue Jul 13 16:46:47 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 13 Jul 2010 16:46:47 +0200 Subject: [rsyslog] spoofing module configuration References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FA4@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 09, 2010 11:43 PM > To: rsyslog-users > Subject: [rsyslog] spoofing module configuration > > in reading the spoofing module configuration it strikes me that the > defaults can be significantly improved. > > the common case for needing to so spoofing is that you are spoofing the > original source IP address > > so the current configuration equivalent commands > > $template spoofaddr, "%fromhost-ip%" > $ActionUDPSpoofSourceNameTemplate spoofaddr > > could be made the default (or call it RSYSLOG_spoofaddr to keep from > polluting the namespace) and the result would be far simpler for people > to > configure, becomging simply That's a good idea, and as so far it needs to be specified, we simply can not break existing configs. I'll see to add it ASAP (but I am on the road tomorrow and am now preparing for it). > > $modload omudpspoof > $ActionUDPSpoofTargetHost server.example.com > *.* :omudpspoof: > > it could be simplified even further if there was some way to specify > the > destination on the action line (like the @ and @@ functions do today, > could we use @S@ to indicate spoofing?) Actually, I would not like to do that, because that would merge the functionality into omfwd. Acutally, having tcp and udp in the same module is legacy and cause quite some problems in the past. I am short of splitting these two (it would also have been very useful if we were gone for a new config format in the near term). I think it is not much more burden and clearer to read if we retain a separate module type. But I am open to discussion, I could use @S@ as an alternative module designator, that would work with the current config system, but probably not extend into a new one (whatever we will end up with). > changing the defaults should have no problems with backwards > compatibility, full ack > adding/changing how the desitnation is specified could > break backward compatibility, but this is a very new piece of > functionality and the simplification may be worth it (what versions > have > this available?) 5.1.3 and above Rainer From david at lang.hm Tue Jul 13 19:29:30 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 13 Jul 2010 10:29:30 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: On Tue, 13 Jul 2010, Rainer Gerhards wrote: > To add some of the less obvious things: support for multiple listeners going > to different outputs, in an easy to use way. Support for explicitely > specified concurrency (or serialization) for high-speed environments, support > for different queues, and tying of different queues to different object > classes (inputs, message processors, actions). Flexibility to support > configuration for even unexpected plugins that we may not even know about > (because some third party writes them and never publishes them). > > But I begin to agree that we, the community, as a whole have very different > needs. I have gotten the impression that it is probably a good idea to stop > the current effort and re-start it with a requirements definition. I have > tried to digest the discussions on config format we had over the year, but > sometimes it looks like the only consensus we have is that the current format > is ugly and hard to use. The solutions are very wide-ranging. I have even > briefly looked at syslog-ng, and seen a lot of the pain again that makes me > dislike that format (but I'll probably still have a closer look and will try > to write up my detailed position why I do not find buying into this format is > a good idea). > > All in all, I think the best way to re-start our thinking about the config > format is to set up a web site where we gather user feedback on > > a) what problems they have with the config format > (not what they just dislike, but real problems, an example > From myself: it is nearly impossible to get the sequence right > To bind inputs to the right rulesets AND use ruleset inclusion) > b) which alternatives they see > > With all this being on a web site, it may be possible to craft a better > decision in 6 to 9 month, assuming we were able to gain sufficient feedback > during that time. > > An alternative would be to create a config parser interface, so that > everybody could code up his favorite config language. However, this seems to > be impractical, as many of the ideas floating around (Lua, syslog-ng style) > require not just different config parsers, but a different rsyslog processing > core as well. Obviously a complete rewrite in the case of Lua, less for > syslog-ng, but still considerate. For the syslog-ng style we would need to > create named filters, something that I really find questionable. Also, we > would need to add an interim layer between inputs and rulesets, something > that eats performance. In any case, this are not config-parser only changes. > > Of course, I could just pick one of the alternatives. However, it doesn't > make sense to invest a couple of month to do the config system "right", if we > know that a lot of folks will still be unhappy after we have done this. one thing that's really good about the current rsyslog config is that it makes doing simple things simple, especially for people used to classic syslog. as you say, we need to say what the problems there are with the existing config format and look at how to solve those. We don't necessarily need to change everything. weaknesses that I know of inability to easily/clearly define if-then-else inability to easily/clearly define/use rulesets inability to easily have multiple conditions that go to the same destination (this can be implemented via rulesets, see above) unclear scope rules for config options inability to easily/clearly define per-input rules/filters (this is part of the scope problem above) I don't think that this requires an entirely new config language. I think that almost everything can be solved with a couple simple changes to the config language (although as we found when I proposed this on June 25 there are more drastic changes under the covers to check/correct/document what gets changed when a config option is processed) Ignoring for the moment the problem of changing how the config options are processed (and the fact that you would need to know what data structures are managed/created/modified) what does the following proposal _not_ do? (pasted in from the mail on June 25 since that's now quite a ways back in the archives ;-) I would propose the following (more or less in order of difficulty) introduce scoping whenever you see a "{" in the config file, save the current config options to a stack. when you see a "}" pop the config options from the stack (undoing any changes in between) introduce statement blocks change the parser so that wherever it currently allows one action make it accept a {} block of actions (treat them as if they were multiple actions with & as the selector) introduce named actions something like sub NAME to define and use NAME to use introduce if-then-else internally you could convert it to ruleset { if condition { block discard} { block } } introduct the ability to implcitly define a ruleset if an action is a condition (i.e. nested configutations) then implicitly create a new ruleset to resolve the nesting. with these capabilities available I think that this will allow for straightforward config files representing very complex configurations with very little change internally to rsyslog. I suspect that the result is going to have some bottlenecks in complex configurations due to all the different rulesets and the passing of messages between them, but once the capability is in place in the config file the implementation under the covers could change later to be better optimized. as far as the rsyslog config being hard to understand, I think there are two conditions here. 1. very simple configs where the fact that rsyslog can use a traditional syslog config file (with a header on it that seldom needs to change) is a huge advantage 2. complex configs where the inability to define scope and nest things is a major problem and makes the resulting config hard to write. David Lang From rgerhards at hq.adiscon.com Thu Jul 15 09:41:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:41:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Hi David, thanks for the well-crafted mail. My concerns for this proposal were (and are) mainly based on the "under the cover" changes. Other than that, I think you are right, except that it boils down to personal taste. Let me ignore the internal changes for now. Throwing in "{}" creates a very compact, ultra-brief config language. But it would definitely work. I just have to admit it does not fit my *personal* taste because it carries a lot of implicit scoping as well (like what exactly is meant to be scoped by the {} -- an action, or an input, or a ruleset...). But I think the semantics of this format are close to any other config format that fits rsyslog. So I think it is probably worth giving it a try, so that we make at least some progress. The only thing I really would like to change is to use "()" instead of "{}" because I would like to reserve "{}" for future use, where it may fit the user's expectation better than simple parenthesis. But I guess that's not really a problem. One thing though, that is on my feature list is that I would like to use a more standard parser, that means one that can becreated with lex and Bison. While the hand-crafted parser is fine, it always is more work to extend and enhance it. As the parser is no critical component, I'd prefer to use the simpler approach. However, I need to check if I can find a suitable grammar for this proposal. This also works on the assumption. I'd also just concentrate on actions for now. So to double-check a fairly simple config in that format would look as follows: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files ( $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; ) ============================================================== This is based on the second example in http://www.rsyslog.com/doc-rsyslog_high_database_rate.html I will probably also begin to look at the internal changes. As it looks, we need to make them in any case. So it doesn't hurt to start with them, even though there initially will be no external (user) visibility that they are made. But at first, I'll start looking at how this may be processed by a standard flex/bison parser. From the work I already did, I know this is not easy, but could probably work. Feedback appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, July 13, 2010 7:30 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > To add some of the less obvious things: support for multiple > listeners going > > to different outputs, in an easy to use way. Support for explicitely > > specified concurrency (or serialization) for high-speed environments, > support > > for different queues, and tying of different queues to different > object > > classes (inputs, message processors, actions). Flexibility to support > > configuration for even unexpected plugins that we may not even know > about > > (because some third party writes them and never publishes them). > > > > But I begin to agree that we, the community, as a whole have very > different > > needs. I have gotten the impression that it is probably a good idea > to stop > > the current effort and re-start it with a requirements definition. I > have > > tried to digest the discussions on config format we had over the > year, but > > sometimes it looks like the only consensus we have is that the > current format > > is ugly and hard to use. The solutions are very wide-ranging. I have > even > > briefly looked at syslog-ng, and seen a lot of the pain again that > makes me > > dislike that format (but I'll probably still have a closer look and > will try > > to write up my detailed position why I do not find buying into this > format is > > a good idea). > > > > All in all, I think the best way to re-start our thinking about the > config > > format is to set up a web site where we gather user feedback on > > > > a) what problems they have with the config format > > (not what they just dislike, but real problems, an example > > From myself: it is nearly impossible to get the sequence right > > To bind inputs to the right rulesets AND use ruleset inclusion) > > b) which alternatives they see > > > > With all this being on a web site, it may be possible to craft a > better > > decision in 6 to 9 month, assuming we were able to gain sufficient > feedback > > during that time. > > > > An alternative would be to create a config parser interface, so that > > everybody could code up his favorite config language. However, this > seems to > > be impractical, as many of the ideas floating around (Lua, syslog-ng > style) > > require not just different config parsers, but a different rsyslog > processing > > core as well. Obviously a complete rewrite in the case of Lua, less > for > > syslog-ng, but still considerate. For the syslog-ng style we would > need to > > create named filters, something that I really find questionable. > Also, we > > would need to add an interim layer between inputs and rulesets, > something > > that eats performance. In any case, this are not config-parser only > changes. > > > > Of course, I could just pick one of the alternatives. However, it > doesn't > > make sense to invest a couple of month to do the config system > "right", if we > > know that a lot of folks will still be unhappy after we have done > this. > > one thing that's really good about the current rsyslog config is that > it > makes doing simple things simple, especially for people used to classic > syslog. > > as you say, we need to say what the problems there are with the > existing > config format and look at how to solve those. We don't necessarily need > to > change everything. > > weaknesses that I know of > > inability to easily/clearly define if-then-else > > inability to easily/clearly define/use rulesets > > inability to easily have multiple conditions that go to the same > destination (this can be implemented via rulesets, see above) > > unclear scope rules for config options > > inability to easily/clearly define per-input rules/filters (this is > part > of the scope problem above) > > > I don't think that this requires an entirely new config language. I > think > that almost everything can be solved with a couple simple changes to > the > config language (although as we found when I proposed this on June 25 > there are more drastic changes under the covers to > check/correct/document > what gets changed when a config option is processed) > > > Ignoring for the moment the problem of changing how the config options > are > processed (and the fact that you would need to know what data > structures > are managed/created/modified) what does the following proposal _not_ > do? > > (pasted in from the mail on June 25 since that's now quite a ways back > in > the archives ;-) > > > > I would propose the following (more or less in order of difficulty) > > introduce scoping > > whenever you see a "{" in the config file, save the current config > options to a stack. when you see a "}" pop the config options from the > stack (undoing any changes in between) introduce statement blocks > change the parser so that wherever it currently allows one action > make > it accept a {} block of actions (treat them as if they were multiple > actions with & as the selector) > > introduce named actions > > something like sub NAME to define and use NAME to use > > introduce if-then-else > > internally you could convert it to > > ruleset { > if condition { > block > discard} > { block } } > > introduct the ability to implcitly define a ruleset > > if an action is a condition (i.e. nested configutations) then > implicitly > create a new ruleset to resolve the nesting. > > > with these capabilities available I think that this will allow for > straightforward config files representing very complex configurations > with > very little change internally to rsyslog. > > I suspect that the result is going to have some bottlenecks in complex > configurations due to all the different rulesets and the passing of > messages between them, but once the capability is in place in the > config > file the implementation under the covers could change later to be > better > optimized. > > as far as the rsyslog config being hard to understand, I think there > are > two conditions here. > > 1. very simple configs where the fact that rsyslog can use a > traditional > syslog config file (with a header on it that seldom needs to change) is > a > huge advantage > > 2. complex configs where the inability to define scope and nest things > is > a major problem and makes the resulting config hard to write. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 09:50:55 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 00:50:55 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were (and > are) mainly based on the "under the cover" changes. Other than that, I think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. But it > would definitely work. I just have to admit it does not fit my *personal* > taste because it carries a lot of implicit scoping as well (like what exactly > is meant to be scoped by the {} -- an action, or an input, or a ruleset...). > But I think the semantics of this format are close to any other config format > that fits rsyslog. So I think it is probably worth giving it a try, so that > we make at least some progress. The only thing I really would like to change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. sure, I suggested {} in part from habit as they are used to defien blocks in several languages while () tends to be used for parameters to a function, but this is a cosmetic change (and easy to tweak once a proof-of-concept parser is available) > One thing though, that is on my feature list is that I would like to use a > more standard parser, that means one that can becreated with lex and Bison. > While the hand-crafted parser is fine, it always is more work to extend and > enhance it. As the parser is no critical component, I'd prefer to use the > simpler approach. However, I need to check if I can find a suitable grammar > for this proposal. This also works on the assumption. I don't see this as a problem. It's work to define a parser, but I don't think that the current grammer is significantly harder to put into a lex/bison parser than any other (the exception being the implicit scoping rules) > I'd also just concentrate on actions for now. So to double-check a fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html looks sane to me. one question, does the comment really mean what it sounds like on this line? $ActionQueueType LinkedList # use asynchronous processing This makes it sound like you don't do async processing if you use the default queue type. I didn't think that that was the case. > I will probably also begin to look at the internal changes. As it looks, we > need to make them in any case. So it doesn't hurt to start with them, even > though there initially will be no external (user) visibility that they are > made. I agree, the changes that I think are going to be needed are as much documentation as they are functional changes. Makeing sure that we know what variables are changed by each config line that's possible, and making it so that these changes are done in a way that they can be swapped out for a different set of values as scope changes happen. David Lang > But at first, I'll start looking at how this may be processed by a standard > flex/bison parser. From the work I already did, I know this is not easy, but > could probably work. > > Feedback appreciated. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, July 13, 2010 7:30 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >> >>> To add some of the less obvious things: support for multiple >> listeners going >>> to different outputs, in an easy to use way. Support for explicitely >>> specified concurrency (or serialization) for high-speed environments, >> support >>> for different queues, and tying of different queues to different >> object >>> classes (inputs, message processors, actions). Flexibility to support >>> configuration for even unexpected plugins that we may not even know >> about >>> (because some third party writes them and never publishes them). >>> >>> But I begin to agree that we, the community, as a whole have very >> different >>> needs. I have gotten the impression that it is probably a good idea >> to stop >>> the current effort and re-start it with a requirements definition. I >> have >>> tried to digest the discussions on config format we had over the >> year, but >>> sometimes it looks like the only consensus we have is that the >> current format >>> is ugly and hard to use. The solutions are very wide-ranging. I have >> even >>> briefly looked at syslog-ng, and seen a lot of the pain again that >> makes me >>> dislike that format (but I'll probably still have a closer look and >> will try >>> to write up my detailed position why I do not find buying into this >> format is >>> a good idea). >>> >>> All in all, I think the best way to re-start our thinking about the >> config >>> format is to set up a web site where we gather user feedback on >>> >>> a) what problems they have with the config format >>> (not what they just dislike, but real problems, an example >>> From myself: it is nearly impossible to get the sequence right >>> To bind inputs to the right rulesets AND use ruleset inclusion) >>> b) which alternatives they see >>> >>> With all this being on a web site, it may be possible to craft a >> better >>> decision in 6 to 9 month, assuming we were able to gain sufficient >> feedback >>> during that time. >>> >>> An alternative would be to create a config parser interface, so that >>> everybody could code up his favorite config language. However, this >> seems to >>> be impractical, as many of the ideas floating around (Lua, syslog-ng >> style) >>> require not just different config parsers, but a different rsyslog >> processing >>> core as well. Obviously a complete rewrite in the case of Lua, less >> for >>> syslog-ng, but still considerate. For the syslog-ng style we would >> need to >>> create named filters, something that I really find questionable. >> Also, we >>> would need to add an interim layer between inputs and rulesets, >> something >>> that eats performance. In any case, this are not config-parser only >> changes. >>> >>> Of course, I could just pick one of the alternatives. However, it >> doesn't >>> make sense to invest a couple of month to do the config system >> "right", if we >>> know that a lot of folks will still be unhappy after we have done >> this. >> >> one thing that's really good about the current rsyslog config is that >> it >> makes doing simple things simple, especially for people used to classic >> syslog. >> >> as you say, we need to say what the problems there are with the >> existing >> config format and look at how to solve those. We don't necessarily need >> to >> change everything. >> >> weaknesses that I know of >> >> inability to easily/clearly define if-then-else >> >> inability to easily/clearly define/use rulesets >> >> inability to easily have multiple conditions that go to the same >> destination (this can be implemented via rulesets, see above) >> >> unclear scope rules for config options >> >> inability to easily/clearly define per-input rules/filters (this is >> part >> of the scope problem above) >> >> >> I don't think that this requires an entirely new config language. I >> think >> that almost everything can be solved with a couple simple changes to >> the >> config language (although as we found when I proposed this on June 25 >> there are more drastic changes under the covers to >> check/correct/document >> what gets changed when a config option is processed) >> >> >> Ignoring for the moment the problem of changing how the config options >> are >> processed (and the fact that you would need to know what data >> structures >> are managed/created/modified) what does the following proposal _not_ >> do? >> >> (pasted in from the mail on June 25 since that's now quite a ways back >> in >> the archives ;-) >> >> >> >> I would propose the following (more or less in order of difficulty) >> >> introduce scoping >> >> whenever you see a "{" in the config file, save the current config >> options to a stack. when you see a "}" pop the config options from the >> stack (undoing any changes in between) introduce statement blocks >> change the parser so that wherever it currently allows one action >> make >> it accept a {} block of actions (treat them as if they were multiple >> actions with & as the selector) >> >> introduce named actions >> >> something like sub NAME to define and use NAME to use >> >> introduce if-then-else >> >> internally you could convert it to >> >> ruleset { >> if condition { >> block >> discard} >> { block } } >> >> introduct the ability to implcitly define a ruleset >> >> if an action is a condition (i.e. nested configutations) then >> implicitly >> create a new ruleset to resolve the nesting. >> >> >> with these capabilities available I think that this will allow for >> straightforward config files representing very complex configurations >> with >> very little change internally to rsyslog. >> >> I suspect that the result is going to have some bottlenecks in complex >> configurations due to all the different rulesets and the passing of >> messages between them, but once the capability is in place in the >> config >> file the implementation under the covers could change later to be >> better >> optimized. >> >> as far as the rsyslog config being hard to understand, I think there >> are >> two conditions here. >> >> 1. very simple configs where the fact that rsyslog can use a >> traditional >> syslog config file (with a header on it that seldom needs to change) is >> a >> huge advantage >> >> 2. complex configs where the inability to define scope and nest things >> is >> a major problem and makes the resulting config hard to write. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 09:53:35 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 09:53:35 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> After writing this, it just hit me that we could stay within the current config notation by introducing $begin $name $end Constructs and don't change anything at the config language at all. The sample below could then be: ============================================================== $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) $ModLoad imudp # network reception $UDPServerRun 514 # start a udp server at port 514 $ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files $Begin action $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:hostname,dbname,userid,password; $End action ============================================================== This would probably be possible to implement within the constraints of the current config parser. We could also add a directive $StrictScoping on to instruct rsyslog to disallow and $Action directives outside of scoped blocks (this could be good to guard against accidential global directives). That still requires reworking of the internals, but would not need a new (real) grammar, so it would be considerable less work. I still need to see how it would work with more complex configs, but assuming we have things like $Begin Ruleset $Begin Rule $Begin Input I think the same paradigm could probably be used for everything (and that than would eliminate the need for a new grammar). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 15, 2010 9:42 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Hi David, > > thanks for the well-crafted mail. My concerns for this proposal were > (and > are) mainly based on the "under the cover" changes. Other than that, I > think > you are right, except that it boils down to personal taste. > > Let me ignore the internal changes for now. > > Throwing in "{}" creates a very compact, ultra-brief config language. > But it > would definitely work. I just have to admit it does not fit my > *personal* > taste because it carries a lot of implicit scoping as well (like what > exactly > is meant to be scoped by the {} -- an action, or an input, or a > ruleset...). > But I think the semantics of this format are close to any other config > format > that fits rsyslog. So I think it is probably worth giving it a try, so > that > we make at least some progress. The only thing I really would like to > change > is to use "()" instead of "{}" because I would like to reserve "{}" for > future use, where it may fit the user's expectation better than simple > parenthesis. But I guess that's not really a problem. > > One thing though, that is on my feature list is that I would like to > use a > more standard parser, that means one that can becreated with lex and > Bison. > While the hand-crafted parser is fine, it always is more work to extend > and > enhance it. As the parser is no critical component, I'd prefer to use > the > simpler approach. However, I need to check if I can find a suitable > grammar > for this proposal. This also works on the assumption. > > I'd also just concentrate on actions for now. So to double-check a > fairly > simple config in that format would look as follows: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > ( > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > ) > ============================================================== > > This is based on the second example in > http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > > I will probably also begin to look at the internal changes. As it > looks, we > need to make them in any case. So it doesn't hurt to start with them, > even > though there initially will be no external (user) visibility that they > are > made. > > But at first, I'll start looking at how this may be processed by a > standard > flex/bison parser. From the work I already did, I know this is not > easy, but > could probably work. > > Feedback appreciated. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > Sent: Tuesday, July 13, 2010 7:30 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] NEW rsyslog.conf format > > > > On Tue, 13 Jul 2010, Rainer Gerhards wrote: > > > > > To add some of the less obvious things: support for multiple > > listeners going > > > to different outputs, in an easy to use way. Support for > explicitely > > > specified concurrency (or serialization) for high-speed > environments, > > support > > > for different queues, and tying of different queues to different > > object > > > classes (inputs, message processors, actions). Flexibility to > support > > > configuration for even unexpected plugins that we may not even know > > about > > > (because some third party writes them and never publishes them). > > > > > > But I begin to agree that we, the community, as a whole have very > > different > > > needs. I have gotten the impression that it is probably a good idea > > to stop > > > the current effort and re-start it with a requirements definition. > I > > have > > > tried to digest the discussions on config format we had over the > > year, but > > > sometimes it looks like the only consensus we have is that the > > current format > > > is ugly and hard to use. The solutions are very wide-ranging. I > have > > even > > > briefly looked at syslog-ng, and seen a lot of the pain again that > > makes me > > > dislike that format (but I'll probably still have a closer look and > > will try > > > to write up my detailed position why I do not find buying into this > > format is > > > a good idea). > > > > > > All in all, I think the best way to re-start our thinking about the > > config > > > format is to set up a web site where we gather user feedback on > > > > > > a) what problems they have with the config format > > > (not what they just dislike, but real problems, an example > > > From myself: it is nearly impossible to get the sequence right > > > To bind inputs to the right rulesets AND use ruleset inclusion) > > > b) which alternatives they see > > > > > > With all this being on a web site, it may be possible to craft a > > better > > > decision in 6 to 9 month, assuming we were able to gain sufficient > > feedback > > > during that time. > > > > > > An alternative would be to create a config parser interface, so > that > > > everybody could code up his favorite config language. However, this > > seems to > > > be impractical, as many of the ideas floating around (Lua, syslog- > ng > > style) > > > require not just different config parsers, but a different rsyslog > > processing > > > core as well. Obviously a complete rewrite in the case of Lua, less > > for > > > syslog-ng, but still considerate. For the syslog-ng style we would > > need to > > > create named filters, something that I really find questionable. > > Also, we > > > would need to add an interim layer between inputs and rulesets, > > something > > > that eats performance. In any case, this are not config-parser only > > changes. > > > > > > Of course, I could just pick one of the alternatives. However, it > > doesn't > > > make sense to invest a couple of month to do the config system > > "right", if we > > > know that a lot of folks will still be unhappy after we have done > > this. > > > > one thing that's really good about the current rsyslog config is that > > it > > makes doing simple things simple, especially for people used to > classic > > syslog. > > > > as you say, we need to say what the problems there are with the > > existing > > config format and look at how to solve those. We don't necessarily > need > > to > > change everything. > > > > weaknesses that I know of > > > > inability to easily/clearly define if-then-else > > > > inability to easily/clearly define/use rulesets > > > > inability to easily have multiple conditions that go to the same > > destination (this can be implemented via rulesets, see above) > > > > unclear scope rules for config options > > > > inability to easily/clearly define per-input rules/filters (this is > > part > > of the scope problem above) > > > > > > I don't think that this requires an entirely new config language. I > > think > > that almost everything can be solved with a couple simple changes to > > the > > config language (although as we found when I proposed this on June 25 > > there are more drastic changes under the covers to > > check/correct/document > > what gets changed when a config option is processed) > > > > > > Ignoring for the moment the problem of changing how the config > options > > are > > processed (and the fact that you would need to know what data > > structures > > are managed/created/modified) what does the following proposal _not_ > > do? > > > > (pasted in from the mail on June 25 since that's now quite a ways > back > > in > > the archives ;-) > > > > > > > > I would propose the following (more or less in order of difficulty) > > > > introduce scoping > > > > whenever you see a "{" in the config file, save the current config > > options to a stack. when you see a "}" pop the config options from > the > > stack (undoing any changes in between) introduce statement blocks > > change the parser so that wherever it currently allows one action > > make > > it accept a {} block of actions (treat them as if they were multiple > > actions with & as the selector) > > > > introduce named actions > > > > something like sub NAME to define and use NAME to use > > > > introduce if-then-else > > > > internally you could convert it to > > > > ruleset { > > if condition { > > block > > discard} > > { block } } > > > > introduct the ability to implcitly define a ruleset > > > > if an action is a condition (i.e. nested configutations) then > > implicitly > > create a new ruleset to resolve the nesting. > > > > > > with these capabilities available I think that this will allow for > > straightforward config files representing very complex configurations > > with > > very little change internally to rsyslog. > > > > I suspect that the result is going to have some bottlenecks in > complex > > configurations due to all the different rulesets and the passing of > > messages between them, but once the capability is in place in the > > config > > file the implementation under the covers could change later to be > > better > > optimized. > > > > as far as the rsyslog config being hard to understand, I think there > > are > > two conditions here. > > > > 1. very simple configs where the fact that rsyslog can use a > > traditional > > syslog config file (with a header on it that seldom needs to change) > is > > a > > huge advantage > > > > 2. complex configs where the inability to define scope and nest > things > > is > > a major problem and makes the resulting config hard to write. > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Jul 15 10:00:42 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:00:42 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > After writing this, it just hit me that we could stay within the current > config notation by introducing > > $begin > $end I have no problem with this. I view is as symatically eqivalent to the {}(), just more characters to type ;-) > $name I had even suggested NAME block and USE syntaxes the only question is if we need to explicitly state the type or if it's good enough to be able to just nest the scope. I think you can get away with just nesting the scope, but I could be wrong and if so defining the type is a fairly cheap way of working around the issue. > The sample below could then be: > > ============================================================== > $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) > $ModLoad imudp # network reception > $UDPServerRun 514 # start a udp server at port 514 > $ModLoad imuxsock # local message reception > > $WorkDirectory /rsyslog/work # default location for work (spool) files > > $Begin action > $ActionQueueType LinkedList # use asynchronous processing > $ActionQueueFileName dbq # set file name, also enables disk mode > $ActionResumeRetryCount -1 # infinite retries on insert failure > # for PostgreSQL replace :ommysql: by :ompgsql: below: > *.* :ommysql:hostname,dbname,userid,password; > $End action > ============================================================== > > This would probably be possible to implement within the constraints of the > current config parser. We could also add a directive > > $StrictScoping on > > to instruct rsyslog to disallow and $Action directives outside of > scoped blocks (this could be good to guard against accidential global > directives). probably a good idea. > That still requires reworking of the internals, but would not need a new > (real) grammar, so it would be considerable less work. I still need to see > how it would work with more complex configs, but assuming we have things like > > $Begin Ruleset > $Begin Rule > $Begin Input > > I think the same paradigm could probably be used for everything (and that > than would eliminate the need for a new grammar). sounds good. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Thursday, July 15, 2010 9:42 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Hi David, >> >> thanks for the well-crafted mail. My concerns for this proposal were >> (and >> are) mainly based on the "under the cover" changes. Other than that, I >> think >> you are right, except that it boils down to personal taste. >> >> Let me ignore the internal changes for now. >> >> Throwing in "{}" creates a very compact, ultra-brief config language. >> But it >> would definitely work. I just have to admit it does not fit my >> *personal* >> taste because it carries a lot of implicit scoping as well (like what >> exactly >> is meant to be scoped by the {} -- an action, or an input, or a >> ruleset...). >> But I think the semantics of this format are close to any other config >> format >> that fits rsyslog. So I think it is probably worth giving it a try, so >> that >> we make at least some progress. The only thing I really would like to >> change >> is to use "()" instead of "{}" because I would like to reserve "{}" for >> future use, where it may fit the user's expectation better than simple >> parenthesis. But I guess that's not really a problem. >> >> One thing though, that is on my feature list is that I would like to >> use a >> more standard parser, that means one that can becreated with lex and >> Bison. >> While the hand-crafted parser is fine, it always is more work to extend >> and >> enhance it. As the parser is no critical component, I'd prefer to use >> the >> simpler approach. However, I need to check if I can find a suitable >> grammar >> for this proposal. This also works on the assumption. >> >> I'd also just concentrate on actions for now. So to double-check a >> fairly >> simple config in that format would look as follows: >> >> ============================================================== >> $ModLoad ommysql # load the output driver (use ompgsql for PostgreSQL) >> $ModLoad imudp # network reception >> $UDPServerRun 514 # start a udp server at port 514 >> $ModLoad imuxsock # local message reception >> >> $WorkDirectory /rsyslog/work # default location for work (spool) files >> >> ( >> $ActionQueueType LinkedList # use asynchronous processing >> $ActionQueueFileName dbq # set file name, also enables disk mode >> $ActionResumeRetryCount -1 # infinite retries on insert failure >> # for PostgreSQL replace :ommysql: by :ompgsql: below: >> *.* :ommysql:hostname,dbname,userid,password; >> ) >> ============================================================== >> >> This is based on the second example in >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html >> >> I will probably also begin to look at the internal changes. As it >> looks, we >> need to make them in any case. So it doesn't hurt to start with them, >> even >> though there initially will be no external (user) visibility that they >> are >> made. >> >> But at first, I'll start looking at how this may be processed by a >> standard >> flex/bison parser. From the work I already did, I know this is not >> easy, but >> could probably work. >> >> Feedback appreciated. >> >> Rainer >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>> Sent: Tuesday, July 13, 2010 7:30 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: >>> >>>> To add some of the less obvious things: support for multiple >>> listeners going >>>> to different outputs, in an easy to use way. Support for >> explicitely >>>> specified concurrency (or serialization) for high-speed >> environments, >>> support >>>> for different queues, and tying of different queues to different >>> object >>>> classes (inputs, message processors, actions). Flexibility to >> support >>>> configuration for even unexpected plugins that we may not even know >>> about >>>> (because some third party writes them and never publishes them). >>>> >>>> But I begin to agree that we, the community, as a whole have very >>> different >>>> needs. I have gotten the impression that it is probably a good idea >>> to stop >>>> the current effort and re-start it with a requirements definition. >> I >>> have >>>> tried to digest the discussions on config format we had over the >>> year, but >>>> sometimes it looks like the only consensus we have is that the >>> current format >>>> is ugly and hard to use. The solutions are very wide-ranging. I >> have >>> even >>>> briefly looked at syslog-ng, and seen a lot of the pain again that >>> makes me >>>> dislike that format (but I'll probably still have a closer look and >>> will try >>>> to write up my detailed position why I do not find buying into this >>> format is >>>> a good idea). >>>> >>>> All in all, I think the best way to re-start our thinking about the >>> config >>>> format is to set up a web site where we gather user feedback on >>>> >>>> a) what problems they have with the config format >>>> (not what they just dislike, but real problems, an example >>>> From myself: it is nearly impossible to get the sequence right >>>> To bind inputs to the right rulesets AND use ruleset inclusion) >>>> b) which alternatives they see >>>> >>>> With all this being on a web site, it may be possible to craft a >>> better >>>> decision in 6 to 9 month, assuming we were able to gain sufficient >>> feedback >>>> during that time. >>>> >>>> An alternative would be to create a config parser interface, so >> that >>>> everybody could code up his favorite config language. However, this >>> seems to >>>> be impractical, as many of the ideas floating around (Lua, syslog- >> ng >>> style) >>>> require not just different config parsers, but a different rsyslog >>> processing >>>> core as well. Obviously a complete rewrite in the case of Lua, less >>> for >>>> syslog-ng, but still considerate. For the syslog-ng style we would >>> need to >>>> create named filters, something that I really find questionable. >>> Also, we >>>> would need to add an interim layer between inputs and rulesets, >>> something >>>> that eats performance. In any case, this are not config-parser only >>> changes. >>>> >>>> Of course, I could just pick one of the alternatives. However, it >>> doesn't >>>> make sense to invest a couple of month to do the config system >>> "right", if we >>>> know that a lot of folks will still be unhappy after we have done >>> this. >>> >>> one thing that's really good about the current rsyslog config is that >>> it >>> makes doing simple things simple, especially for people used to >> classic >>> syslog. >>> >>> as you say, we need to say what the problems there are with the >>> existing >>> config format and look at how to solve those. We don't necessarily >> need >>> to >>> change everything. >>> >>> weaknesses that I know of >>> >>> inability to easily/clearly define if-then-else >>> >>> inability to easily/clearly define/use rulesets >>> >>> inability to easily have multiple conditions that go to the same >>> destination (this can be implemented via rulesets, see above) >>> >>> unclear scope rules for config options >>> >>> inability to easily/clearly define per-input rules/filters (this is >>> part >>> of the scope problem above) >>> >>> >>> I don't think that this requires an entirely new config language. I >>> think >>> that almost everything can be solved with a couple simple changes to >>> the >>> config language (although as we found when I proposed this on June 25 >>> there are more drastic changes under the covers to >>> check/correct/document >>> what gets changed when a config option is processed) >>> >>> >>> Ignoring for the moment the problem of changing how the config >> options >>> are >>> processed (and the fact that you would need to know what data >>> structures >>> are managed/created/modified) what does the following proposal _not_ >>> do? >>> >>> (pasted in from the mail on June 25 since that's now quite a ways >> back >>> in >>> the archives ;-) >>> >>> >>> >>> I would propose the following (more or less in order of difficulty) >>> >>> introduce scoping >>> >>> whenever you see a "{" in the config file, save the current config >>> options to a stack. when you see a "}" pop the config options from >> the >>> stack (undoing any changes in between) introduce statement blocks >>> change the parser so that wherever it currently allows one action >>> make >>> it accept a {} block of actions (treat them as if they were multiple >>> actions with & as the selector) >>> >>> introduce named actions >>> >>> something like sub NAME to define and use NAME to use >>> >>> introduce if-then-else >>> >>> internally you could convert it to >>> >>> ruleset { >>> if condition { >>> block >>> discard} >>> { block } } >>> >>> introduct the ability to implcitly define a ruleset >>> >>> if an action is a condition (i.e. nested configutations) then >>> implicitly >>> create a new ruleset to resolve the nesting. >>> >>> >>> with these capabilities available I think that this will allow for >>> straightforward config files representing very complex configurations >>> with >>> very little change internally to rsyslog. >>> >>> I suspect that the result is going to have some bottlenecks in >> complex >>> configurations due to all the different rulesets and the passing of >>> messages between them, but once the capability is in place in the >>> config >>> file the implementation under the covers could change later to be >>> better >>> optimized. >>> >>> as far as the rsyslog config being hard to understand, I think there >>> are >>> two conditions here. >>> >>> 1. very simple configs where the fact that rsyslog can use a >>> traditional >>> syslog config file (with a header on it that seldom needs to change) >> is >>> a >>> huge advantage >>> >>> 2. complex configs where the inability to define scope and nest >> things >>> is >>> a major problem and makes the resulting config hard to write. >>> >>> David Lang >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Jul 15 10:08:58 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:08:58 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAE@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB0@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, July 15, 2010 10:01 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Thu, 15 Jul 2010, Rainer Gerhards wrote: > > > After writing this, it just hit me that we could stay within the > current > > config notation by introducing > > > > $begin > > $end > > I have no problem with this. I view is as symatically eqivalent to the > {}(), just more characters to type ;-) Jupp, but the big difference is that the current parser can handle that. Also, if we really stick with the language, I personally think this is more consistent with the rest of the language (but that's again an issue of personal taste). > > $name > > I had even suggested NAME block and USE syntaxes Ack, didn't mention it explicitely, but definitely kept it on my mind ;) > > the only question is if we need to explicitly state the type or if it's > good enough to be able to just nest the scope. I think you can get away > with just nesting the scope, but I could be wrong and if so defining > the > type is a fairly cheap way of working around the issue. Again a taste issue first: I think it is less confusing for a human to know what exactly the block defines. But there is also a hard argument: if I know it is an action, I can disallow input or global statements inside this block (and vice versa)! So we do not only get the scoping, but also the capability to not permit irrelevant statements within the scope. The only thing I need to change is add a type to each config statement (in the statement table), but this is not much work (given the fact that I need to change some internals in any way to support the scoping). Rainer > > > The sample below could then be: > > > > ============================================================== > > $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > > $ModLoad imudp # network reception > > $UDPServerRun 514 # start a udp server at port 514 > > $ModLoad imuxsock # local message reception > > > > $WorkDirectory /rsyslog/work # default location for work (spool) > files > > > > $Begin action > > $ActionQueueType LinkedList # use asynchronous processing > > $ActionQueueFileName dbq # set file name, also enables disk mode > > $ActionResumeRetryCount -1 # infinite retries on insert failure > > # for PostgreSQL replace :ommysql: by :ompgsql: below: > > *.* :ommysql:hostname,dbname,userid,password; > > $End action > > ============================================================== > > > > This would probably be possible to implement within the constraints > of the > > current config parser. We could also add a directive > > > > $StrictScoping on > > > > to instruct rsyslog to disallow and $Action directives > outside of > > scoped blocks (this could be good to guard against accidential global > > directives). > > probably a good idea. > > > That still requires reworking of the internals, but would not need a > new > > (real) grammar, so it would be considerable less work. I still need > to see > > how it would work with more complex configs, but assuming we have > things like > > > > $Begin Ruleset > > $Begin Rule > > $Begin Input > > > > I think the same paradigm could probably be used for everything (and > that > > than would eliminate the need for a new grammar). > > sounds good. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > >> Sent: Thursday, July 15, 2010 9:42 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> Hi David, > >> > >> thanks for the well-crafted mail. My concerns for this proposal were > >> (and > >> are) mainly based on the "under the cover" changes. Other than that, > I > >> think > >> you are right, except that it boils down to personal taste. > >> > >> Let me ignore the internal changes for now. > >> > >> Throwing in "{}" creates a very compact, ultra-brief config > language. > >> But it > >> would definitely work. I just have to admit it does not fit my > >> *personal* > >> taste because it carries a lot of implicit scoping as well (like > what > >> exactly > >> is meant to be scoped by the {} -- an action, or an input, or a > >> ruleset...). > >> But I think the semantics of this format are close to any other > config > >> format > >> that fits rsyslog. So I think it is probably worth giving it a try, > so > >> that > >> we make at least some progress. The only thing I really would like > to > >> change > >> is to use "()" instead of "{}" because I would like to reserve "{}" > for > >> future use, where it may fit the user's expectation better than > simple > >> parenthesis. But I guess that's not really a problem. > >> > >> One thing though, that is on my feature list is that I would like to > >> use a > >> more standard parser, that means one that can becreated with lex and > >> Bison. > >> While the hand-crafted parser is fine, it always is more work to > extend > >> and > >> enhance it. As the parser is no critical component, I'd prefer to > use > >> the > >> simpler approach. However, I need to check if I can find a suitable > >> grammar > >> for this proposal. This also works on the assumption. > >> > >> I'd also just concentrate on actions for now. So to double-check a > >> fairly > >> simple config in that format would look as follows: > >> > >> ============================================================== > >> $ModLoad ommysql # load the output driver (use ompgsql for > PostgreSQL) > >> $ModLoad imudp # network reception > >> $UDPServerRun 514 # start a udp server at port 514 > >> $ModLoad imuxsock # local message reception > >> > >> $WorkDirectory /rsyslog/work # default location for work (spool) > files > >> > >> ( > >> $ActionQueueType LinkedList # use asynchronous processing > >> $ActionQueueFileName dbq # set file name, also enables disk mode > >> $ActionResumeRetryCount -1 # infinite retries on insert failure > >> # for PostgreSQL replace :ommysql: by :ompgsql: below: > >> *.* :ommysql:hostname,dbname,userid,password; > >> ) > >> ============================================================== > >> > >> This is based on the second example in > >> http://www.rsyslog.com/doc-rsyslog_high_database_rate.html > >> > >> I will probably also begin to look at the internal changes. As it > >> looks, we > >> need to make them in any case. So it doesn't hurt to start with > them, > >> even > >> though there initially will be no external (user) visibility that > they > >> are > >> made. > >> > >> But at first, I'll start looking at how this may be processed by a > >> standard > >> flex/bison parser. From the work I already did, I know this is not > >> easy, but > >> could probably work. > >> > >> Feedback appreciated. > >> > >> Rainer > >> > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >>> Sent: Tuesday, July 13, 2010 7:30 PM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> On Tue, 13 Jul 2010, Rainer Gerhards wrote: > >>> > >>>> To add some of the less obvious things: support for multiple > >>> listeners going > >>>> to different outputs, in an easy to use way. Support for > >> explicitely > >>>> specified concurrency (or serialization) for high-speed > >> environments, > >>> support > >>>> for different queues, and tying of different queues to different > >>> object > >>>> classes (inputs, message processors, actions). Flexibility to > >> support > >>>> configuration for even unexpected plugins that we may not even > know > >>> about > >>>> (because some third party writes them and never publishes them). > >>>> > >>>> But I begin to agree that we, the community, as a whole have very > >>> different > >>>> needs. I have gotten the impression that it is probably a good > idea > >>> to stop > >>>> the current effort and re-start it with a requirements definition. > >> I > >>> have > >>>> tried to digest the discussions on config format we had over the > >>> year, but > >>>> sometimes it looks like the only consensus we have is that the > >>> current format > >>>> is ugly and hard to use. The solutions are very wide-ranging. I > >> have > >>> even > >>>> briefly looked at syslog-ng, and seen a lot of the pain again that > >>> makes me > >>>> dislike that format (but I'll probably still have a closer look > and > >>> will try > >>>> to write up my detailed position why I do not find buying into > this > >>> format is > >>>> a good idea). > >>>> > >>>> All in all, I think the best way to re-start our thinking about > the > >>> config > >>>> format is to set up a web site where we gather user feedback on > >>>> > >>>> a) what problems they have with the config format > >>>> (not what they just dislike, but real problems, an example > >>>> From myself: it is nearly impossible to get the sequence right > >>>> To bind inputs to the right rulesets AND use ruleset inclusion) > >>>> b) which alternatives they see > >>>> > >>>> With all this being on a web site, it may be possible to craft a > >>> better > >>>> decision in 6 to 9 month, assuming we were able to gain sufficient > >>> feedback > >>>> during that time. > >>>> > >>>> An alternative would be to create a config parser interface, so > >> that > >>>> everybody could code up his favorite config language. However, > this > >>> seems to > >>>> be impractical, as many of the ideas floating around (Lua, syslog- > >> ng > >>> style) > >>>> require not just different config parsers, but a different rsyslog > >>> processing > >>>> core as well. Obviously a complete rewrite in the case of Lua, > less > >>> for > >>>> syslog-ng, but still considerate. For the syslog-ng style we would > >>> need to > >>>> create named filters, something that I really find questionable. > >>> Also, we > >>>> would need to add an interim layer between inputs and rulesets, > >>> something > >>>> that eats performance. In any case, this are not config-parser > only > >>> changes. > >>>> > >>>> Of course, I could just pick one of the alternatives. However, it > >>> doesn't > >>>> make sense to invest a couple of month to do the config system > >>> "right", if we > >>>> know that a lot of folks will still be unhappy after we have done > >>> this. > >>> > >>> one thing that's really good about the current rsyslog config is > that > >>> it > >>> makes doing simple things simple, especially for people used to > >> classic > >>> syslog. > >>> > >>> as you say, we need to say what the problems there are with the > >>> existing > >>> config format and look at how to solve those. We don't necessarily > >> need > >>> to > >>> change everything. > >>> > >>> weaknesses that I know of > >>> > >>> inability to easily/clearly define if-then-else > >>> > >>> inability to easily/clearly define/use rulesets > >>> > >>> inability to easily have multiple conditions that go to the same > >>> destination (this can be implemented via rulesets, see above) > >>> > >>> unclear scope rules for config options > >>> > >>> inability to easily/clearly define per-input rules/filters (this is > >>> part > >>> of the scope problem above) > >>> > >>> > >>> I don't think that this requires an entirely new config language. I > >>> think > >>> that almost everything can be solved with a couple simple changes > to > >>> the > >>> config language (although as we found when I proposed this on June > 25 > >>> there are more drastic changes under the covers to > >>> check/correct/document > >>> what gets changed when a config option is processed) > >>> > >>> > >>> Ignoring for the moment the problem of changing how the config > >> options > >>> are > >>> processed (and the fact that you would need to know what data > >>> structures > >>> are managed/created/modified) what does the following proposal > _not_ > >>> do? > >>> > >>> (pasted in from the mail on June 25 since that's now quite a ways > >> back > >>> in > >>> the archives ;-) > >>> > >>> > >>> > >>> I would propose the following (more or less in order of difficulty) > >>> > >>> introduce scoping > >>> > >>> whenever you see a "{" in the config file, save the current > config > >>> options to a stack. when you see a "}" pop the config options from > >> the > >>> stack (undoing any changes in between) introduce statement blocks > >>> change the parser so that wherever it currently allows one > action > >>> make > >>> it accept a {} block of actions (treat them as if they were > multiple > >>> actions with & as the selector) > >>> > >>> introduce named actions > >>> > >>> something like sub NAME to define and use NAME to use > >>> > >>> introduce if-then-else > >>> > >>> internally you could convert it to > >>> > >>> ruleset { > >>> if condition { > >>> block > >>> discard} > >>> { block } } > >>> > >>> introduct the ability to implcitly define a ruleset > >>> > >>> if an action is a condition (i.e. nested configutations) then > >>> implicitly > >>> create a new ruleset to resolve the nesting. > >>> > >>> > >>> with these capabilities available I think that this will allow for > >>> straightforward config files representing very complex > configurations > >>> with > >>> very little change internally to rsyslog. > >>> > >>> I suspect that the result is going to have some bottlenecks in > >> complex > >>> configurations due to all the different rulesets and the passing of > >>> messages between them, but once the capability is in place in the > >>> config > >>> file the implementation under the covers could change later to be > >>> better > >>> optimized. > >>> > >>> as far as the rsyslog config being hard to understand, I think > there > >>> are > >>> two conditions here. > >>> > >>> 1. very simple configs where the fact that rsyslog can use a > >>> traditional > >>> syslog config file (with a header on it that seldom needs to > change) > >> is > >>> a > >>> huge advantage > >>> > >>> 2. complex configs where the inability to define scope and nest > >> things > >>> is > >>> a major problem and makes the resulting config hard to write. > >>> > >>> David Lang > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 15 10:14:19 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 15 Jul 2010 10:14:19 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> While I think we alread settle fort he other alternative, there is one point I'D like to take (as it may be important for future discussions): > > One thing though, that is on my feature list is that I would like to > use a > > more standard parser, that means one that can becreated with lex and > Bison. > > While the hand-crafted parser is fine, it always is more work to > extend and > > enhance it. As the parser is no critical component, I'd prefer to use > the > > simpler approach. However, I need to check if I can find a suitable > grammar > > for this proposal. This also works on the assumption. > > I don't see this as a problem. It's work to define a parser, but I > don't > think that the current grammer is significantly harder to put into a > lex/bison parser than any other (the exception being the implicit > scoping > rules) A problem from the grammer PoV is that a traditional action line has no structure at all. It is anything from the first non-whitespace after the filter to the end of line. So here we need LF as a delimiter, while in all other cases, NL should be consider as whitespace and be discarded. You really can't specify this with a decent contextfree grammar, but Flex's substates most probably provide sufficient power to cover these "two languages in one" approach. But as I said ... this seem no longer be relevant to the current discussion, as we will probably stick with the current config system and its parser. Rainer From david at lang.hm Thu Jul 15 10:37:49 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 01:37:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 15 Jul 2010, Rainer Gerhards wrote: > While I think we alread settle fort he other alternative, there is one point > I'D like to take (as it may be important for future discussions): > >>> One thing though, that is on my feature list is that I would like to >> use a >>> more standard parser, that means one that can becreated with lex and >> Bison. >>> While the hand-crafted parser is fine, it always is more work to >> extend and >>> enhance it. As the parser is no critical component, I'd prefer to use >> the >>> simpler approach. However, I need to check if I can find a suitable >> grammar >>> for this proposal. This also works on the assumption. >> >> I don't see this as a problem. It's work to define a parser, but I >> don't >> think that the current grammer is significantly harder to put into a >> lex/bison parser than any other (the exception being the implicit >> scoping >> rules) > > A problem from the grammer PoV is that a traditional action line has no > structure at all. It is anything from the first non-whitespace after the > filter to the end of line. So here we need LF as a delimiter, while in all > other cases, NL should be consider as whitespace and be discarded. interesting, I'm not sure that anyone else realized that a config option could be split over multiple lines. I'd lay good odds that you could say that NL/LF is the end of a configuration option in an upgrade without anyone noticing the change. > You really > can't specify this with a decent contextfree grammar, but Flex's substates > most probably provide sufficient power to cover these "two languages in one" > approach. > > But as I said ... this seem no longer be relevant to the current discussion, > as we will probably stick with the current config system and its parser. In the long run it's probably a useful thing to switch from the current parser to a lex/bison based parser. it makes it easier to be sure that you are sticking with the defined config language, and should make it easier to add new options, but it's not a requrement. David Lang From mrdemeanour at jackpot.uk.net Thu Jul 15 11:13:15 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Thu, 15 Jul 2010 10:13:15 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> Message-ID: <4C3ED12B.4080704@jackpot.uk.net> david at lang.hm wrote: > > interesting, I'm not sure that anyone else realized that a config > option could be split over multiple lines. I've banged my head on this (end-of-line comments). I believe the comments problem has been worked around now, but I still make sure that I don't try to use end-of-line comments anywhere in my configs, just in case. -- Jack. From joel.merrick at gmail.com Thu Jul 15 13:18:59 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 15 Jul 2010 12:18:59 +0100 Subject: [rsyslog] MySQL custom filters? Message-ID: Hi list, I'm trying to build a service to enable the quick searching of mail logs, for our support team to use. We get quite a lot of log generation (about 2G of mysql data a day) Searching these becomes really inefficient after a while, even though there's extra keys and indexes in the db. I'd like to try and parse the syslog event using rsyslog and get the message ID out of the payload and add it as an indexed field, which should speed up queries (so we can stitch together a full email transaction) Is this something rsyslog can do? I'm currently using the default db schema and loganalyzer 3.0.1 If not, no big deal, will have to write a custom parser and use a pipe to take the syslogs from rsyslog (perhaps?) I've also thought of multiplexing the logs to ramdisk and physical disk, although that throws up another set of problems. Cheers Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 07:43:31 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 15 Jul 2010 22:43:31 -0700 (PDT) Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Thu, 15 Jul 2010, Joel Merrick wrote: > Hi list, > > I'm trying to build a service to enable the quick searching of mail > logs, for our support team to use. We get quite a lot of log > generation (about 2G of mysql data a day) > > Searching these becomes really inefficient after a while, even though > there's extra keys and indexes in the db. > > I'd like to try and parse the syslog event using rsyslog and get the > message ID out of the payload and add it as an indexed field, which > should speed up queries (so we can stitch together a full email > transaction) this shouldn't be _too_ hard, depending on where the message ID is in the messages you are logging just create your own template that writes the message ID as a separate field. David Lang > Is this something rsyslog can do? I'm currently using the default db > schema and loganalyzer 3.0.1 > > If not, no big deal, will have to write a custom parser and use a pipe > to take the syslogs from rsyslog (perhaps?) > > I've also thought of multiplexing the logs to ramdisk and physical > disk, although that throws up another set of problems. > > Cheers > Joel > > From rgerhards at hq.adiscon.com Fri Jul 16 08:53:38 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 08:53:38 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Thursday, July 15, 2010 11:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > david at lang.hm wrote: > > > > interesting, I'm not sure that anyone else realized that a config > > option could be split over multiple lines. > > I've banged my head on this (end-of-line comments). I believe the > comments problem has been worked around now, but I still make sure that > I don't try to use end-of-line comments anywhere in my configs, just in > case. That's an (one?) anomaly of the current parser. Thinking that it would be replaced in the medium to long term, I did not care about it. Looks like I now need to have a look ;) Rainer From rgerhards at hq.adiscon.com Fri Jul 16 09:11:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 09:11:20 +0200 Subject: [rsyslog] MySQL custom filters? References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FB8@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Friday, July 16, 2010 7:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] MySQL custom filters? > > On Thu, 15 Jul 2010, Joel Merrick wrote: > > > Hi list, > > > > I'm trying to build a service to enable the quick searching of mail > > logs, for our support team to use. We get quite a lot of log > > generation (about 2G of mysql data a day) > > > > Searching these becomes really inefficient after a while, even though > > there's extra keys and indexes in the db. > > > > I'd like to try and parse the syslog event using rsyslog and get the > > message ID out of the payload and add it as an indexed field, which > > should speed up queries (so we can stitch together a full email > > transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in > the > messages you are logging > > just create your own template that writes the message ID as a separate > field. If that's fast enough, you probably use regular expressions inside templates. Depending on the message content, you can possibly use field-based extraction (which is faster). If all that is too slow, you can write (or have written) a custom message formatter, where you have full control and power over what is done. So in short: ample of possibilities. :) Rainer From timo.bumke at bayerhealthcare.com Fri Jul 16 09:24:35 2010 From: timo.bumke at bayerhealthcare.com (timo.bumke at bayerhealthcare.com) Date: Fri, 16 Jul 2010 09:24:35 +0200 Subject: [rsyslog] Omoracle ORA-01461 Message-ID: Hello list, anybody using omoracle successfully and can help me with my problem? I followed regner's notes to setup rsyslog and omoracle. But even with a test db and two columns it won't work with my installation, see: "rsyslogd: Error message: ORA-01461: can bind a LONG value only for insert into a LONG column". I created the test table as follows: create table test (hostname varchar2(100), message varchar2(4000)); I found out that if I am only writing one syslog property to oracle it succeeds. My failing configuration: $ModLoad omoracle $OmoracleDBUser myoracleuser $OmoracleDBPassword ***** $OmoracleDB myoracledb $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"INSERT INTO TEST(hostname,message) VALUES(:hostname,:msg)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt Freundliche Gr??e / Best regards Timo Bumke _________________________________________ B&R Unternehmensberatungs- und Vertriebsgesellschaft mbH Amsterdamer Str.230 50735 K?ln, Deutschland Vertragspartner der Bayer Schering Pharma AG Im Auftrag der Bayer Schering Pharma AG Geb?ude A001, EG, Raum 012 59192 Bergkamen, Deutschland Phone: +49 2307 65-3803 Email: timo.bumke at bayerhealthcare.com Web: http://www.bayerscheringpharma.de From mrdemeanour at jackpot.uk.net Fri Jul 16 11:32:34 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Fri, 16 Jul 2010 10:32:34 +0100 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> Message-ID: <4C402732.5030806@jackpot.uk.net> Rainer Gerhards wrote: >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> david at lang.hm wrote: >>> interesting, I'm not sure that anyone else realized that a config >>> option could be split over multiple lines. >> I've banged my head on this (end-of-line comments). I believe the >> comments problem has been worked around now, but I still make sure >> that I don't try to use end-of-line comments anywhere in my >> configs, just in case. > > That's an (one?) anomaly of the current parser. Thinking that it > would be replaced in the medium to long term, I did not care about > it. Looks like I now need to have a look ;) No big deal for me *now*, but it caused pain when I first ran into it. Anyway, I thought you'd addressed this - about a year ago, maybe? -- Jack. From rgerhards at hq.adiscon.com Fri Jul 16 11:50:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 11:50:16 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > Sent: Friday, July 16, 2010 11:33 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > Rainer Gerhards wrote: > >> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users > >> Subject: Re: [rsyslog] NEW rsyslog.conf format > >> > >> david at lang.hm wrote: > >>> interesting, I'm not sure that anyone else realized that a config > >>> option could be split over multiple lines. > >> I've banged my head on this (end-of-line comments). I believe the > >> comments problem has been worked around now, but I still make sure > >> that I don't try to use end-of-line comments anywhere in my > >> configs, just in case. > > > > That's an (one?) anomaly of the current parser. Thinking that it > > would be replaced in the medium to long term, I did not care about > > it. Looks like I now need to have a look ;) > > No big deal for me *now*, but it caused pain when I first ran into it. > Anyway, I thought you'd addressed this - about a year ago, maybe? I guess just mostly -- at least it boils down with actions themselves, where it is hard to handle due to the missing well-defined structure of the string. Rainer From joel.merrick at gmail.com Fri Jul 16 12:08:15 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Fri, 16 Jul 2010 11:08:15 +0100 Subject: [rsyslog] MySQL custom filters? In-Reply-To: References: Message-ID: On Fri, Jul 16, 2010 at 6:43 AM, wrote: > On Thu, 15 Jul 2010, Joel Merrick wrote: > >> Hi list, >> >> I'm trying to build a service to enable the quick searching of mail >> logs, for our support team to use. We get quite a lot of log >> generation (about 2G of mysql data a day) >> >> Searching these becomes really inefficient after a while, even though >> there's extra keys and indexes in the db. >> >> I'd like to try and parse the syslog event using rsyslog and get the >> message ID out of the payload and add it as an indexed field, which >> should speed up queries (so we can stitch together a full email >> transaction) > > this shouldn't be _too_ hard, depending on where the message ID is in the > messages you are logging > > just create your own template that writes the message ID as a separate > field. > The position of the message ID's are always pretty consistent but not exactly. I've got a PoC ruby daemon listening on a named pipe and regex'ing out the message ID's already. Shawn's very kindly told me about Solr, so I'm going to give that a whirl today. If I could get away from using the ruby daemon and use rsyslog properly, that'd be good.. however it's working and can easily handle the load The regexp in ruby I'm using is; \w{6}-\w{6}-\w{2} Could this be done for the templates? -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From david at lang.hm Fri Jul 16 19:57:18 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 16 Jul 2010 10:57:18 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103F2C@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103F3F@GRFEXC.intern.adiscon.com><20100713005037.GB3089@brevard.conman.org><20100713062722.GA3959@brevard.conman.org><9B6E2A8877C38245BFB15CC491A11DA7103F99@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FAD@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FB1@GRFEXC.intern.adiscon.com> <4C3ED12B.4080704@jackpot.uk.net><9B6E2A8877C38245BFB15CC491A11DA7103FB6@GRFEXC.intern.adiscon.com> <4C402732.5030806@jackpot.uk.net> <9B6E2A8877C38245BFB15CC491A11DA7103FBB@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang From rgerhards at hq.adiscon.com Fri Jul 16 20:08:46 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 16 Jul 2010 20:08:46 +0200 Subject: [rsyslog] NEW rsyslog.conf format Message-ID: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> In theorie yes, in practice eg inside a password for a db connection. ----- Urspr?ngliche Nachricht ----- Von: david at lang.hm Gesendet: Freitag, 16. Juli 2010 19:57 An: rsyslog-users Betreff: Re: [rsyslog] NEW rsyslog.conf format On Fri, 16 Jul 2010, Rainer Gerhards wrote: >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >> Sent: Friday, July 16, 2010 11:33 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] NEW rsyslog.conf format >> >> Rainer Gerhards wrote: >>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>> >>>> david at lang.hm wrote: >>>>> interesting, I'm not sure that anyone else realized that a config >>>>> option could be split over multiple lines. >>>> I've banged my head on this (end-of-line comments). I believe the >>>> comments problem has been worked around now, but I still make sure >>>> that I don't try to use end-of-line comments anywhere in my >>>> configs, just in case. >>> >>> That's an (one?) anomaly of the current parser. Thinking that it >>> would be replaced in the medium to long term, I did not care about >>> it. Looks like I now need to have a look ;) >> >> No big deal for me *now*, but it caused pain when I first ran into it. >> Anyway, I thought you'd addressed this - about a year ago, maybe? > > I guess just mostly -- at least it boils down with actions themselves, where > it is hard to handle due to the missing well-defined structure of the string. is a # outside of quotes ever valid in an action string? David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From david at lang.hm Sun Jul 18 00:45:46 2010 From: david at lang.hm (david at lang.hm) Date: Sat, 17 Jul 2010 15:45:46 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: On Fri, 16 Jul 2010, Rainer Gerhards wrote: > In theorie yes, in practice eg inside a password for a db connection. how hard would it be to allow quotes around the password? (if this ends up disallowing quotes in the password to the database, that's not too bad a cost) I'm trying to think of if there are some fairly minor changes that could be made that would make it significantly easier for a better parser to be written. changng the config is always a problem, but there are some problems that are much larger than others, and if a minor change would make it much easier to move to a standard parser it may be worth making the breakage in a 5.x or 6.x release (where the new capibilities are introduced so that people can see the advantage of the breakage) David Lang > ----- Urspr?ngliche Nachricht ----- > Von: david at lang.hm > Gesendet: Freitag, 16. Juli 2010 19:57 > An: rsyslog-users > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour >>> Sent: Friday, July 16, 2010 11:33 AM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>> >>> Rainer Gerhards wrote: >>>>> -----Original Message----- From: rsyslog-bounces at lists.adiscon.com >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog-users >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format >>>>> >>>>> david at lang.hm wrote: >>>>>> interesting, I'm not sure that anyone else realized that a config >>>>>> option could be split over multiple lines. >>>>> I've banged my head on this (end-of-line comments). I believe the >>>>> comments problem has been worked around now, but I still make sure >>>>> that I don't try to use end-of-line comments anywhere in my >>>>> configs, just in case. >>>> >>>> That's an (one?) anomaly of the current parser. Thinking that it >>>> would be replaced in the medium to long term, I did not care about >>>> it. Looks like I now need to have a look ;) >>> >>> No big deal for me *now*, but it caused pain when I first ran into it. >>> Anyway, I thought you'd addressed this - about a year ago, maybe? >> >> I guess just mostly -- at least it boils down with actions themselves, where >> it is hard to handle due to the missing well-defined structure of the string. > > is a # outside of quotes ever valid in an action string? > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Jul 19 08:27:52 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 19 Jul 2010 08:27:52 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Sunday, July 18, 2010 12:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > In theorie yes, in practice eg inside a password for a db connection. > > how hard would it be to allow quotes around the password? (if this ends > up > disallowing quotes in the password to the database, that's not too bad > a > cost) > > I'm trying to think of if there are some fairly minor changes that > could > be made that would make it significantly easier for a better parser to > be > written. The real problem is the interface spec: whenever I change the syntax, I also (need to) change the interface spec. That is because the current spec says that everything from first non-whitespace after the filter up to LF needs to be passed to the output module. That's it... So even a minor change invalidates that interface. Given the fact that I know about at least three externally written plugins (which means probably more), I am hesitant to break that part of the spec, at least if I can avoid it. > changng the config is always a problem, but there are some problems > that > are much larger than others, and if a minor change would make it much > easier to move to a standard parser it may be worth making the breakage I agree, but only if unavoidable. As it currently looks, I think I will probably be able to generate a (decently complex) flex/bison parser that processes old and new-style (whatever it be) format. However, moving to flex/bison is considerable work, even if it were crystal-clear what we intend to do. So it sounds very appealing to me to stay within the constraints of the current parser and implement scoping with its help. That is still a lot of work, but much, much less than a full overhaul. Most importantly, it enables us to experimentally extend the config language, see how that works out in practice and *then* decide if we should really pursue that route. If so, we can than look at what exactly it takes to create a new parser subsystem. Of course, while extending the current system, we must keep an eye on potential "flex/bison grammars" and try not to introduce anything new that causes new problems. With the current proposal, I do not see any such problems. This gradual approach has the vast advantage that we get scoping into rsyslog at a far earlier time than when we did the full "right thing". However, the plugin interface will still be broken (I need the push/pop config ability plus config statement type designators), but at a far easier to fix level (from a plugin developer's PoV). > in > a 5.x or 6.x So doing this in a 6.x version sounds like a good thing, as it makes crystal-clear that some important things have changed. So I think you proposal is a very good one ;) Rainer > release (where the new capibilities are introduced so that > people can see the advantage of the breakage) > > David Lang > > > ----- Urspr?ngliche Nachricht ----- > > Von: david at lang.hm > > Gesendet: Freitag, 16. Juli 2010 19:57 > > An: rsyslog-users > > Betreff: Re: [rsyslog] NEW rsyslog.conf format > > > > On Fri, 16 Jul 2010, Rainer Gerhards wrote: > > > >>> -----Original Message----- > >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >>> bounces at lists.adiscon.com] On Behalf Of Mr. Demeanour > >>> Sent: Friday, July 16, 2010 11:33 AM > >>> To: rsyslog-users > >>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>> > >>> Rainer Gerhards wrote: > >>>>> -----Original Message----- From: rsyslog- > bounces at lists.adiscon.com > >>>>> [mailto:rsyslog- bounces at lists.adiscon.com] On Behalf Of Mr. > >>>>> Demeanour Sent: Thursday, July 15, 2010 11:13 AM To: rsyslog- > users > >>>>> Subject: Re: [rsyslog] NEW rsyslog.conf format > >>>>> > >>>>> david at lang.hm wrote: > >>>>>> interesting, I'm not sure that anyone else realized that a > config > >>>>>> option could be split over multiple lines. > >>>>> I've banged my head on this (end-of-line comments). I believe the > >>>>> comments problem has been worked around now, but I still make > sure > >>>>> that I don't try to use end-of-line comments anywhere in my > >>>>> configs, just in case. > >>>> > >>>> That's an (one?) anomaly of the current parser. Thinking that it > >>>> would be replaced in the medium to long term, I did not care about > >>>> it. Looks like I now need to have a look ;) > >>> > >>> No big deal for me *now*, but it caused pain when I first ran into > it. > >>> Anyway, I thought you'd addressed this - about a year ago, maybe? > >> > >> I guess just mostly -- at least it boils down with actions > themselves, where > >> it is hard to handle due to the missing well-defined structure of > the string. > > > > is a # outside of quotes ever valid in an action string? > > > > David Lang > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sean at conman.org Mon Jul 19 22:33:18 2010 From: sean at conman.org (Sean Conner) Date: Mon, 19 Jul 2010 16:33:18 -0400 Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> Message-ID: <20100719203318.GB17467@brevard.conman.org> It was thus said that the Great Rainer Gerhards once stated: > > If so, we can than look at what exactly it takes to create a new parser > subsystem. Of course, while extending the current system, we must keep an eye > on potential "flex/bison grammars" and try not to introduce anything new that > causes new problems. With the current proposal, I do not see any such > problems. The current parser obviously creates some internal structures used by the engine to run. Is this fully documented? If so, what's to keep someone from replacing the current parser with a completely different one that builds the same internal structures? Could you not have different configuration parsers? (issue: how to know which one to use; command line option perhaps? the first line describing which parsing module to use (and if missing, use the original one)?) Such a method might be beneficial to explore alternative configuration files. -spc (Just an idea ... ) From david at lang.hm Mon Jul 19 23:20:49 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Jul 2010 14:20:49 -0700 (PDT) Subject: [rsyslog] NEW rsyslog.conf format In-Reply-To: <20100719203318.GB17467@brevard.conman.org> References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com> <20100719203318.GB17467@brevard.conman.org> Message-ID: On Mon, 19 Jul 2010, Sean Conner wrote: > It was thus said that the Great Rainer Gerhards once stated: >> >> If so, we can than look at what exactly it takes to create a new parser >> subsystem. Of course, while extending the current system, we must keep an eye >> on potential "flex/bison grammars" and try not to introduce anything new that >> causes new problems. With the current proposal, I do not see any such >> problems. > > The current parser obviously creates some internal structures used by the > engine to run. This is an incorrect assumption. the current parser creates some internal structures, but it also executes things immediatly > Is this fully documented? No, it's not fully documented because it's currently up to the individual module to do whatever it wants to do when it sees a config option. It can _do_ something, or it can create a variable that nothing else knows about, or it can change an existing variable. I initially made the same assumption, but Rainer has clarified this in these threads. David Lang > If so, what's to keep someone > from replacing the current parser with a completely different one that > builds the same internal structures? Could you not have different > configuration parsers? (issue: how to know which one to use; command line > option perhaps? the first line describing which parsing module to use (and > if missing, use the original one)?) Such a method might be beneficial to > explore alternative configuration files. > > -spc (Just an idea ... ) > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From akozumpl at redhat.com Tue Jul 20 10:55:18 2010 From: akozumpl at redhat.com (Ales Kozumplik) Date: Tue, 20 Jul 2010 10:55:18 +0200 Subject: [rsyslog] log forwarding through unix sockets Message-ID: <4C456476.4010703@redhat.com> Hi list, I am using rsyslog to forward logs between KVM guest and host machines during the Fedora installation program (aka Anaconda). Details are described here: https://fedoraproject.org/wiki/Anaconda/Logging#Remote_logging_via_virtio, but in the gist: recent QEMU/KVM has a feature using which one can write to a character device on the guest end and read those data from a unix socket on the host end. We are tying to use this facility to forward the installation logs to the host. Two rsyslogd instances are involved in the process: the sending one on the guest end and the receiving one on the host end (which parses the incoming messages' headers and files the messages into different files). Unfortunately I've run into a couple of issues trying to set up the forwarding using this mechanism: 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to read data from SOCK_DGRAM. This has two consequences: first, to be able to attach rsyslog on the host end one first needs to copy the data between the two socket types, e.g. using socat. Second, messages longer than 1024 characters are sometimes split into two. The second message is thus missing the syslog header and the receiving rsyslogd doesn't know where to file it. Is there a recommended workaround for those things (maybe a parameter I overlooked in the docs tellling rsyslogd to use SOCK_STREAM)? 2) I seem to be unable to get the forwarding template right. For network forwarding (which is also supported in Anaconda), simply putting no explicit formatting does the trick: *.* @@ some.host The received logs can be matched for anything: severity, facility, hostname and programname. This is not the case when logs are forwarded through the character device: *.* /dev/virtio_ports/port_name Using the implicit formatting the receiving syslog won't parse the programname. I tried using the predefined ForwardFormat but then the receiving rsyslogd parsed hostname as the programname and the programname remains part of the final message. Is that the expected behavior? What worked for me in the end was creating a template based on the ForwardFormat but with the %HOSTNAME% part omitted: I can live with that for know since I know the message came from a certain socket so it can be only one host. Still: it seems weird there's no forwarding format provided that would retain 100% of the information parsable by another rsyslog reading from a socket. I'm probably just missing something? Thanks for any reply about this. Ales Kozumplik From rgerhards at hq.adiscon.com Tue Jul 20 15:40:17 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Jul 2010 15:40:17 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 19, 2010 11:21 PM > To: rsyslog-users > Subject: Re: [rsyslog] NEW rsyslog.conf format > > On Mon, 19 Jul 2010, Sean Conner wrote: > > > It was thus said that the Great Rainer Gerhards once stated: > >> > >> If so, we can than look at what exactly it takes to create a new > parser > >> subsystem. Of course, while extending the current system, we must > keep an eye > >> on potential "flex/bison grammars" and try not to introduce anything > new that > >> causes new problems. With the current proposal, I do not see any > such > >> problems. > > > > The current parser obviously creates some internal structures used > by the > > engine to run. > > This is an incorrect assumption. the current parser creates some > internal > structures, but it also executes things immediatly > > > Is this fully documented? > > No, it's not fully documented because it's currently up to the > individual > module to do whatever it wants to do when it sees a config option. It > can > _do_ something, or it can create a variable that nothing else knows > about, > or it can change an existing variable. > > I initially made the same assumption, but Rainer has clarified this in > these threads. David is absolutely right in his posting. But let me add some more explanation. Rsyslog's config parser was never "designed". We inherited it from sysklogd and it probably is one of the last remaining parts that actually have sysklogd heritage at all. It is not even a real parser, at least if you make some usual assumptions of what a language parser does. This all is part of the problem, and this also is the reason why it is considerable effort to change the way the config system operates. I'd really love to have what Sean assumes we have. This would be a big step into the right direction. But even if we had it, I don't think that would change the discussion. Even though loadable parsers could then be easily added, I doubt someone except me will ever write on. Look at the situation of message parsers and such -- while it is fairly simple to create one, most people are hesitant to do it (for output plugins it is even more simple, and there we see third parties!). A parser is not trivial, so I don't expect to see someone actually write one (vs. claim he would write one if the interface were there). I, on the other hand, have no motivation at all to write multiple parsers - just duplicated (aka wasted) effort. So the discussion about which parsers is the first (and thus potentially only) one is very vital. Just for the records: the current route probably is to stay with the current config system, introduce scoping and *then* think about how the system could be modified. Rainer From tbergfeld at hq.adiscon.com Wed Jul 21 15:06:02 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 21 Jul 2010 15:06:02 +0200 Subject: [rsyslog] rsyslog 5.5.6 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.6, a member of the devel branch. The new release provides exciting performance enhancements: on multicore-machines it can be many times faster than version 5.5.5 (which already was quite fast). Most importantly, the enhancement provides much better scalability, so adding many additional core gains much more speedup than with any previous version. A new concept of "strgen" modules has been implemented, which permit to use high speed C code as templates. Also, support for malformed "last message repated n times" messages, as emited by some syslogds, has been added in form of a custom message parser. There are also a couple of bugfixes and minor improvements. See ChangeLog for more details. ChangeLog: http://www.rsyslog.com/changelog-for-5-5-6-devel/ Download: http://www.rsyslog.com/rsyslog-5-5-6-devel As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From friedl at hq.adiscon.com Wed Jul 21 15:55:26 2010 From: friedl at hq.adiscon.com (Florian Riedl) Date: Wed, 21 Jul 2010 15:55:26 +0200 Subject: [rsyslog] New rsyslog website is live! Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Dear rsyslog folks, The Adiscon GmbH is proud to announce that today we have made the new rsyslog website live. If you find something missing or not working correctly, please let us know. Further, we are open to suggestions to make the new website even better. We will do some last finishing touches to it currently as well, therefore sometimes some things might not work correctly. Since we did not drag over the complete old content like old news releases, you can still get find it at http://old.rsyslog.com. We hope you have a good experience with the new website. Best regards, Florian Riedl Adiscon -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From lists at luigirosa.com Thu Jul 22 05:53:38 2010 From: lists at luigirosa.com (Luigi Rosa) Date: Thu, 22 Jul 2010 05:53:38 +0200 Subject: [rsyslog] New rsyslog website is live! In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FD9@GRFEXC.intern.adiscon.com> Message-ID: <4C47C0C2.5010806@luigirosa.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Riedl said the following on 21/07/10 15:55: > If you find something missing or not working correctly, please let us know. The style of both Google ad does not display well on Firefox+Ubuntu The right coloumn of ad is too big, the row below the three boxes overlaps the other elements. http://luigirosa.com/rsyslog.png Ciao, luigi - -- / +--[Luigi Rosa]-- \ There is a greater darkness than the one we fight. It is the darkness of the soul that has lost its way. The war we fight is not against powers and principalities, it is against chaos and despair. Greater than the death of flesh is the death of hope, the death of dreams. Against this peril we can never surrender. The future is all around us, waiting, in moments of transition, to be born in moments of revelation. No one knows the shape of that future or where it will take us. We know only that it is always born in pain. --G'Kar, "Z'ha'dum" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHwL8ACgkQ3kWu7Tfl6ZSi1QCfUkQXhzdCRzcdu81gEp43bqCg N7oAnipWupEp16ILTl4omY5jdu9bncG+ =ELlp -----END PGP SIGNATURE----- From rgerhards at hq.adiscon.com Fri Jul 23 17:43:09 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Jul 2010 17:43:09 +0200 Subject: [rsyslog] NEW rsyslog.conf format References: <00ef01cb2511$ed126613$100013ac@intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7103FBD@GRFEXC.intern.adiscon.com><20100719203318.GB17467@brevard.conman.org> <9B6E2A8877C38245BFB15CC491A11DA7103FC5@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FED@GRFEXC.intern.adiscon.com> For those interested: I have begun to implement action scoping. A snapshot with partial functionality is available at http://git.adiscon.com/?p=rsyslog.git;a=shortlog;h=refs/heads/newconf It does NOT yet include the necessary output plugin interface change (or updated plugins), but it implements $Begin action $End action $StrictScoping [on/off] -- off default So if you want to play a bit with it, feel free to do so. Note that it disallows global statements within action scope and in overall has somewhat better detection of user errors (these are easier to detect when scoping is used). Note that scoping is purely optional: if not enabled, it will not be used. So any current rsyslog.conf remains valid. I will see that I change the projects's output plugins next week, and will possibly then make an experimental release. I just thought I let all of you know. Rainer From david at lang.hm Sat Jul 24 06:57:26 2010 From: david at lang.hm (david at lang.hm) Date: Fri, 23 Jul 2010 21:57:26 -0700 (PDT) Subject: [rsyslog] mark messages Message-ID: I have a server sending me bad data, so I implmented the following rule to trap log messaages where the hostname isn't an IP address or name :hostname, regex, "[a-zA-Z\.]" /file & ~ *.* /file2;fixformat unfortunantly it turns out that this also traps mark messages. the %rawmsg% for mark is just "-- MARK --" and apparently hostname is not populated (fromhost-ip is 127.0.0.1) I do have -x on the rsyslog command line, so it is not doing DNS resolution, but it should come up with either the local hostname or 127.0.0.1 as the hostname for locally generated messages. Either one of these would match my regex as being a 'normal' message This box is currently running 5.5.3 David Lang From rgerhards at hq.adiscon.com Mon Jul 26 14:18:20 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 14:18:20 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Hi David, I have just checked immark, it uses a function to log internal messages (that alone is questionable, but stems back to its history). However, this function should properly populate hostname, so it looks like something else is broken. Will check and keep you updated. Thanks for the info, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Jul 26 15:18:44 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:18:44 +0200 Subject: [rsyslog] mark messages References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FF9@GRFEXC.intern.adiscon.com> David, I now checked > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Saturday, July 24, 2010 6:57 AM > To: rsyslog-users > Subject: [rsyslog] mark messages > > I have a server sending me bad data, so I implmented the following rule > to > trap log messaages where the hostname isn't an IP address or name > > :hostname, regex, "[a-zA-Z\.]" /file > & ~ > *.* /file2;fixformat > > unfortunantly it turns out that this also traps mark messages. > > the %rawmsg% This is a special case where %rawmsg% does not contain everything. Internal messages generate the necessary in-memory structure, but do not try to emulate %rawmsg% in all its glory (but it may be worth thinking about that). HOWEVER, fromhost and fromhost-ip are properly populated. So the filter should work, assuming that the hostname actually matches the regex. I suggest that you use the canned RSYSLOG_DebugFormat template so that we can see what exactly is stored in your in-memory message representation. Rainer > for mark is just "-- MARK --" and apparently hostname is > not > populated (fromhost-ip is 127.0.0.1) > > I do have -x on the rsyslog command line, so it is not doing DNS > resolution, but it should come up with either the local hostname or > 127.0.0.1 as the hostname for locally generated messages. Either one of > these would match my regex as being a 'normal' message > > This box is currently running 5.5.3 > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:18:02 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:18:02 +0200 Subject: [rsyslog] Rsyslog Version Comparison Message-ID: <4C4D8B0A.8090503@kinzesberg.de> Hi folks, I have searched the new site for a comparison of the major version of rsyslog (3, 4, 5), but found nothing. Only information seems to be the change logs, but I would not like to parse through several dozen documents and work on a matrix for some hours, so ... Is there an overview document relating versions and features? Any hint or help is appreciated. Dirk From rgerhards at hq.adiscon.com Mon Jul 26 15:27:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Jul 2010 15:27:31 +0200 Subject: [rsyslog] Rsyslog Version Comparison References: <4C4D8B0A.8090503@kinzesberg.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> As far as I know, there is no such comparison. But I agree this would probably be very useful. I'll ask the web folks if they have time to generate such a page (maybe not with all details, but the more important features, at least for a start). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz > Sent: Monday, July 26, 2010 3:18 PM > To: rsyslog-users > Subject: [rsyslog] Rsyslog Version Comparison > > Hi folks, > > I have searched the new site for a comparison of the major version of > rsyslog (3, 4, 5), but found nothing. Only information seems to be the > change logs, but I would not like to parse through several dozen > documents and work on a matrix for some hours, so ... > > Is there an overview document relating versions and features? > > Any hint or help is appreciated. > > Dirk > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From dirk.schulz at kinzesberg.de Mon Jul 26 15:35:25 2010 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 26 Jul 2010 15:35:25 +0200 Subject: [rsyslog] Rsyslog Version Comparison In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> References: <4C4D8B0A.8090503@kinzesberg.de> <9B6E2A8877C38245BFB15CC491A11DA7103FFA@GRFEXC.intern.adiscon.com> Message-ID: <4C4D8F1D.8000507@kinzesberg.de> thanks a lot, that would be great! dirk Am 26.07.10 15:27, schrieb Rainer Gerhards: > As far as I know, there is no such comparison. But I agree this would > probably be very useful. I'll ask the web folks if they have time to generate > such a page (maybe not with all details, but the more important features, at > least for a start). > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Dirk H. Schulz >> Sent: Monday, July 26, 2010 3:18 PM >> To: rsyslog-users >> Subject: [rsyslog] Rsyslog Version Comparison >> >> Hi folks, >> >> I have searched the new site for a comparison of the major version of >> rsyslog (3, 4, 5), but found nothing. Only information seems to be the >> change logs, but I would not like to parse through several dozen >> documents and work on a matrix for some hours, so ... >> >> Is there an overview document relating versions and features? >> >> Any hint or help is appreciated. >> >> Dirk >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Mon Jul 26 20:25:40 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 26 Jul 2010 11:25:40 -0700 (PDT) Subject: [rsyslog] mark messages In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: On Mon, 26 Jul 2010, Rainer Gerhards wrote: > Hi David, > > I have just checked immark, it uses a function to log internal messages (that > alone is questionable, but stems back to its history). However, this function > should properly populate hostname, so it looks like something else is broken. > Will check and keep you updated. you may need to explicitly check what happens when -x is provided. David Lang > Thanks for the info, > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Saturday, July 24, 2010 6:57 AM >> To: rsyslog-users >> Subject: [rsyslog] mark messages >> >> I have a server sending me bad data, so I implmented the following rule >> to >> trap log messaages where the hostname isn't an IP address or name >> >> :hostname, regex, "[a-zA-Z\.]" /file >> & ~ >> *.* /file2;fixformat >> >> unfortunantly it turns out that this also traps mark messages. >> >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname is >> not >> populated (fromhost-ip is 127.0.0.1) >> >> I do have -x on the rsyslog command line, so it is not doing DNS >> resolution, but it should come up with either the local hostname or >> 127.0.0.1 as the hostname for locally generated messages. Either one of >> these would match my regex as being a 'normal' message >> >> This box is currently running 5.5.3 >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Jul 27 09:29:28 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Jul 2010 09:29:28 +0200 Subject: [rsyslog] mark messages References: <9B6E2A8877C38245BFB15CC491A11DA7103FF3@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104002@GRFEXC.intern.adiscon.com> David, have you seen my other message where I asked to check all properties? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Monday, July 26, 2010 8:26 PM > To: rsyslog-users > Subject: Re: [rsyslog] mark messages > > On Mon, 26 Jul 2010, Rainer Gerhards wrote: > > > Hi David, > > > > I have just checked immark, it uses a function to log internal > messages (that > > alone is questionable, but stems back to its history). However, this > function > > should properly populate hostname, so it looks like something else is > broken. > > Will check and keep you updated. > > you may need to explicitly check what happens when -x is provided. > > David Lang > > > > Thanks for the info, > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Saturday, July 24, 2010 6:57 AM > >> To: rsyslog-users > >> Subject: [rsyslog] mark messages > >> > >> I have a server sending me bad data, so I implmented the following > rule > >> to > >> trap log messaages where the hostname isn't an IP address or name > >> > >> :hostname, regex, "[a-zA-Z\.]" /file > >> & ~ > >> *.* /file2;fixformat > >> > >> unfortunantly it turns out that this also traps mark messages. > >> > >> the %rawmsg% for mark is just "-- MARK --" and apparently hostname > is > >> not > >> populated (fromhost-ip is 127.0.0.1) > >> > >> I do have -x on the rsyslog command line, so it is not doing DNS > >> resolution, but it should come up with either the local hostname or > >> 127.0.0.1 as the hostname for locally generated messages. Either one > of > >> these would match my regex as being a 'normal' message > >> > >> This box is currently running 5.5.3 > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Tue Jul 27 13:51:21 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Tue, 27 Jul 2010 13:51:21 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors Message-ID: I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. I'm trying to use the rsyslog to send syslog messages to an existing oracle db. I'm facing these problems, and don't really know where to begin. I've setup the correct oracle environment during startup of the rsyslog and it got me errors seen below. I have done the same trying to build the rsyslog using "./configure --enable-oracle", then "make", "make install" with the oracle environment setup, but got same errors seen below. Can anyone help me solve this? errors while building rsyslog's plugin omoracle: make[2]: Entering directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' CC omoracle_la-omoracle.lo omoracle.c: In function ?prepare_statement?: omoracle.c:254: warning: pointer targets in passing argument 3 of ?OCIStmtPrepare? differ in signedness omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from incompatible pointer type omoracle.c: In function ?createInstance?: omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? differ in signedness omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? differ in signedness omoracle.c: In function ?log_detailed_err?: omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from incompatible pointer type omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from incompatible pointer type omoracle.c: In function ?tryResume?: omoracle.c:461: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?startSession?: omoracle.c:481: warning: pointer targets in passing argument 5 of ?OCISessionGet? differ in signedness omoracle.c: In function ?parseSelectorAct?: omoracle.c:517: warning: implicit declaration of function ?cflineParseTemplateName? CCLD omoracle.la make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' Making all in tests syslog entries when starting rsyslog daemon: 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = /proc/kmsg started. 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: TNS:could not resolve the connect identifier specified 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle session 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line without actions will be discarded 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2124 ] Debug statements checking rsyslog's configuration: 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' 1494.718302000:2abb22fc5ac0: loading module '/usr/local/lib/rsyslog/omoracle.so' 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry -- Best regards! Damien From mrdemeanour at jackpot.uk.net Tue Jul 27 14:30:08 2010 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 27 Jul 2010 13:30:08 +0100 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: References: Message-ID: <4C4ED150.4070603@jackpot.uk.net> Damjan ?iberna wrote: > I've installed oracle-instantclient-basic-10.2.0.4-1.x86_64 > and oracle-instantclient-devel-10.2.0.4-1.x86_64 and jdk-6u21-linux-x64. > I'm trying to use the rsyslog to send syslog messages to an existing oracle > db. I'm facing these problems, and don't really know where to begin. I've > setup the correct oracle environment during startup of the rsyslog and it > got me errors seen below. I have done the same trying to build the rsyslog > using "./configure --enable-oracle", then "make", "make install" with the > oracle environment setup, but got same errors seen below. > > Can anyone help me solve this? I'm very much not up-to-date on Oracle, and I've never used instantclient. I've never tried to use rsyslog with Oracle either. Inline remarks [below] may therefore be wide of the mark. However it looks to me that you have a problem with your Oracle connect string; a problem with your rsyslog config; and a problem with your ORACLE_HOME. > > > errors while building rsyslog's plugin omoracle: > > make[2]: Entering directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > CC omoracle_la-omoracle.lo > omoracle.c: In function ?prepare_statement?: > omoracle.c:254: warning: pointer targets in passing argument 3 of > ?OCIStmtPrepare? differ in signedness > omoracle.c:268: warning: passing argument 4 of ?OCIBindDynamic? from > incompatible pointer type > omoracle.c: In function ?createInstance?: > omoracle.c:301: warning: pointer targets in passing argument 1 of ?strlen? > differ in signedness > omoracle.c:301: warning: pointer targets in passing argument 1 of ?__strdup? > differ in signedness > omoracle.c: In function ?log_detailed_err?: > omoracle.c:356: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:359: warning: passing argument 2 of ?OCIHandleAlloc? from > incompatible pointer type > omoracle.c:365: warning: passing argument 4 of ?OCIParamGet? from > incompatible pointer type > omoracle.c: In function ?tryResume?: > omoracle.c:461: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?startSession?: > omoracle.c:481: warning: pointer targets in passing argument 5 of > ?OCISessionGet? differ in signedness > omoracle.c: In function ?parseSelectorAct?: > omoracle.c:517: warning: implicit declaration of function > ?cflineParseTemplateName? > CCLD omoracle.la > make[2]: Leaving directory `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > Making all in tests Those all look like warnings, not errors. Did the module get built? > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.089573+02:00 paris kernel: imklog 5.4.0, log source = > /proc/kmsg started. > 2010-07-27T08:20:02.089665+02:00 paris rsyslogd: [origin software="rsyslogd" > swVersion="5.4.0" x-pid="11839" x-info="http://www.rsyslog.com"] start > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: ORA-12154: > TNS:could not resolve the connect identifier specified http://ora-12154.ora-code.com/ Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached. > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > session > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured in > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > without actions will be discarded Defective rsyslog.conf. > 2010-07-27T08:20:02.089442+02:00 paris rsyslogd-2124: CONFIG ERROR: could > not interpret master config file '/etc/rsyslog.conf'. [try > http://www.rsyslog.com/e/2124 ] > > > Debug statements checking rsyslog's configuration: > > 1494.718276000:2abb22fc5ac0: cfline: '$ModLoad omoracle' > 1494.718290000:2abb22fc5ac0: Requested to load module 'omoracle' > 1494.718302000:2abb22fc5ac0: loading module > '/usr/local/lib/rsyslog/omoracle.so' > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html The poster says: tora: symbol lookup error: /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: nltrc_entry [...] When I switch ORACLE_HOME to point to a full install of Oracle 10g, the problem goes away, and TOra launches normally. HTH, -- MrD. From damjanster at gmail.com Wed Jul 28 10:10:22 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 10:10:22 +0200 Subject: [rsyslog] rsyslog 5.4.0 omoracle errors In-Reply-To: <4C4ED150.4070603@jackpot.uk.net> References: <4C4ED150.4070603@jackpot.uk.net> Message-ID: > > However it looks to me that you have a problem with your Oracle connect > string; a problem with your rsyslog config; and a problem with your > ORACLE_HOME. > The ORACLE_HOME, TNS_ADMIN, LD_LIBRARY_PATH variables get set just before the rsyslogd is run. ORACLE_HOME is set to the production installation of our database - not to instantclinet's home. > > > > > > errors while building rsyslog's plugin omoracle: > > > CCLD omoracle.la > > make[2]: Leaving directory > `/usr/src/rsyslog/rsyslog-5.4.0/plugins/omoracle' > > Making all in tests > > Those all look like warnings, not errors. Did the module get built? > The module got built and installed. It's just not loading. > > > > > > syslog entries when starting rsyslog daemon: > > 2010-07-27T08:20:02.074395+02:00 paris rsyslogd: Error message: > ORA-12154: > > TNS:could not resolve the connect identifier specified > > http://ora-12154.ora-code.com/ > This error is interesting in its own, but since the omoracle plugin doesn't get loaded the $Om... parameters get ignored - as I can see from the debug output running rsyslog. > > > 2010-07-27T08:20:02.074413+02:00 paris rsyslogd: Unable to start Oracle > > session > > 2010-07-27T08:20:02.074430+02:00 paris rsyslogd: OCI INVALID HANDLE > > 2010-07-27T08:20:02.074468+02:00 paris rsyslogd: the last error occured > in > > /etc/rsyslog.conf, line 19:"*.* :omoracle:;TestStmt" > > 2010-07-27T08:20:02.089085+02:00 paris rsyslogd: warning: selector line > > without actions will be discarded > > Defective rsyslog.conf. > Not 100% sure, but I believe this is due to omoracle not loading. > > 1494.740232000:2abb22fc5ac0: Called LogError, msg: could not load module > > '/usr/local/lib/rsyslog/omoracle.so', dlopen: /usr/lib/oracle/ > > 10.2.0.4/client64/lib/libnnz10.so: undefined symbol: nltrc_entry > > > http://old.nabble.com/Building-tora-2.0.0-0.3054svn.el5.src.rpm-on-FC9-td19979563.html > > The poster says: > tora: symbol lookup error: > /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so: undefined symbol: > nltrc_entry > [...] > When I switch ORACLE_HOME to point to a full install of Oracle 10g, > the problem goes away, and TOra launches normally. > An interesting point. As I've mentioned before, these variables are set like this: export LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.4/client64/lib export PATH=/ust/lib/oracle/10.2.0.4/client64:/usr/local/bin:$PATH export TNS_ADMIN=/usr/lib/oracle/10.2.0.4/client64 export ORAENV_ASK=NO export ORACLE_SID=dbase . oraenv unset ORAENV_ASK ORACLE_HOME gets set via oraenv to the production database path - not instantclient's. The database in question is verison 11.2G, but this should not be a problem. Any help is much apprechiated. From damjanster at gmail.com Wed Jul 28 15:35:51 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Wed, 28 Jul 2010 15:35:51 +0200 Subject: [rsyslog] OmoracleStatement format Message-ID: I'm trying to get as much valuable info into our oracledb as possible for further analysis. This is what I came up with so far: $template OmoracleStatement,"INSERT INTO SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message)" $template TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost-ip%%syslogfacility%%syslogseverity%%msg%" *.* :omoracle:;TestStmt These statements don't really work well: 1. timestamp ~ timereported - there's no reference on the web site about how different options format the output. I'd love to have the full-form date&time format, but without the letter "T" in the middle, since Oracle doesn't know how to handle it. The above values string is a workaround, but I'm afraid it's too slow to process great amounts of entries. 2. hostname doesn't get written - I only get 127.0.0.1 3. hostip - only gets written when messages arrive from localhost: 127.0.0.1 4. facility - gets written correctly 5. severity - the %msg% value gets written into this column 6. message - always empty I'm trying to centralize syslog from all surrounding servers. Only the central server uses rsyslog, all the rest use the plain syslog daemon. Should I replace syslog with rsyslog on the surrounding servers to get this to work? Is there some place to get some better reference for the rsyslog strings and it's results? Is it possible to log the exact values that omoracle tries to commit to the database? -- Best regards! Damien From rgerhards at hq.adiscon.com Wed Jul 28 15:42:22 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 28 Jul 2010 15:42:22 +0200 Subject: [rsyslog] OmoracleStatement format References: Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> I have no idea on omoracle, but I can comment on the "normal" rsyslog stuff... > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Wednesday, July 28, 2010 3:36 PM > To: rsyslog-users > Subject: [rsyslog] OmoracleStatement format > > I'm trying to get as much valuable info into our oracledb as possible > for > further analysis. This is what I came up with so far: > > > $template OmoracleStatement,"INSERT INTO > SYSLOG(ts,hostname,hostip,facility,severity,message) VALUES > (to_timestamp_tz(substr(:ts, 1, 10) || ' ' || substr(:ts, 12), 'YYYY- > MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostname,:hostip,:facility,:severity,:message) > " > $template > TestStmt,"%timereported:::date-rfc3339%%hostname%%fromhost- > ip%%syslogfacility%%syslogseverity%%msg%" > *.* :omoracle:;TestStmt > > These statements don't really work well: > 1. timestamp ~ timereported - there's no reference on the web site > about how > different options format the output. I'd love to have the full-form > date&time format, but without the letter "T" in the middle, since > Oracle > doesn't know how to handle it. The above values string is a workaround, > but > I'm afraid it's too slow to process great amounts of entries. I think it would be best to split the RFC3339 date via the property replacer (using start and end position) and then feed this to omoracle. The full doc on property replacer is here: http://www.rsyslog.com/doc/property_replacer.html > > 2. hostname doesn't get written - I only get 127.0.0.1 It would be useful to write a quick debug file *.* /var/log/debug.log;RSYSLOG_DebugFormat This shows what exactly is stored in which property and can probably used to solve the question what exactly happens. > > 3. hostip - only gets written when messages arrive from localhost: > 127.0.0.1 > > 4. facility - gets written correctly > > 5. severity - the %msg% value gets written into this column > > 6. message - always empty see 2. > I'm trying to centralize syslog from all surrounding servers. Only the > central server uses rsyslog, all the rest use the plain syslog daemon. > Should I replace syslog with rsyslog on the surrounding servers to get > this > to work? That's probably not necessary, but let's see the result of 2. > Is there some place to get some better reference for the rsyslog > strings and > it's results? see link above > > Is it possible to log the exact values that omoracle tries to commit to > the > database? you can write to a file with the same template you use for omoracle. But 2. should be sufficient. Rainer > > > -- > Best regards! > Damien > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Thu Jul 29 03:43:40 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Wed, 28 Jul 2010 21:43:40 -0400 Subject: [rsyslog] How to write to a local socket? Message-ID: I just configured a privilege-separated RSyslog instance, and it's running fine. To read the kernel message log, I'm running a second daemon instance as root, along the lines described in the wiki. Currently, my root instance forwards messages via UDP to unprivileged instance's localhost-only listener. It works, but I'm not entirely happy with it. I'd like to forward via a local UNIX domain socket, instead. I think I understand how to configure the 'imuxsock' module so my unprivileged instance reads from a non-standard socket location. But I can't figure out how to tell my root instance to forward via a local domain socket. Is this possible? If so, how? Ryan B. Lynch ryan.b.lynch at gmail.com From sledz at dresearch.de Thu Jul 29 09:17:00 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 09:17:00 +0200 Subject: [rsyslog] Buggy pipe behaviour Message-ID: <4C512AEC.9070301@dresearch.de> We need to configure a pipe to connect the output to a special application. Our configuration looks like this: ----->snip<-------- $ModLoad imuxsock $ModLoad imklog $ModLoad immark $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $RepeatedMsgReduction on *.* |/var/run/syslog2thinfs ... some other channels ----->snap<-------- The fifo is created and has sufficient rights. Now we can see the following behaviour: No receiver connected to the pipe, rsyslog writes messages into it Receiver is connected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (just a few) Receiver is reconnected, queued messages are read -> fine Receiver is disconnected, rsyslog continues writing messages into it (more than the pipe capacity?) Receiver is reconnected, *some queued messages* are read (but only up to the pipe capacity?) After this *no more messages* reach the end of the pipe. Disconnect/reconnect the receiver makes no difference. -> bad :( I believe this is a bug. May be some messages get lost because there is no place for intermediate storage. But after reconnecting the receiver new messages should pass the pipe again. Right? We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour using the following shell snippets. Sender: ----->snip<-------- i=0;while true; do logger -t count $i; i=$(($i+1)); done ----->snap<-------- Receiver: ----->snip<-------- while true; do cat /var/run/syslog2thinfs ; done ----->snap<-------- Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 10:46:18 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 10:46:18 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> This sounds like intended behavior. When an action fails (pipe fails when nobody reads and it is tried to write to it), rsyslog retries the configured number of times and then suspends the action for the configured period (at least I think it is configurable, you need to look up the details). Only after this period the action is retried. If it fails again, it is re-suspended, but this time with a longer suspension period. This is done so that rsyslog does not spent a lot of time on actions known to be failing. >From what you wrote, I think your use case would probably better be served by omprog, but I may be wrong. If you think about this route, you need to know that someone requested the functionality, but was never seen when it was done ;) So the module is only barely tested. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 9:17 AM > To: rsyslog ML > Subject: [rsyslog] Buggy pipe behaviour > > We need to configure a pipe to connect the output to a special > application. Our configuration looks like this: > > ----->snip<-------- > $ModLoad imuxsock > $ModLoad imklog > $ModLoad immark > > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat > > $RepeatedMsgReduction on > > *.* |/var/run/syslog2thinfs > > ... some other channels > ----->snap<-------- > > The fifo is created and has sufficient rights. > > Now we can see the following behaviour: > > No receiver connected to the pipe, rsyslog writes messages into it > > Receiver is connected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (just a few) > > Receiver is reconnected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (more than the pipe capacity?) > > Receiver is reconnected, *some queued messages* are read (but only up > to the pipe capacity?) > > After this *no more messages* reach the end of the pipe. > Disconnect/reconnect the receiver makes no difference. -> bad :( > > I believe this is a bug. May be some messages get lost because there is > no place for intermediate storage. But after reconnecting the receiver > new messages should pass the pipe again. Right? > > We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour > using the following shell snippets. > > Sender: > ----->snip<-------- > i=0;while true; do logger -t count $i; i=$(($i+1)); done > ----->snap<-------- > > Receiver: > ----->snip<-------- > while true; do cat /var/run/syslog2thinfs ; done > ----->snap<-------- > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 12:33:26 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:33:26 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> Message-ID: <4C5158F6.3060702@dresearch.de> Am 29.07.2010 10:46, schrieb Rainer Gerhards: > This sounds like intended behavior. When an action fails (pipe fails when > nobody reads and it is tried to write to it), rsyslog retries the configured > number of times and then suspends the action for the configured period (at > least I think it is configurable, you need to look up the details). Only > after this period the action is retried. If it fails again, it is > re-suspended, but this time with a longer suspension period. This is done so > that rsyslog does not spent a lot of time on actions known to be failing. So you say, if i wait long enough the messages should receive the end of the pipe? Are there some related debug printouts i can search for? Can you give some hints to the related configuration parameters (URL or keyword). Unfortunately the manual is not very helpful here. > From what you wrote, I think your use case would probably better be served by > omprog, but I may be wrong. If you think about this route, you need to know > that someone requested the functionality, but was never seen when it was done > ;) So the module is only barely tested. Same wish. Where can i read more about omprog? Regards, Steffen From rgerhards at hq.adiscon.com Thu Jul 29 12:43:06 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:43:06 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 12:33 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > This sounds like intended behavior. When an action fails (pipe fails > when > > nobody reads and it is tried to write to it), rsyslog retries the > configured > > number of times and then suspends the action for the configured > period (at > > least I think it is configurable, you need to look up the details). > Only > > after this period the action is retried. If it fails again, it is > > re-suspended, but this time with a longer suspension period. This is > done so > > that rsyslog does not spent a lot of time on actions known to be > failing. > > So you say, if i wait long enough the messages should receive the end > of the pipe? Yes, that's what I assume. > > Are there some related debug printouts i can search for? Search for "suspend", that should bring up a couple of messages. > > Can you give some hints to the related configuration parameters (URL or > keyword). Unfortunately the manual is not very helpful here. See http://www.rsyslog.com/doc/rsyslog_conf_global.html quick check brings up that $ActionResumeRetryCount $ACtionREsumeInterval Is relevant > > > From what you wrote, I think your use case would probably better be > served by > > omprog, but I may be wrong. If you think about this route, you need > to know > > that someone requested the functionality, but was never seen when it > was done > > ;) So the module is only barely tested. > > Same wish. Where can i read more about omprog? I thought I had writen some doc before I learned that this work was not being used by the original requester. I just checked, but it does not seem so. So it is probably best to look at the source. Rainer > > Regards, > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 12:46:10 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 12:46:10 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> This may also be of interest: http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982. html Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 12:43 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 12:33 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 10:46, schrieb Rainer Gerhards: > > > This sounds like intended behavior. When an action fails (pipe > fails > > when > > > nobody reads and it is tried to write to it), rsyslog retries the > > configured > > > number of times and then suspends the action for the configured > > period (at > > > least I think it is configurable, you need to look up the details). > > Only > > > after this period the action is retried. If it fails again, it is > > > re-suspended, but this time with a longer suspension period. This > is > > done so > > > that rsyslog does not spent a lot of time on actions known to be > > failing. > > > > So you say, if i wait long enough the messages should receive the end > > of the pipe? > > Yes, that's what I assume. > > > > > Are there some related debug printouts i can search for? > > Search for "suspend", that should bring up a couple of messages. > > > > > Can you give some hints to the related configuration parameters (URL > or > > keyword). Unfortunately the manual is not very helpful here. > > See > http://www.rsyslog.com/doc/rsyslog_conf_global.html > > quick check brings up that > $ActionResumeRetryCount > $ACtionREsumeInterval > > Is relevant > > > > > > From what you wrote, I think your use case would probably better be > > served by > > > omprog, but I may be wrong. If you think about this route, you need > > to know > > > that someone requested the functionality, but was never seen when > it > > was done > > > ;) So the module is only barely tested. > > > > Same wish. Where can i read more about omprog? > > I thought I had writen some doc before I learned that this work was not > being > used by the original requester. I just checked, but it does not seem > so. So > it is probably best to look at the source. > > Rainer > > > > Regards, > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From joel.merrick at gmail.com Thu Jul 29 12:53:13 2010 From: joel.merrick at gmail.com (Joel Merrick) Date: Thu, 29 Jul 2010 11:53:13 +0100 Subject: [rsyslog] Problem with mysql template Message-ID: Hi all, I'm trying to create a very quick mail log searching solution. The idea is to pre-hash the database by using the last 2 alpha-numeric characters on the message id. This isn't inserting to the database and I can't think why.. I've already built the tables with the structure logs-aa.. logs-ZZ etc.. $template OurDBLog,"INSERT INTO logs-'%msg:R,ERE,1,NULL:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-([A-Za-z0-9]{2})--end%' (messageid, host, \ send_host, created_at, payload, subject) values \ ('%msg:R,ERE,0,ZERO:[A-Za-z0-9]{6}-[A-Za-z0-9]{6}-[A-Za-z0-9]{2}--end%','%HOSTNAME%', '%msg:R,ERE,0,ZERO:H=.*\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}]--end%', \ '%timegenerated:::date-mysql%', '%msg%', '%msg:R,ERE,1,ZERO:T="(.+)"--end%')",SQL Any idea? On a side note, how can I get extra verbosity out of rsyslog so I'm not blindly trying to insert and then check via mysql Cheers, Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge' From sledz at dresearch.de Thu Jul 29 12:58:21 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 12:58:21 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com><4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104020@GRFEXC.intern.adiscon.com> Message-ID: <4C515ECD.6060109@dresearch.de> Am 29.07.2010 12:46, schrieb Rainer Gerhards: > This may also be of interest: > > http://kb.monitorware.com/problem-to-migrate-from-syslog-ng-to-rsyslog-t8982.html General Error Language file ./language/en/404error.php couldn't be opened. Please notify the board administrator or webmaster: alorbach at adiscon.com :( From sledz at dresearch.de Thu Jul 29 13:13:04 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 13:13:04 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> Message-ID: <4C516240.3000200@dresearch.de> Am 29.07.2010 12:43, schrieb Rainer Gerhards: >>> This sounds like intended behavior. When an action fails >>> (pipe fails when nobody reads and it is tried to write to >>> it), rsyslog retries the configured number of times and >>> then suspends the action for the configured period (at >>> least I think it is configurable, you need to look up the >>> details). Only after this period the action is retried. >>> If it fails again, it is re-suspended, but this time with >>> a longer suspension period. This is done so that rsyslog >>> does not spent a lot of time on actions known to be failing. >> >> So you say, if i wait long enough the messages should receive >> the end of the pipe? > > Yes, that's what I assume. I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 and your assumption seems to be wrong. :( If the receiver is available again after about 20 seconds (while flooding syslog with the mentioned script) it reads the content of the pipe and nothing more. The debug log from rsyslogd endless says ----------->snip<---------------- 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start 1711.687992707:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1711.688016872:b6644b70: Message from UNIX socket: #3 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping message! 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start 1713.688441799:b6644b70: --------imuxsock calling select, active file descriptors (max 3): 3 1713.688488314:b6644b70: Message from UNIX socket: #3 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity -1) 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to drain. ----------->snap<---------------- So it seems that rsyslogd does not detect that the receiver is available again (as mentioned before this only occurs if the receiver is not available for a "longer" time - probably the time the pipe runs full). Steffen From rgerhards at hq.adiscon.com Thu Jul 29 13:16:16 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:16:16 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com> <4C516240.3000200@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> OK, then this seems to be a bug indeed. I suggest you file a bug report with bugzilla. Usually, I tend to forget about those things if they exist on the mailing list only :( When they are in bugzilla, I pick them as soon as I have time to do so. It would probably wise to include a link to the mailing list archive. I will try to look into this ASAP, but it may take some while as I am pretty busy right at the moment. Thanks, Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 1:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > >>> This sounds like intended behavior. When an action fails > >>> (pipe fails when nobody reads and it is tried to write to > >>> it), rsyslog retries the configured number of times and > >>> then suspends the action for the configured period (at > >>> least I think it is configurable, you need to look up the > >>> details). Only after this period the action is retried. > >>> If it fails again, it is re-suspended, but this time with > >>> a longer suspension period. This is done so that rsyslog > >>> does not spent a lot of time on actions known to be failing. > >> > >> So you say, if i wait long enough the messages should receive > >> the end of the pipe? > > > > Yes, that's what I assume. > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 > and your assumption seems to be wrong. :( > > If the receiver is available again after about 20 seconds (while > flooding syslog with the mentioned script) it reads the content of the > pipe and nothing more. > > The debug log from rsyslogd endless says > > ----------->snip<---------------- > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > 1711.687992707:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1711.688016872:b6644b70: Message from UNIX socket: #3 > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > 1713.688441799:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1713.688488314:b6644b70: Message from UNIX socket: #3 > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > ----------->snap<---------------- > > So it seems that rsyslogd does not detect that the receiver is > available again (as mentioned before this only occurs if the receiver > is not available for a "longer" time - probably the time the pipe runs > full). > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 13:19:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 13:19:27 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> One more thing: it may be useful if you could send me (privately) a complete debug log. I've just taken a look at ompipe, and there is no indication why this bug should happen. If I see how things proceed, I may be able to solve it quickly. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Thursday, July 29, 2010 1:16 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > OK, then this seems to be a bug indeed. I suggest you file a bug report > with > bugzilla. Usually, I tend to forget about those things if they exist on > the > mailing list only :( When they are in bugzilla, I pick them as soon as > I have > time to do so. It would probably wise to include a link to the mailing > list > archive. > > I will try to look into this ASAP, but it may take some while as I am > pretty > busy right at the moment. > > Thanks, > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Thursday, July 29, 2010 1:13 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > > >>> This sounds like intended behavior. When an action fails > > >>> (pipe fails when nobody reads and it is tried to write to > > >>> it), rsyslog retries the configured number of times and > > >>> then suspends the action for the configured period (at > > >>> least I think it is configurable, you need to look up the > > >>> details). Only after this period the action is retried. > > >>> If it fails again, it is re-suspended, but this time with > > >>> a longer suspension period. This is done so that rsyslog > > >>> does not spent a lot of time on actions known to be failing. > > >> > > >> So you say, if i wait long enough the messages should receive > > >> the end of the pipe? > > > > > > Yes, that's what I assume. > > > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval > 30 > > and your assumption seems to be wrong. :( > > > > If the receiver is available again after about 20 seconds (while > > flooding syslog with the mentioned script) it reads the content of > the > > pipe and nothing more. > > > > The debug log from rsyslogd endless says > > > > ----------->snip<---------------- > > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > > 1711.687992707:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1711.688016872:b6644b70: Message from UNIX socket: #3 > > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > > message! > > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > > 1713.688441799:b6644b70: --------imuxsock calling select, active file > > descriptors (max 3): 3 > > 1713.688488314:b6644b70: Message from UNIX socket: #3 > > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), > but > > could not drop msg (iRet: 0, severity -1) > > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > > drain. > > ----------->snap<---------------- > > > > So it seems that rsyslogd does not detect that the receiver is > > available again (as mentioned before this only occurs if the receiver > > is not available for a "longer" time - probably the time the pipe > runs > > full). > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From damjanster at gmail.com Thu Jul 29 13:24:29 2010 From: damjanster at gmail.com (=?ISO-8859-2?Q?Damjan_=AEiberna?=) Date: Thu, 29 Jul 2010 13:24:29 +0200 Subject: [rsyslog] OmoracleStatement format In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: > > I think it would be best to split the RFC3339 date via the property > replacer > (using start and end position) and then feed this to omoracle. > > The full doc on property replacer is here: > > http://www.rsyslog.com/doc/property_replacer.html I first thought I could replace some strings with regex, but I've got a fix from coworker to solve the issue like this: $template OmoracleStatement,"INSERT INTO SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" $template TestStmt,"%hostname%%timereported:0:10:date-rfc3339%%timereported:12:32:date-rfc3339%%fromhost-ip%%syslogfacility%%syslogseverity%%programname%%msg%" It works great now. > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > It would be useful to write a quick debug file > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > This shows what exactly is stored in which property and can probably used > to > solve the question what exactly happens. > It seems that the issue with timestamp was the cause of all the problems. The data got displaced for one colon. Not it works like a charm. Thanks for the help. From sledz at dresearch.de Thu Jul 29 14:05:10 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 14:05:10 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> Message-ID: <4C516E76.3080209@dresearch.de> On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > One more thing: it may be useful if you could send me (privately) a complete > debug log. I've just taken a look at ompipe, and there is no indication why > this bug should happen. If I see how things proceed, I may be able to solve > it quickly. Is on the way. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 15:00:01 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:00:01 +0200 Subject: [rsyslog] OmoracleStatement format References: <9B6E2A8877C38245BFB15CC491A11DA7104017@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104024@GRFEXC.intern.adiscon.com> Excellent, great to hear it is working now :) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Damjan ?iberna > Sent: Thursday, July 29, 2010 1:24 PM > To: rsyslog-users > Subject: Re: [rsyslog] OmoracleStatement format > > > > > I think it would be best to split the RFC3339 date via the property > > replacer > > (using start and end position) and then feed this to omoracle. > > > > The full doc on property replacer is here: > > > > http://www.rsyslog.com/doc/property_replacer.html > > > I first thought I could replace some strings with regex, but I've got a > fix > from coworker to solve the issue like this: > > $template OmoracleStatement,"INSERT INTO > SYSLOG(hostname,ts,hostip,facility,severity,program,message) VALUES > (:hostname,to_timestamp_tz(:dategen || ' ' || :timegen, 'YYYY-MM-DD > HH24:MI:SS.FF6TZH:TZM'),:hostip,:facility,:severity,:program,:message)" > > $template > TestStmt,"%hostname%%timereported:0:10:date- > rfc3339%%timereported:12:32:date-rfc3339%%fromhost- > ip%%syslogfacility%%syslogseverity%%programname%%msg%" > > It works great now. > > > > > > > > 2. hostname doesn't get written - I only get 127.0.0.1 > > > > It would be useful to write a quick debug file > > > > *.* /var/log/debug.log;RSYSLOG_DebugFormat > > > > This shows what exactly is stored in which property and can probably > used > > to > > solve the question what exactly happens. > > > > It seems that the issue with timestamp was the cause of all the > problems. > The data got displaced for one colon. Not it works like a charm. > > Thanks for the help. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Jul 29 15:07:31 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 15:07:31 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Ah, OK, now I see clearly. Well, the "obvious" happens, but I didn't realize it myself: You set the retry count to -1, that is infinite. So messages are never discarded. When nobody is reading the pipe, a queue builds up. In the log, the queue capacity is simply exhausted. As it looks from the log, nobody seems to be reading the pipe, at least we consistently get error 11 back from the write API call. Can you confirm this (I may be wrong, just looking quickly). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 2:05 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 01:19 PM, Rainer Gerhards wrote: > > One more thing: it may be useful if you could send me (privately) a > complete > > debug log. I've just taken a look at ompipe, and there is no > indication why > > this bug should happen. If I see how things proceed, I may be able to > solve > > it quickly. > > Is on the way. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Thu Jul 29 15:18:05 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Thu, 29 Jul 2010 15:18:05 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> Message-ID: <4C517F8D.9020405@dresearch.de> On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > You set the retry count to -1, that is infinite. So > messages are never discarded. When nobody is reading > the pipe, a queue builds up. In the log, the queue > capacity is simply exhausted. As it looks from the > log, nobody seems to be reading the pipe, at least > we consistently get error 11 back from the write API > call. As i wrote before *there is someone reading* the pipe. In another shell i run while true; do cat /var/run/syslog2thinfs ; done Also when i kill and restart the reader the behaviour still is the same. Steffen From rgerhards at hq.adiscon.com Thu Jul 29 16:35:33 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 29 Jul 2010 16:35:33 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Did you keep it running for more than 30 seconds after it has reached the stalled state? From the log, it looks like it were only roughly 9 seconds. As I said, I don'T see any more activity inside the debug log. But maybe it is just hidden. I suggest you restart the test and then wait for 5 minutes and se what happens. You may want to stop the producer after a few seconds, because messages are still sitting inside the queue and that makes looking at the log easier. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 3:18 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Buggy pipe behaviour > > On 07/29/2010 03:07 PM, Rainer Gerhards wrote: > > You set the retry count to -1, that is infinite. So > > messages are never discarded. When nobody is reading > > the pipe, a queue builds up. In the log, the queue > > capacity is simply exhausted. As it looks from the > > log, nobody seems to be reading the pipe, at least > > we consistently get error 11 back from the write API > > call. > > As i wrote before *there is someone reading* the pipe. > > In another shell i run > > while true; do cat /var/run/syslog2thinfs ; done > > Also when i kill and restart the reader the behaviour still is the > same. > > Steffen > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From ryan.b.lynch at gmail.com Fri Jul 30 00:33:43 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Thu, 29 Jul 2010 18:33:43 -0400 Subject: [rsyslog] How to write to a local socket? In-Reply-To: References: Message-ID: On Wed, Jul 28, 2010 at 21:43, Ryan Lynch wrote: > I'd like to forward via a local UNIX domain socket, instead. I think I > understand how to configure the 'imuxsock' module so my unprivileged > instance reads from a non-standard socket location. But I can't figure > out how to tell my root instance to forward via a local domain socket. I didn't figure out a completely RSyslog-native method, but another poster's message pointed me toward 'socat' and 'omprog', which I have working, now. (It would be really nice if RSyslog could support this natively, though.) In case anyone else wants to set this up, maybe this will save you some effort. I'm also interested in any comments/criticisms about this method, I'd love to hear suggestions for better ways to make this work. Also, I rolled it all up into a Fedora/EL RPM spec, and I'll send it on to anyone who's interested--just ask. Setup steps: * Install the 'socat' utility. * Build RSyslog with the '--enable-omprog' ./configure flag. * Create two separate RSyslog config files, one for the 'root' instance (writes to the socket) and a second for the 'unprivileged' instance (reads from the socket). * Rewrite your RSyslog init script to start two separate daemon instances, one using each config file (and separate PID files, too). * Create the user 'rsyslogd' and the group 'rsyslogd'. * Set permissions/ownerships as needed to allow the user 'rsyslogd' to write to the file '/var/log/rsyslog.log' * Create an executable script called '/usr/libexec/rsyslogd/omprog_socat' that contains the lines: #!/bin/bash /usr/bin/socat -t0 -T0 -lydaemon -d - UNIX-SENDTO:/dev/log * The 'root' instance config file should contain (modifying the output actions to taste): $ModLoad imklog $ModLoad omprog $Template FwdViaUNIXSocket,"<%pri%>%syslogtag%%msg%" $ActionOMProgBinary /usr/libexec/rsyslogd/omprog_socat *.* :omprog:;FwdViaUNIXSocket * The 'unprivileged' instance config file should contain (modifying the output actions to taste): $ModLoad imuxsock $PrivDropToUser rsyslogd $PrivDropToGroup rsyslogd *.* /var/log/rsyslog.log The 'root' daemon can only accept input from the kernel message buffer, and nothing else (especially not the syslog socket (/dev/log) or any network sockets). The unprivileged user will handle all of local and network log messages. To merge the kernel logs into the same data channel as everything else, here's what happens: [During the RSyslog daemons' startup] A) At startup, the 'root' daemon's 'imklog' module starts listening for kernel messages (via '/prog/kmsg'), and its 'omprog' module starts an instance of 'socat' (called via the 'omprog_socat' wrapper), establishing a persistent one-way IO connection where 'omprog' pipes its output to the STDIN of 'socat'. (Note that this same 'socat' instance remains running throughout the life of the RSyslog daemon, handling everything 'omprog' outputs. Contrast this, efficiency-wise, against the built-in 'subshell' module [the '^/path/to/program' action], which runs a separate instance instance of the child program for each message.) B) At startup, the 'unprivileged' daemon's 'imuxsock' module opens the system logging socket ('/dev/log') and starts listening for incoming log messages from other programs. [During normal operation] 1) The kernel buffer produces a message string on '/proc/kmsg'. 2) The 'root' RSyslog daemon reads the message from '/proc/kmsg', assigning it the priority number of 'kern.info' and the string tag 'kernel'. 3) The 'root' daemon prepends the priority number and tag as a header to the message string, and then passes it to the 'omprog' module for output (via persistent pipe) to the running 'socat' instance. 4) The 'socat' instance receives the header-framed message and sends it to the system logging socket ('/dev/log'). 5) The 'unprivileged' RSyslog daemon reads the message from '/dev/log', assigning it the priority and tag given in the message header, plus all of the other properties (timestamp, hostname, etc.) a message object should have. 6) The 'unprivileged' daemon formats the message and writes it to the output file. The only real difference I can see in the forwarded messages is that the 'source' property is set to 'imuxsock' instead of 'imklog'. I don't think that's a real problem, though, since the priority and tag are still distinct. -Ryan From sledz at dresearch.de Fri Jul 30 08:18:28 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:18:28 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> Message-ID: <4C526EB4.9000106@dresearch.de> Am 29.07.2010 16:35, schrieb Rainer Gerhards: > Did you keep it running for more than 30 seconds after > it has reached the stalled state? From the log, it looks > like it were only roughly 9 seconds. As I said, I don'T > see any more activity inside the debug log. But maybe it > is just hidden. > > I suggest you restart the test and then wait for 5 minutes > and se what happens. You may want to stop the producer > after a few seconds, because messages are still sitting > inside the queue and that makes looking at the log > easier. I've rerun the test: * start rsyslog * start receiver * start producer * stop and restart receiver after 5 sec -> OK * stop and restart receiver after 30 sec -> stall * stop producer * wait 10 min and call "logger test" -> still stalling :( I'll send the logfile to your personal address again. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:26:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:26:13 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 16:35, schrieb Rainer Gerhards: > > Did you keep it running for more than 30 seconds after > > it has reached the stalled state? From the log, it looks > > like it were only roughly 9 seconds. As I said, I don'T > > see any more activity inside the debug log. But maybe it > > is just hidden. > > > > I suggest you restart the test and then wait for 5 minutes > > and se what happens. You may want to stop the producer > > after a few seconds, because messages are still sitting > > inside the queue and that makes looking at the log > > easier. > > I've rerun the test: > > * start rsyslog > * start receiver > * start producer > * stop and restart receiver after 5 sec -> OK > * stop and restart receiver after 30 sec -> stall > * stop producer > * wait 10 min and call "logger test" -> still stalling :( Interesting -- I don't see any reprobing of the output. Unfortunately, the debug output does not really provide much insight of what is going on at the moment. I'll see if I can add some more instrumentation to try track this down. Not sure if I can do this today. Rainer > > I'll send the logfile to your personal address again. > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 08:30:11 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 08:30:11 +0200 Subject: [rsyslog] Buggy pipe behaviour In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> Message-ID: <4C527173.9090805@dresearch.de> Am 30.07.2010 08:26, schrieb Rainer Gerhards: > Interesting -- I don't see any reprobing of the output. > Unfortunately, the debug output does not really provide > much insight of what is going on at the moment. I'll see > if I can add some more instrumentation to try track this > down. Not sure if I can do this today. Can you give some hints which source files/functions are primarily involved here? May be we can do a little code review. Steffen From rgerhards at hq.adiscon.com Fri Jul 30 08:45:23 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:45:23 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com> <4C527173.9090805@dresearch.de> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > Sent: Friday, July 30, 2010 8:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > Interesting -- I don't see any reprobing of the output. > > Unfortunately, the debug output does not really provide > > much insight of what is going on at the moment. I'll see > > if I can add some more instrumentation to try track this > > down. Not sure if I can do this today. > > Can you give some hints which source files/functions are primarily > involved here? May be we can do a little code review. I'd start with ./action.[ch] and obviously ompipe itself. It may be useful to see what/how ompipe returns. You can also set debug mode to do a function trace (see debug doc), this requires --enable-rtinst. Rainer > > Steffen > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Fri Jul 30 08:46:57 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 30 Jul 2010 08:46:57 +0200 Subject: [rsyslog] Buggy pipe behaviour References: <4C512AEC.9070301@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401E@GRFEXC.intern.adiscon.com> <4C5158F6.3060702@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710401F@GRFEXC.intern.adiscon.com><4C516240.3000200@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104021@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA7104022@GRFEXC.intern.adiscon.com> <4C516E76.3080209@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402B@GRFEXC.intern.adiscon.com> <4C517F8D.9020405@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA710402C@GRFEXC.intern.adiscon.com> <4C526EB4.9000106@dresearch.de><9B6E2A8877C38245BFB15CC491A11DA7104031@GRFEXC.intern.adiscon.com><4C527173.9090805@dresearch.de> <9B6E2A8877C38245BFB15CC491A11DA7104032@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7104033@GRFEXC.intern.adiscon.com> And if you don't know this already, this doc may be useful: http://download.rsyslog.com/design.pdf It is not totally up to date, but covers the most important ides (most importantly the engine state transitions). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Friday, July 30, 2010 8:45 AM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Steffen Sledz > > Sent: Friday, July 30, 2010 8:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Buggy pipe behaviour > > > > Am 30.07.2010 08:26, schrieb Rainer Gerhards: > > > Interesting -- I don't see any reprobing of the output. > > > Unfortunately, the debug output does not really provide > > > much insight of what is going on at the moment. I'll see > > > if I can add some more instrumentation to try track this > > > down. Not sure if I can do this today. > > > > Can you give some hints which source files/functions are primarily > > involved here? May be we can do a little code review. > > I'd start with ./action.[ch] and obviously ompipe itself. It may be > useful to > see what/how ompipe returns. You can also set debug mode to do a > function > trace (see debug doc), this requires --enable-rtinst. > > Rainer > > > > Steffen > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From sledz at dresearch.de Fri Jul 30 14:52:55 2010 From: sledz at dresearch.de (Steffen Sledz) Date: Fri, 30 Jul 2010 14:52:55 +0200 Subject: [rsyslog] [PATCH] break potential infinite loop in actionDoRetry In-Reply-To: <4C527173.9090805@dresearch.de> References: <4C527173.9090805@dresearch.de> Message-ID: <1280494375-11930-1-git-send-email-sledz@dresearch.de> If a module always returns RS_RET_OK (like ompipe does) the actionDoRetry loop may not have leaved faked ACT_STATE_SUSP state in case iResumeOKinRow had ever reached a count of 1000. Signed-off-by: Steffen Sledz --- action.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/action.c b/action.c index 32a07dc..90ec1bf 100644 --- a/action.c +++ b/action.c @@ -508,6 +508,7 @@ static rsRetVal actionDoRetry(action_t *pThis, time_t ttNow) iRet = pThis->pMod->tryResume(pThis->pModData); if((pThis->iResumeOKinRow > 999) && (pThis->iResumeOKinRow % 1000 == 0)) { bTreatOKasSusp = 1; + pThis->iResumeOKinRow = 0; } else { bTreatOKasSusp = 0; } -- 1.6.4.2 From ryan.b.lynch at gmail.com Fri Jul 30 15:28:45 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 09:28:45 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <4C456476.4010703@redhat.com> References: <4C456476.4010703@redhat.com> Message-ID: On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > read data from SOCK_DGRAM. This has two consequences: first, to be able > to attach rsyslog on the host end one first needs to copy the data > between the two socket types, e.g. using socat. Second, messages longer > than 1024 characters are sometimes split into two. The second message is > thus missing the syslog header and the receiving rsyslogd doesn't know > where to file it. Is there a recommended workaround for those things > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > SOCK_STREAM)? I ran into a similar problem. Doesn't it seem wierd that RSyslog: - can write TO a pipe, but it can't natively read FROM a pipe. - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. The only protocols that Rsyslog can both read to AND write from are network sockets (UDP, TCP, RELP) and real files. Maybe everybody just uses UDP for local intra-daemon message routing? I guess real file I/O would work, too, but that seems kind of ugly to me (lots of needless I/O to a particularly slow subsystem). Or maybe there hasn't been much demand to support multiple local daemon instances with combined message processing. I decided to use the 'omprog' module to write via 'socat' to the '/dev/log' socket. I like your method, too. And thank you for mentioning 'socat', that's what gave me the idea to go in this direction, in the first place. > 2) I seem to be unable to get the forwarding template right. For network > forwarding (which is also supported in Anaconda), simply putting no > explicit formatting does the trick: > *.* @@ some.host > The received logs can be matched for anything: severity, facility, > hostname and programname. > > This is not the case when logs are forwarded through the character device: > *.* /dev/virtio_ports/port_name > > Using the implicit formatting the receiving syslog won't parse the > programname. > > I tried using the predefined ForwardFormat but then the receiving > rsyslogd parsed hostname as the programname and the programname remains > part of the final message. Is that the expected behavior? What worked > for me in the end was creating a template based on the ForwardFormat but > with the %HOSTNAME% part omitted: I can live with that for know since I > know the message came from a certain socket so it can be only one host. > Still: it seems weird there's no forwarding format provided that would > retain 100% of the information parsable by another rsyslog reading from > a socket. I'm probably just missing something? I don't think the problem is your forwarding format--I don't think it's possible for RSyslog to handle a HOSTNAME field, properly, in messages received via socket. Based on my own tests, I believe that 'imuxsock' and 'imudp' use different logic to parse incoming messages. 'imuxsock' always assumes that the hostname is the local host, so it doesn't have the conditional logic to differentiate between "forwarded" messages (which have an extra HOSTNAME field between the timestamp and tag) versus regular local messages (no HOSTNAME). This is a pretty reasonable assumption, really--the local UNIX socket doesn't traditionally have any way to receive messages forwarded from other hosts. Rainer could probably confirm this, or we could compare those two modules' sources. RSyslog is a fantastic piece of software, and its feature set has come a long way. But all of Rainer's excellent work has expanded our imaginations about what Syslog can do, and maybe our imaginations are advancing faster than he can code new features. -Ryan From sean at conman.org Sat Jul 31 01:05:20 2010 From: sean at conman.org (Sean Conner) Date: Fri, 30 Jul 2010 19:05:20 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: References: <4C456476.4010703@redhat.com> Message-ID: <20100730230520.GA21655@brevard.conman.org> It was thus said that the Great Ryan Lynch once stated: > On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik wrote: > > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > > read data from SOCK_DGRAM. This has two consequences: first, to be able > > to attach rsyslog on the host end one first needs to copy the data > > between the two socket types, e.g. using socat. Second, messages longer > > than 1024 characters are sometimes split into two. The second message is > > thus missing the syslog header and the receiving rsyslogd doesn't know > > where to file it. Is there a recommended workaround for those things > > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > > SOCK_STREAM)? > > I ran into a similar problem. Doesn't it seem wierd that RSyslog: > - can write TO a pipe, but it can't natively read FROM a pipe. > - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. > The only protocols that Rsyslog can both read to AND write from are > network sockets (UDP, TCP, RELP) and real files. > > Maybe everybody just uses UDP for local intra-daemon message routing? The default syslog() call uses a local UDP socket (usually '/dev/log') and there's no overhead a programmer has to do in order to call syslog() (I mean, a programm can call openlog(), but it's not mandatory). So programs (other than syslogd) use local Unix UDP socket. For talking to other syslog daemons, I think the typical scenario is to run one locally, and any forwarding is done via an actual network socket. I never thought of doing relaying to another Unix socket. I know in my case (at home) I send a copy of all logs to 239.255.0.1, which is a multicast address (local segment only) so that I can run other instances of syslogd (or in my case, my own syslogd) on that address (on any machine on the segment); I can even run multiple copies locally listening to that address without issue. Adding support for multicast addresses was simple (about 32 lines of code, but it also supports IPv6). > I guess real file I/O would work, too, but that seems kind of ugly to > me (lots of needless I/O to a particularly slow subsystem). Or maybe > there hasn't been much demand to support multiple local daemon > instances with combined message processing. I decided to use the > 'omprog' module to write via 'socat' to the '/dev/log' socket. One issue with using files is that you end up having to poll a file for input. Normally, when you read from files, reading 0 bytes means you've hit the end of the file (and read() doesn't block on end-of-file for actual files). In this case (and in the case if doing a 'tail -f') you have to keep reading the file for more input once you hit the end. In the case of 'tail -f' (and for this, I checked the actual source code) it just sleeps for a second everytime it reads 0 bytes from a file. > I like your method, too. And thank you for mentioning 'socat', that's > what gave me the idea to go in this direction, in the first place. > > > > 2) I seem to be unable to get the forwarding template right. For network > > forwarding (which is also supported in Anaconda), simply putting no > > explicit formatting does the trick: > > *.* @@ some.host > > The received logs can be matched for anything: severity, facility, > > hostname and programname. > > > > This is not the case when logs are forwarded through the character device: > > *.* /dev/virtio_ports/port_name > > > > Using the implicit formatting the receiving syslog won't parse the > > programname. > > > > I tried using the predefined ForwardFormat but then the receiving > > rsyslogd parsed hostname as the programname and the programname remains > > part of the final message. Is that the expected behavior? What worked > > for me in the end was creating a template based on the ForwardFormat but > > with the %HOSTNAME% part omitted: I can live with that for know since I > > know the message came from a certain socket so it can be only one host. > > Still: it seems weird there's no forwarding format provided that would > > retain 100% of the information parsable by another rsyslog reading from > > a socket. I'm probably just missing something? > > I don't think the problem is your forwarding format--I don't think > it's possible for RSyslog to handle a HOSTNAME field, properly, in > messages received via socket. I agree, but replace "rsyslog" with "any syslog" (it's why in my own syslogd I only send IP addresses and not hostnames). > Based on my own tests, I believe that 'imuxsock' and 'imudp' use > different logic to parse incoming messages. 'imuxsock' always assumes > that the hostname is the local host, so it doesn't have the > conditional logic to differentiate between "forwarded" messages (which > have an extra HOSTNAME field between the timestamp and tag) versus > regular local messages (no HOSTNAME). This is a pretty reasonable > assumption, really--the local UNIX socket doesn't traditionally have > any way to receive messages forwarded from other hosts. If that's the case, then I'm surprised; in my syslogd, all messages (reguardless of source) go through the same parsing engine (then again, I only handle RFC-3164 style messages). I handle messages from the local socket by setting the "hostname" to the actual socket filename; I could have used "localhost" but I felt the actual socket filename would be better in those rare instances where you had a chroot'ed program that wrote to its own "/dev/log" socket so one could see which chroot'ed environment the log message was generated under. -spc From ryan.b.lynch at gmail.com Sat Jul 31 04:23:33 2010 From: ryan.b.lynch at gmail.com (Ryan Lynch) Date: Fri, 30 Jul 2010 22:23:33 -0400 Subject: [rsyslog] log forwarding through unix sockets In-Reply-To: <20100730230520.GA21655@brevard.conman.org> References: <4C456476.4010703@redhat.com> <20100730230520.GA21655@brevard.conman.org> Message-ID: Hi, Sean, On Fri, Jul 30, 2010 at 19:05, Sean Conner wrote: > It was thus said that the Great Ryan Lynch once stated: >> Maybe everybody just uses UDP for local intra-daemon message routing? > > ?The default syslog() call uses a local UDP socket (usually '/dev/log') and > there's no overhead a programmer has to do in order to call syslog() (I > mean, a programm can call openlog(), but it's not mandatory). ?So programs > (other than syslogd) use local Unix UDP socket. When I wrote "UDP", I could have been clearer--I meant "UDP over a loopback IP connection", not over a local socket. That's the distinction: Are you calling sendto() to a listener on 127.0.01, or to a listener on /dev/log? The point here is that RSyslog cannot natively send its output to /dev/log (as far as I can tell). RSyslog can do IPC via a '*.* @127.0.0.1' action, but there's no corresponding '*.* @/dev/log' action, at least as far as I know. So if you want to forward messages between daemons, you HAVE to listen on the loopback IP, unless you're willing to use something like 'omprog' or pipe output, both of which require invoking an external program like 'socat' or creating a named pipe. (It works, but it's messier and more complicated--performance might be worse, too.) For Ales's KVM application, there may be a worse problem: His virtual machines might not have working network interfaces at all times, such as during provisioning/build. That's why the distinction of network socket vs. local socket matters--if you don't have any networking interfaces up, or you have security concerns about rogue local processes sending malicious traffic to the 127.0.0.1 listener, then the lack of a "send to local socket" capability makes life a little more difficult. -Ryan