On Aug 26, 2019, at 2:42 PM, Christian Boltz
wrote: To give you a real-world example: In the good old times ;-) logrotate and logdigest both lived in /etc/cron.daily. Thanks to the alphabetical order, logdigest sent me a mail with the interesting log events just a few seconds before logrotate rotated the logs away. I'm not sure if this was just pure luck by those who chose the script names or planned, but it worked perfectly.
Then someone came up with the idea to convert logrotate to a systemd timer, which means it runs at a random time[1], and completely independent of logdigest. Until I found out what's going on, I only wondered why the logdigest mail didn't contain the amount of messages I expected…
This sounds like what happened with logwatch[1], except in that case its cron.daily symlink was installed at ‘0logwatch’ to intentionally run before everything else (including logrotate). Then logrotate switched to timers and began running a few hours earlier, making the logwatch output useless.
Oh, BTW - if someone has a less annoying solution for "run logdigest a few seconds before logrotate", please speak up or, better, implement it in the logrotate and/or logdigest package ;-)
I submitted a fix to upstream logwatch to run its logwatch.service Before=logrotate (note: Before/After go in the service definition, not the timer!) and now have the latest release, including that fix, accepted to the OBS server:monitoring project. Packaging this in logwatch seemed like the best solution since logwatch cares that it runs before logrotate, but logrotate doesn’t care if any other log-related service is even installed. Now it just needs some attention to go into Leap itself (via Factory? Tumbleweed?). There’s another issue related to systemd timers: they are not activated until you both enable AND start them with systemctl (or rather, ’systemctl enable foo.timer’ to activate on boot and ’systemctl start foo.timer’ to activate it now). Nothing is enabled by default unless you get it added to systemd-presets-common-SUSE [2]. Even if it is listed there, I don’t think it gets started until you reboot or start it manually? This is another hurdle in migrating from cron to systemd timers — how to avoid having something that was running from cron, and after you upgrade, it no longer runs? I’ve been meaning to pose this question to this list, especially regarding OBS. Say you’re converting a package in OBS from cron to timers, and even get the timer enabled in systemd presets in Factory. But what about people not running Factory, but using that OBS repo on stable releases (Leap, SLES, etc.)? They won’t have the new systemd-presets-common-SUSE, so they ‘zypper up’ and now your package’s periodic jobs don’t run. And I’m pretty sure it’s against distro policy to put ’systemctl enable --now foo.timer’ in your %post… ;-) In the specific case of logwatch, I intentionally kept the cron job active in my first SR, pending resolution of this preset/activation issue; I manually removed the cron.daily symlink and activated the timer on my machines to resolve the logrotate vs. logwatch issue. Someone else has now followed up and removed the cron jobs when using systemd, so <shrug>… on the one hand, yay, now it’s “fully converted”, but on the other, it might no longer run nightly after an upgrade? -Andrew [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1112500 [2] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_syste...