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