Hello, Am Mittwoch, 2. Dezember 2020, 10:44:50 CET schrieb Thorsten Kukuk:
we have quite some packages, which:
1. require logrotate and ship a logrotate configuration file 2. have a special directory in /var/log 3. never create a log file as they are controlled by systemd
The reason the packages never write to the log file by default is, that they log to stdout/stderr and systemd/journald captures them.
Correct me if I'm wrong, but when using syslog-ng, rsyslog etc., these messages will probably end up in /var/log/messages. (At least I have quite some kmail and akonadiserver messages there, and I'm sure they don't write to syslog directly.) And even if your mail didn't target syslog daemons, they are not too different when it comes to requiring logrotate.
What should we do with such packages? Requiring logrotate, even if never used by default, is already a bad idea. It runs regular (so uses resources) without doing anything.
Agreed in theory, even if the resource usage is minor. However, a superfluous logrotate run is still much better than not having logrotate installed, and to get multi-GB logfiles because nothing rotates and compresses them. (I've seen more than one full disk because of such a monster logfile.)
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 ;-)
What would be a good solution? I understand that some people may want to run this tools without control by systemd. But on the other side, in this cases the people have to adjust the configuration anyways.
Maybe a good solution could be: - continue to ship the logrotate configuration file - only Recommend logrotate, not require it
I'd guesstimate ;-) that you'll still find lots of syslog usage, especially on servers. Also many people use --no-recommends on servers which in the end would mean no logrotate and multi-GB logfiles. Let me extend your proposal a bit: - if a program always writes its own logfiles (for example apache, salt, also syslog-ng, rsyslog etc.), it should _require_ logrotate - if a program writes to stdout/stderr (which ends up in the journal or gets forwarded to syslog* that, see above, already requires logrotate) and only writes its own logfile after a config change, recommending logrotate is ok.
- let the admin create the configuration file and directory
I guess you meant "_log_ file and directory"? An unused logfile or directory might be an annoyance, but hurts much less than a problem caused by a missing log directory which stops a program from writing its log. Well, you can always look for the startup error of $program in its logfile - oh wait... ;-)) Therefore I'd apply a similar policy as for requiring logrotate - programs that write a logfile in the default config (apache, salt, ...) should also ship their log directories. As a sort-of-disclaimer, even if it should be obvious: I prefer syslog over journal, and have syslog* running everywhere. Regards, Christian Boltz -- Was spricht gegen einen Punkt im Expertenmodus: [ ] Ich weiß nicht, was eine Partition ist. Wenn einer das anklickt, ist klar, daß er Anfänger ist. [Bernd Brodesser in suse-linux]