Re: [syslog-ng] Macro expansion in program destination
No, this is *not* what syslog-ng does. Syslog-ng does *not* pass the macro value for $S_DAY do the command line, and thus the 30 does *not* appear at all.
I think a barrier to implementing this kind of functionality is that the program is started long before any log messages are received so there is nothing intelligent that the program macro could be expanded to. Starting the program when the first log message is received is a bad idea because 1) there may be an overhead in starting any given program which may mean log messages are lost and 2) if there is anything wrong with your program you won't know until the log message is received (instead of getting some indication when syslog-ng is started/sighup'd) But... I just had a thought on how this could be implemented (in a rather hack-ish manner) assuming the macro expansion _could_ be applied to the program destination (which I realize is not the case right now). One handy behaviour of syslog-ng is that if the program() exits it is restarted (I'm going on memory here so I reserve the right to be completely wrong). Normally program destinations _shouldn't_ exit, but if that program were to exit when syslog-ng comes to restart the program could perform the macro expansion again. I'd still favour and alternative (like parsing in the destination program) but if its an itch you feel like scratching grab the code and go for it. Also just another random thought for a Monday (to be taken with symptoms of caffeine withdrawal in mind). You could perform some trickery with named pipes (see mkfifo(1)). Lets say you wanted program x to receive log messages with some knowledge of the day without needing to do any parsing. You could setup 31 named pipes called /tmp/pipe-1 /tmp/pipe-2.... /tmp/pipe-31 then you could ask syslog-ng to write to a file destination d_pipe ("/tmp/pipe-$S_DAY") external to all this you could start 31 instances of program x each reading from one of the named pipes.
you could start 31 instances of program x each reading from one of the named pipes.
Or one program using poll() or select() to wait for input on all of the pipes simultaneously. Joe. -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of chris packham Sent: 07 December 2009 14:25 To: syslog-ng@lists.balabit.hu Subject: Re: [syslog-ng] Macro expansion in program destination
No, this is *not* what syslog-ng does. Syslog-ng does *not* pass the macro value for $S_DAY do the command line, and thus the 30 does *not* appear at all.
I think a barrier to implementing this kind of functionality is that the program is started long before any log messages are received so there is nothing intelligent that the program macro could be expanded to. Starting the program when the first log message is received is a bad idea because 1) there may be an overhead in starting any given program which may mean log messages are lost and 2) if there is anything wrong with your program you won't know until the log message is received (instead of getting some indication when syslog-ng is started/sighup'd) But... I just had a thought on how this could be implemented (in a rather hack-ish manner) assuming the macro expansion _could_ be applied to the program destination (which I realize is not the case right now). One handy behaviour of syslog-ng is that if the program() exits it is restarted (I'm going on memory here so I reserve the right to be completely wrong). Normally program destinations _shouldn't_ exit, but if that program were to exit when syslog-ng comes to restart the program could perform the macro expansion again. I'd still favour and alternative (like parsing in the destination program) but if its an itch you feel like scratching grab the code and go for it. Also just another random thought for a Monday (to be taken with symptoms of caffeine withdrawal in mind). You could perform some trickery with named pipes (see mkfifo(1)). Lets say you wanted program x to receive log messages with some knowledge of the day without needing to do any parsing. You could setup 31 named pipes called /tmp/pipe-1 /tmp/pipe-2.... /tmp/pipe-31 then you could ask syslog-ng to write to a file destination d_pipe ("/tmp/pipe-$S_DAY") external to all this you could start 31 instances of program x each reading from one of the named pipes. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
participants (2)
-
chris packham
-
Fegan, Joe