On Monday 2019-08-26 09:50, Thorsten Kukuk wrote:

On Sun, Aug 25, Eric Schirra wrote:

...

Why should i do this, when i want cron? I don't like system-timer. I use always cron. Or do i not understand something?

If you need to start to debug performance issues, you will start liking systemd-timer and hate cron. You can personally use whatever you want, nobody plans to drop cron. But openSUSE is a systemd based distribution, and systemd-timer has many advantages over cron, that's why we use it as default. And if it would be a really bad decission, people wouldn't have had converted so many cron jobs to systemd-timers.

Let timers speak for themselves, no need to bring in "people". Just because many people do something does not mean it's necessarily good. The amount of users e.g. Windows has is no indicator that it's a good or not-bad choice. (for some definition of "good" and "bad", ofc) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am Montag, 26. August 2019, 09:50:25 CEST schrieb Thorsten Kukuk:

On Sun, Aug 25, Eric Schirra wrote:

...

Why should i do this, when i want cron? I don't like system-timer. I use always cron. Or do i not understand something?

If you need to start to debug performance issues, you will start liking systemd-timer and hate cron. You can personally use whatever you want, nobody plans to drop cron. But openSUSE is a systemd based distribution, and systemd-timer has many advantages over cron, that's why we use it as default. And if it would be a really bad decission, people wouldn't have had converted so many cron jobs to systemd-timers.

I understood that cron and cron files should be removed in packages. When that is not the case and you can use both in package building, everything is fine. Then everyone can take what they want. By the way, I guess that most cron use. Systemd-timer has no advantages for me. Is only more complicated. Whether the computer needs 10 seconds or 10.5 seconds to boot I do not care and on a server system anyway. Regards Eric -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Montag, 26. August 2019 21:42:24 CEST Christian Boltz wrote:

Hello,

Am Montag, 26. August 2019, 09:50:25 CEST schrieb Thorsten Kukuk:

...

On Sun, Aug 25, Eric Schirra wrote:

...

Why should i do this, when i want cron? I don't like system-timer. I use always cron. Or do i not understand something?

If you need to start to debug performance issues, you will start liking systemd-timer and hate cron. You can personally use whatever you want, nobody plans to drop cron. But openSUSE is a systemd based distribution, and systemd-timer has many advantages over cron, that's why we use it as default. And if it would be a really bad decission, people wouldn't have had converted so many cron jobs to systemd-timers.

There are times when I want my /etc/cron.daily/ back (and want to have everything in there instead of having it converted to a systemd timer).

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.

Pure luck ...

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...

You don't want multiple timers, you want one timer triggering two services: $> cat /etc/systemd/system/logdigestrotate.service [Unit] Description=LogDigest and Rotate Wants=logdigest.service logrotate.service After=logdigest.service logrotate.service [Install] Also=logdigestrotate.timer $> cat /etc/systemd/system/logdigestrotate.timer [Timer] OnCalendar=daily AccuracySec=12h $> cat /etc/systemd/system/logrotate.service.d/after_logdigest.conf [Unit] After=logdigest.service Regards, Stefan-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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...