Bugzilla – Bug 908279
logrotate.timer not enabled automatically
Last modified: 2018-04-18 08:22:35 UTC
I'm always following Factory, and by luck noticed that I have a >100 MB /var/log/messages which wasn't rotated since months :-/ This seems to be a problem with the switch from a cronjob to logrotate.timer - logrotate.timer was disabled :-( Please make sure to always enable logrotate.timer (except if explicitely disabled by the user). Note: I wouldn't be too surprised if systemd-sysv-convert can only handle *.service, but not *.timer.
for systemd-presets-brading-opensUSE I guess ?
hmm, it has: enable logrotate.timer added in ------------------------------------------------------------------- Wed Apr 2 23:54:58 UTC 2014 - crrodriguez@opensuse.org - Enable the logrotate.timer that replaces the cron-based activation by default. Did you install fresh? If not, run "systemctl enable logrotate.timer"
I'm following Factory since years, so no new install. I also know how to manually enable logrotate.timer (and already did that after submitting this bugreport). However the question is why it wasn't enable automatically - my guess is that the migration from the cron.daily script fails. (If in doubt, test by upgrading a 13.1 to 13.2 and check if logrotate.timer is enabled.)
The timer is enabled by default grep logrotate 90-default-openSUSE.preset enable logrotate.timer It seems to the problem beign discussed lately in the packaging mailing list about presets . sometimes this doesn't work. depends on the package installation order.
Any news on this old bug? Leap 42.x still has /etc/cron.daily/logrotate, so we might hit the problem again when people update from Leap 42.x to Leap 15 or from SLE 12 to SLE 15. If in doubt, I'd recommend to add a check for "systemctl is-enabled logrotate.timer" to openQA.
Assigning to marcus as he is maintainer of the presets.
indeed 'logrotate' (logrotate.timer) is disabled when upgrading from 42.2 to 42.3. noticed this on all my systems I did upgrade. Anyway the logrotate package switched back to 'cron.daily' setup. Hence I am going to update the 42.3 logrotate package to latest version to fix this issue ... and having a working 'logrotate' without manual interaction.
I interpreted the changelog wrong ... anyway on all on my upgraded 42.2 to 42.3 systems there is one special package missing: - systemd-rpm-macros as mentioned here: https://bugzilla.opensuse.org/show_bug.cgi?id=1064303#c10 the important %service_add_pre/%service_add_post macros are missing and hence logrotate is not enabled by default. With systemd-rpm-macros installed also logrotate.timer is enabled by default after install. Seems there is a missing dependency about 'systemd-rpm-macros' ...
shouöld this really be asking Markus Meissner, or should it be me ? ;)
it should have been you 8-)
I have upgraded my Leap system from 42.2 to 42.3 on February 1st, 2018. The last log rotation happened on January 25th. Since then log files are no longer rotated. $ systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) So the bug is still there. (Clearing needinfo as the bug is assigned to Marcus anyway.)
I started looking into this after investigating a root partition full situation on my wife's Tumbleweed system. This is a very old installation and logrotate.timer was disabled for her too. Clearly the upgrade path from cron job to systemd timer is broken. My kids' Tuumbleweed systems have been installed more recently and do not suffer from the problem. I'll fix my wife's system manually but can we do something for all other users affected by the problem? I'm thinking of upgrades of Leap 42.2 to 42.3, but also SLE 12 SP2 to SP3.