Re: Logging to program destinations has odd prefix?
At Friday 11:14 AM 9/17/2004, Balazs Scheidler wrote:
On Thu, 2004-09-16 at 19:36, Lars Kellogg-Stedman wrote:
Text logged to a program via the program() destination has a prefix of the form <nnn>, which I'm assuming is the encoding of the syslog level and facility. Great! But I don't want it :).
Is there any way to prevent this text from being logged? Sure, I can write a "wrapper" program to edit these messages before they reach the intended destination, but my template doesn't ask for this information, so I'm not sure it should be there.
I think this was fixed in one of the recent versions.
I just ran into this bug while using syslog-ng 1.6.0rc1 with a program destination on a Solaris system. After finding the above discussion from 2004 I upgraded to 1.6.11...but the bug is still there. Here are some samples of lines handed off from syslog-ng to the external program: <6>Jul 7 14:53:50 sys1 kernel: SysRq : Emergency Sync <4>Jul 7 14:53:50 sys1 kernel: Emergency Sync complete <6>Jul 7 14:53:51 sys2 kernel: SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts I'm getting around this by editing out the prefix, but it would be good if this were fixed in syslog-ng itself. - John
On Wed, 2006-07-12 at 15:27 -0700, John Caruso wrote:
At Friday 11:14 AM 9/17/2004, Balazs Scheidler wrote:
On Thu, 2004-09-16 at 19:36, Lars Kellogg-Stedman wrote:
Text logged to a program via the program() destination has a prefix of the form <nnn>, which I'm assuming is the encoding of the syslog level and facility. Great! But I don't want it :).
Is there any way to prevent this text from being logged? Sure, I can write a "wrapper" program to edit these messages before they reach the intended destination, but my template doesn't ask for this information, so I'm not sure it should be there.
I think this was fixed in one of the recent versions.
I just ran into this bug while using syslog-ng 1.6.0rc1 with a program destination on a Solaris system. After finding the above discussion from 2004 I upgraded to 1.6.11...but the bug is still there. Here are some samples of lines handed off from syslog-ng to the external program:
<6>Jul 7 14:53:50 sys1 kernel: SysRq : Emergency Sync <4>Jul 7 14:53:50 sys1 kernel: Emergency Sync complete <6>Jul 7 14:53:51 sys2 kernel: SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
I'm getting around this by editing out the prefix, but it would be good if this were fixed in syslog-ng itself.
Let me stress that _this is not a bug_, it is working as intended. Newer versions can specify a template for programs, which can be used to omit the priority value. -- Bazsi
On Thursday 02:45 AM 7/13/2006, Balazs Scheidler wrote:
Let me stress that _this is not a bug_, it is working as intended. Newer versions can specify a template for programs, which can be used to omit the priority value.
Ok, thanks. The preceding exchange didn't indicate that; in fact I was assuming it was intentional until I saw you saying that it was fixed in a recent version. I couldn't find anything about this in the 1.6 (or even 2.0) documentation either (searching for "program", "prefix", "<", etc), and the only mailing list postings I found about it were these two that implied it was a bug. Was I missing something obvious, or is this just undocumented behavior? I'd think that as the default it would make more sense to generate messages just as they would have been generated with a file() destination and to require users who actually want the priority prefix (or any other special handling) to use a template to get it, rather than requiring it to be stripped out by default. - John
On Thu, 2006-07-13 at 10:08 -0700, John Caruso wrote:
On Thursday 02:45 AM 7/13/2006, Balazs Scheidler wrote:
Let me stress that _this is not a bug_, it is working as intended. Newer versions can specify a template for programs, which can be used to omit the priority value.
Ok, thanks. The preceding exchange didn't indicate that; in fact I was assuming it was intentional until I saw you saying that it was fixed in a recent version. I couldn't find anything about this in the 1.6 (or even 2.0) documentation either (searching for "program", "prefix", "<", etc), and the only mailing list postings I found about it were these two that implied it was a bug. Was I missing something obvious, or is this just undocumented behavior?
I'd think that as the default it would make more sense to generate messages just as they would have been generated with a file() destination and to require users who actually want the priority prefix (or any other special handling) to use a template to get it, rather than requiring it to be stripped out by default.
And what happens to those users who are using the current format in their scripts? -- Bazsi
On Friday 05:24 AM 7/14/2006, Balazs Scheidler wrote:
I'd think that as the default it would make more sense to generate messages just as they would have been generated with a file() destination and to require users who actually want the priority prefix (or any other special handling) to use a template to get it, rather than requiring it to be stripped out by default.
And what happens to those users who are using the current format in their scripts?
They'd use a template, of course. My general point was just that it's better to design for the rule rather than the exception, especially when the resulting behavior is unexpected and (apparently) not documented. It doesn't matter much to me anymore since I've already spent the time tracking down/testing this behavior (since I initially thought it might be a problem with *my* script) and then working around it. - John
On Fri, 2006-07-14 at 10:04 -0700, John Caruso wrote:
On Friday 05:24 AM 7/14/2006, Balazs Scheidler wrote:
I'd think that as the default it would make more sense to generate messages just as they would have been generated with a file() destination and to require users who actually want the priority prefix (or any other special handling) to use a template to get it, rather than requiring it to be stripped out by default.
And what happens to those users who are using the current format in their scripts?
They'd use a template, of course. My general point was just that it's better to design for the rule rather than the exception, especially when the resulting behavior is unexpected and (apparently) not documented. It doesn't matter much to me anymore since I've already spent the time tracking down/testing this behavior (since I initially thought it might be a problem with *my* script) and then working around it.
1) it might be a rule for you and an exception for others. I would not think that this behaviour is unexpected, a lot of applications require priority information, some users even add this information to their log files, as otherwise it'd be lost. I agree that it is unexpected if you are using program() to send out alerts, but that's not necessarily the primary purpose. 2) changing the way it currently works would break systems that already rely on this behaviour. I don't want to break their systems. For a critical software like syslog-ng, a suboptimal feature is way better than a regression. And there's a clean solution for those you don't want the priority information. In 2.0.x you can even define your template once and use it for several destinations. -- Bazsi
On Saturday 08:53 AM 7/15/2006, Balazs Scheidler wrote:
2) changing the way it currently works would break systems that already rely on this behaviour. I don't want to break their systems.
Sure. I was just offering an opinion, but keeping legacy behavior makes sense. I'd suggest that it would be good to document this behavior of program() destinations prominently in the reference manual, though. The current documentation not only doesn't mention it (that I can see), but even implies that the <X> is *not* coming from syslog-ng; e.g. in the 1.6 docs for the template() option of program() it says that the default is "a format conforming to the default logfile format," but the default logfile format doesn't include the <X>. That's exactly why I initially thought it might be a bug in my Perl script.... - John
On Sat, 2006-07-15 at 11:48 -0700, John Caruso wrote:
On Saturday 08:53 AM 7/15/2006, Balazs Scheidler wrote:
2) changing the way it currently works would break systems that already rely on this behaviour. I don't want to break their systems.
Sure. I was just offering an opinion, but keeping legacy behavior makes sense.
I'd suggest that it would be good to document this behavior of program() destinations prominently in the reference manual, though. The current documentation not only doesn't mention it (that I can see), but even implies that the <X> is *not* coming from syslog-ng; e.g. in the 1.6 docs for the template() option of program() it says that the default is "a format conforming to the default logfile format," but the default logfile format doesn't include the <X>. That's exactly why I initially thought it might be a bug in my Perl script....
Agreed, I've added the following change to the documentation: --- orig/doc/reference/syslog-ng.xml +++ mod/doc/reference/syslog-ng.xml @@ -1865,7 +1865,9 @@ <para> The program destination supports all common destination options - and has no specific options. + and has no specific options. The default format matches the BSD + syslog protocol, e.g. it includes the priority value in addition + to the format used in logfiles. </para> <example> -- Bazsi
participants (2)
-
Balazs Scheidler
-
John Caruso