Hello, Am Donnerstag, 3. Dezember 2020, 09:19:43 CET schrieb Thorsten Kukuk:
On Wed, Dec 02, Christian Boltz wrote:
Am Mittwoch, 2. Dezember 2020, 10:44:50 CET schrieb Thorsten Kukuk:
[...]
I'm not speaking about syslog daemons. It's absolut necessary that syslog daemons require logrotate to make sure /var/log/messages isn't growing to much.
I'm speaking about tools like chrony, minidlna and similar, which don't log via syslog(), but either write to stderr/stdout and if not started by systemd, write into their own log files somewhere below /var/log.
This either wasn't clear in your initial mail, or I overlooked it. Thanks for the clarification, it adresses my concerns. I agree that in these cases requiring logrotate indeed doesn't make sense. [...]
If package still creates log files, it has to require logrotate, correct. But I'm speaking about all the cases, where the packages could theoretically create log files, but disabled it on purpose.
Agreed once more ;-)
Clobbering /var/log with special directories and files owned by special users will also only trigger actions, even if never used.
Which actions? As long as those files stay empty, I'm sure that logrotate won't rotate them ;-)
Of course not, but logrotate is run regulary by a sysemd timer or cron job, calls a stat on the files, etc. That's, if you log everything to systemd-journal as we do by default, is pretty useless and e.g. only activates disks from power save modes for nothing.
Agreed in general, but /etc/logrotate.d/zypper.lr (rotating /var/log/ zypper.log) and /etc/logrotate.d/firewalld (rotating /var/log/firewalld) basically means we won't get rid of logrotate anyway ;-) (Well, we probably don't have zypper and firewalld inside containers, but that's a different story.) [...]
Again, we are not speaking about syslog, we are speaking about applications which can optional write directly their own log files. To make this happen, you have to: - adjust the configuration - don't start the service by systemd (starting by systemd is the default)
Not sure if this is really a valid use case today anymore.
If both conditions need to be fulfilled to make a program write its own logfile, that's indeed a bit exotic. I would still call it a valid (and rare) usecase ;-) but I also understand that in such cases requiring logrotate would be too much. However, we also have programs where adjusting the configuration is enough to make them write a logfile, even if they are still started by systemd. One example I know is vsftpd - you can switch between using syslog and logging to its own logfile with a config option. (I'm saying this based on the config file, never tested it myself.) Actually chrony (one of the examples you mentioned) also belongs to this category - I just enabled log measurements statistics tracking in chrony.conf, and after restarting chronyd, I now have # ls -l /var/log/chrony/ -rw-r--r-- 1 chrony chrony 2603 4. Dez 00:26 measurements.log -rw-r--r-- 1 chrony chrony 1287 4. Dez 00:26 statistics.log -rw-r--r-- 1 chrony chrony 660 4. Dez 00:26 tracking.log This also means chrony should continue to ship the empty log directory - otherwise it will probably run into problems when trying to create these logfiles. We could discuss if in such cases logrotate should be required or only recommended - but given that it's already required for zypper.log, it won't change much ;-) Regards, Christian Boltz -- The only reason coders' computers work better than non-coders' computers is coders know computers are schizophrenic little children with auto-immune diseases and we don't beat them when they're bad. [http://www.stilldrinking.org/programming-sucks]