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. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 247165, AG München) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Monday, 26 August 2019 9: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.

An interesting question, though, would be how many do so because they believe systemd-whatever to be technically superior and how many only to escape the constant nagging "why don't you replace your init script / xinetd config / cron job / ... / ... by whatever the systemd religion teaches us to be The Right Way". Michal Kubecek -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. 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... As a workaround, I now have # /etc/systemd/system/logrotate.timer.d/exact-time.conf [Timer] OnCalendar= OnCalendar=*-*-* 00:16:00 AccuracySec=1s to get rid of the random logrotate time. Now please don't tell me that systemd timers make everything better ;-) </rant> 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 ;-) Regards, Christian Boltz [1] quoting logrotate.timer: [Timer] OnCalendar=daily AccuracySec=12h -- Heutzutage ist alles digital, auch der Bauer. Der kann aber gar nicht richtig arbeiten, da er kein netzt hat. Man muss z.b. den Bestand der Tiere hochladen. Das dauert manchmal so lange, dass die Zahl schon wieder falsch ist. [Tim Schiemann zu https://plus.google.com/+KristianKöhntopp/posts/Zo8EaVJbGx9] -- 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...

On Aug 26 2019, Andrew Daugherity wrote:

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

systemctl enable --now foo.timer Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Aug 27, Ludwig Nussel wrote:

Am 20.08.19 um 13:07 schrieb Thorsten Kukuk:

...

2. The permissions macros couldn't be used in the filesystem package due to dependency order problems, so this could be fixed now.

I wonder if those permission settings still make sense in the first place. Super secret cron scripts in level paranoid?

I don't think it makes sense, but that's something for the security team who maintains that list. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 247165, AG München) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org