$DAY not working in filenames macros in 1.6.x as it did in 1.5.x
Hi guys, I am running syslog-ng 1.5.15 on some debian stable machines. All good, all happy. I have a source: source network-hosts { udp(ip(0.0.0.0) port(8514)); tcp(ip(0.0.0.0) port(8514) max-connections(200)); }; I use filename macro expansion to auto-rotate my logs. My destinations look exactly like: destination logfiles-host { file("/var/log/HOSTS/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY\_$HOST\_$PROGRAM" template("$ISODATE [$HOST] <$FACILITY> $MSG\n") template_escape(no) owner(root) group(logs) perm(0660) dir_perm(0770) create_dirs(yes)); }; the routing stanza goes: log { source(network-hosts); destination(logfiles-host); }; This works as I expect (even without escaping the _'s between $DAY, $HOST and $PROGRAM). My log paths look like: /var/log/HOSTS/mel1/2005/02/20050203_mel1_named /var/log/HOSTS/mel1/2005/02/20050203_mel1_sendmail Great. However, using 1.6.x (I've not tested 1.6.6, to be sure, only 1.6.4 and 1.6.5) on both Solaris and Linux, using the exact same config (i.e., when I upgraded, for example), using this destination: destination d_local { file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY\_$HOST" template("$ISODATE [$HOST] <$FACILITY> $MSG\n") template_escape(no) perm(0660) dir_perm(0770) create_dirs(yes)); }; I get this: /var/log/LOCAL/mel1/2005/02/200502mel1 So $DAY is not expanding. Same thing occurs when I use file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY_$HOST" Is this a problem with $DAY, the _, or something else? Let me know if I can provide further info to help debug this.. Anyone else run into this? I'd like to upgrade all my boxes to 1.6.{4,5,6} eventually but at the moment this is holding me back from moving to 1.6. Cheers, Andrew Fort
Andrew Fort wrote: Oops - I knew I should've tried this before the original post.
However, using 1.6.x (I've not tested 1.6.6, to be sure, only 1.6.4 and 1.6.5) on both Solaris and Linux, using the exact same config (i.e., when I upgraded, for example), using this destination:
destination d_local { file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY\_$HOST" template("$ISODATE [$HOST] <$FACILITY> $MSG\n") template_escape(no) perm(0660) dir_perm(0770) create_dirs(yes)); };
I get this:
/var/log/LOCAL/mel1/2005/02/200502mel1
So $DAY is not expanding. Same thing occurs when I use
file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY_$HOST"
Is this a problem with $DAY, the _, or something else?
I changed the file line to: file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY-$HOST-$PROGRAM" And now I get what I am looking for, e.g. /var/log/LOCAL/mel1/2005/02/20050203-mel1-syslog-ng So, what's special about the underscore? (i'd prefer to use an underscore if I could... :). Cheers, andrew
On Thu, 2005-02-03 at 12:30 +1100, Andrew Fort wrote:
Andrew Fort wrote:
Oops - I knew I should've tried this before the original post.
I changed the file line to: file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH$DAY-$HOST-$PROGRAM"
And now I get what I am looking for,
e.g.
/var/log/LOCAL/mel1/2005/02/20050203-mel1-syslog-ng
So, what's special about the underscore? (i'd prefer to use an underscore if I could... :).
The problem is the difference how macro expansion is performed in 1.5.x and 1.6.x. This process has been signficantly enhanced performance wise, so it first locates whole words in the template string (word characters are [A-Z_], and once found it is replaced by the expansion value). The '_' is taken part of the word and thus not a $DAY but a $DAY_ macro is looked up which does not exist => becomes an empty value. This is solved in the development branch by adding brace support to expansion: file("/var/log/LOCAL/$HOST/$YEAR/$MONTH/$YEAR$MONTH${DAY}_$HOST-$PROGRAM") This makes it recognize the DAY macro and still add an underscore after that. However I'd prefer not touching 1.6.x too much until 1.9.x becomes 2.0.0. -- Bazsi
On 03/02/2005, at 8:49 PM, Balazs Scheidler wrote:
This makes it recognize the DAY macro and still add an underscore after that. However I'd prefer not touching 1.6.x too much until 1.9.x becomes 2.0.0.
Thanks for the clarification Bazsi; we'll stick with 1.5.x for now.
participants (2)
-
Andrew Fort
-
Balazs Scheidler