2014-09-15 9:23 GMT+02:00 David Lang <[email protected]>: > a very little known feature was asked about on the forums, output channels > were added to rsyslog back in the 0.9 days, and provided a way to have > rsyslog rotate it's output files when they hit a max size. This was back in > the days of 31 bit file lengths, so it was a work-around for the 2G file > size limits. > > This capability was not included in the new config syntax, so it's only > available via the legacy config (http://www.rsyslog.com/doc/ > rsyslog_conf_output.html) > > Nowdays, logrotate is the normal go-to tool for this sort of > functionality, and it has the advantage that it can do time or size (bytes > or lines) based rotation and that whatever it does has no impact on the > performance of rsyslog (other than the HUP to get rsyslog to reopen files) > > I think we should decide to either phase this out and push people to using > logrotate, or bring it fully up to date and have it be part of the v7 > action config (rotate based on file size, log count, and possibly even > evaluating a rainerscript formula like $$hour%3 to rotate every 3 hours) > > Evaluating this in rsyslog will add to the overhead of each message being > written, and when a file rotation happens, it will be one file at a time > (so multiple files will not all end at the same time), and rsyslog will > have to pause while the rotation is taking place (as it execs the rotation > command and waits for it to finish) > > Overall, I think that it's not worth the hassle of maintaining it. There > are so many gatcha's in trying to use it that I think it's better to just > punt to an external rotation tool like logrotate. > > Thoughts from others on the list? > > What I say here is out of my memory. I haven't thought about this for at least 2 years, so take it with a grain of salt. Basically, the file stream object provides everything needed for a kind of rotation. This is due to the fact that this is what is done using disk queues, and it is the same object. My plan was to use that functionality and make omfile provide rotation features based on it. I guess 90% are already in place, "just" parameterization, testing and a small handful of extra code is missing. I see cases where it makes sense. Blocking rotation would probably not a good idea, but could be done. Async would also be possible (in the sense that a new file is begun, with new name, and the old compressed).
I did not invest any more time into this, as usually that features receives a question only once a year AND I don't see feature requests for such functionality. I still think we should provide the old style feature, as it is useful for some folks and there are some exotic use cases which are hard to work around when it would go away. So far, maintainance is not an issue. This all just for your information! Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
