Section "10. Installing Necessary System Tools" of the handbook has the sections: "10.a. System Logger" and "10.b. Optional: cron" If a user installs The recommended logger, syslog-ng, then his log files will continually grow unless the sysadmin manually prunes them. A naive user may never notice this and will probably secretly lose disk space. How about a one line mention of logrotate? Something like "If you install syslog-ng you may also want to install logrotate to keep your log files down to a reasonable size." Reproducible: Always Steps to Reproduce: 1. 2. 3.
Sorry; none of our installation CDs provides the necessary sources to install logrotate. In other words, people who install Gentoo networkless wouldn't be able to install logrotate and we try to keep the documentation in that part as consistent as possible (i.e. we try to reduce the "not available for networkless" stuff).
Please allow me to reopen. Users have been getting log files >1Gb since we changed the default logger from metalog to syslog-ng because metalog has built-in log rotation and syslog-ng hasn't. IMHO, the right way would be to add logrotate to the upcoming release if not too late and mention it in the docs once done. It's only 31kB of source code / 43kB once compiled.
zhen: please add logrotate to the GRP spec files
i can surely add it to the grp spec files. may I ask though why syslog-ng is now the default logger? metalog (for reasons noted here, and others) is a much better drop-in logger for regular users (imo)
It's been defaulted for a very long time now. I don't know the exact reason anymore, but one that I can think of is that syslog-ng doesn't suffer from the buffering-feature that makes metalogd a tad more difficult to explain to the users (not much, but it did require a couple of extra lines with the explanation of the SIGUSR1 and SIGUSR2 signals and how to use them to drive metalogd's buffering). I believed that syslog-ng had no such shortcomings and that it was way more powerful: 1-0 for syslog-ng vs metalog. Yet this no-default-rotation makes it a draw again: 1-1 :)
ah yes, I forgot about buffering ;) is it more expensive to have the user deal with logrotating and the documentation associated than explaining signals? I still think metalog is the best choice ..
Reopening because it will require change to the docs either way. IIRC buffering and the required blah blah that was required to prevent users from complaining "my logs are empty/late" was the reason for the move to syslog-ng as default in the docs. Funny thing is that issue is now gone. metalog uses sync mode by default and has buffering as an option. If devs recommend that metalog is the best default, we might as well go back to metalog. That said, could we still include logrotate on the CDs so we can mention it very briefly when we tell users about other possible loggers?
What happened with this? By the way, logrotate is in the GRP set (at least for x86 and amd64, which I am building now) I tend to think syslog-ng is a better logger for us to use as a default, simply because it works similarly to sysklogd, which is what people will be familiar with. It also speaks "Gentoo" in being very powerful and easy to master. It also supports network logging, which I tend to think it essential in a logger.
Okay, I've made "metalog" the default again as it requires the littlest changes (syslog-ng requires logrotate for good functionality which isn't available _as source_ on the LiveCD) and doesn't have the buffering issue anymore.
