On Tue, 13 Apr 1999, Richi Plana wrote:

On Mon, 12 Apr 1999, Balazs Scheidler wrote:

|o| I am thinking about builtin support for logfile rotation. One |o| could specify rotation parameters in destination statements: |o| |o| destination d_messages { file /var/log/messages rotate(weekly, 9) |o| compress };

|o| What do you think?

That'd be nice, but a lot of systems have their own "rotate log" systems and they may wish to centralize log rotation. Perhaps something like what squid has (squid -k rotatelogs) would be a better solution, but one needs to set up some kind of IPC. Or how about SIGUSR1 to rotate the logs... eh, wot?

I started to write a reply agreeing completely with you, but this is a sticky issue. The design philosophy of unix programs is supposed to be to make a program do a specific thing well, and to call other programs (that do their specific thing well) to do other things -- and this has definite advantages over the Windows idea of making huge programs with dozens of overlapping features -- but log rotation is definitely a logical extension of handling system logs. From a configuration standpoint, it is much cleaner to take care of everything regarding one log in one step. The problem, however, is that there are a number of different ways that a site might want to rotate its logs. Probably the most common way is what was contained in the proposed syntax above: filename.1, filename.2, etc. At JMU, however, we rotate our logs in the (what I think is much more logical) filename.YYYY-MM-DD, in a couple instances with time of day tacked on, and in most cases we gzip the logs as well. If log rotation were part of the syslog daemon, it would need to be flexible enough to keep most people happy. It would probably need to have at least the above two ways of naming rotated logs (digits and times), it would need the ability to compress logs immediately after rotation (gzip or bzip2), and it would need the ability to call an external script to do whatever else a site might like to do with a rotated log. (And if you could have a file rotate into a date-style filename anyway, why not have the ability to save it there in the first place?) Now, is it worth the time to write in these features, and do it well? Maybe. Maybe not. But if it were done in a flexible way, it would make configuration nice and easy, and keep it all in one place. (This is a complete 360 from where I stood when I originally started to reply.) -- Scott Dellinger Systems Administrator, JMU Technical Services dellinsd@jmu.edu

I started to write a reply agreeing completely with you, but this is a sticky issue. The design philosophy of unix programs is supposed to be to make a program do a specific thing well, and to call other programs (that do their specific thing well) to do other things -- and this has definite advantages over the Windows idea of making huge programs with dozens of overlapping features -- but log rotation is definitely a logical extension of handling system logs. From a configuration standpoint, it is much cleaner to take care of everything regarding one log in one step. The problem, however, is that there are a number of different ways that a site might want to rotate its logs. Probably the most common way is what was contained in the proposed syntax above: filename.1, filename.2, etc. At JMU, however, we rotate our logs in the (what I think is much more logical) filename.YYYY-MM-DD, in a couple instances with time of day tacked on, and in most cases we gzip the logs as well. If log rotation were part of the syslog daemon, it would need to be flexible enough to keep most people happy. It would probably need to have at least the above two ways of naming rotated logs (digits and times), it would need the ability to compress logs immediately after rotation (gzip or bzip2), and it would need the ability to call an external script to do whatever else a site might like to do with a rotated log. (And if you could have a file rotate into a date-style filename anyway, why not have the ability to save it there in the first place?) Now, is it worth the time to write in these features, and do it well? Maybe. Maybe not. But if it were done in a flexible way, it would make configuration nice and easy, and keep it all in one place.

I had the same problems when thinking about logrotation. What I don't like in current schemes is that from distribution to distribution (and from one UNIX to the other) configuring log rotation is different. RedHat has its logrotate (which I do like very much), Debian has IMHO a slightly worse solution. Providing these features in syslog-ng would make this situation a bit easier. And strictly IMHO logrotation info should be kept where log files are specified. (Debian does this, but it's too inflexible, because I can't specify how many generations a given file should have, and how often a given file should be rotated) Maybe it would be enough to bundle a logrotation program with syslog-ng (for example logrotate). Or simply file a wishlist bug for debian to move to logrotate. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi@balabit.hu