On Fri, Feb 6, 2009 at 04:01, Rainer Gerhards <[email protected]> wrote: > The same happens when you use time-based properties: if you do not > reevaluate the file name, you will never switch files, because the name > stays always at the (somewhat random) initial value. > > So IMO this can not be a valid use-case.
Put that way, I agree to a point. However, it (case c) can still be of limited utility for environments using 3rd-party post-processing (like logrotate or FS utilization monitors). In those cases, it would be more useful to HUP the writing process prior to beginning and work on essentially cold files rather than the 'smear' you get when working with live files. The concept could definitely be abused as you showed with the host example. > What you describe in your post > (initial case b)) I would call a side-effect. As the file was closed due > to size limitation, as a side-effect a new name could be generated. That > is of interest because the name conveys the information how long it took > to reach the file size. I think a solution to this need could be to emit > a log message, telling which file was closed at what time (if an output > channel reaches max size). I presume that one would have to create an expression-based filter to handle this, but don't directly see how to generate (and retain) a new filename from it. > Does this make sense? Or did I misunderstand your intentions? If I got > it right, would the proposed new message on max file size (output > channel) solve your need? I think that should be fairly easy to add. It does make sense, I'm just not sure how to apply it. Thanks for your thoughts! RB _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
