[opensuse-packaging] /etc/cron.* directories moved to cron package
Hi, I moved the /etc/cron.* packages from the filesystem to the cron package. Why? 1. On MicroOS we don't have cron, but the existing directories did confuse people who where wondering, why their cron scripts where never executed 2. The permissions macros couldn't be used in the filesystem package due to dependency order problems, so this could be fixed now. 3. There are only 20 packages left from over 12360 source packages, so you cannot count cron an integral/required part of the OS anymore. All packages containing cron files are adjusted to this change, you only need to accept my SRs. And there is no change for users, it's a pure packaging change. Maybe the package maintainers of this remaining package could even convert this remaining cron files to systemd-timers ;) apt-cacher-ng atop cacti cronie-anacron froxlor leafnode logdigest logwatch matomo munin nagios openlmi-providers (openlmi-pcp) patch2mail rkhunter sarg storeBackup texlive-filesystem tmpwatch yast2-ntp-client yum Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Dienstag, 20. August 2019, 13:07:02 CEST schrieb Thorsten Kukuk:
Hi,
I moved the /etc/cron.* packages from the filesystem to the cron package.
Why?
1. On MicroOS we don't have cron, but the existing directories did confuse people who where wondering, why their cron scripts where never executed 2. The permissions macros couldn't be used in the filesystem package due to dependency order problems, so this could be fixed now. 3. There are only 20 packages left from over 12360 source packages, so you cannot count cron an integral/required part of the OS anymore.
All packages containing cron files are adjusted to this change, you only need to accept my SRs. And there is no change for users, it's a pure packaging change.
Maybe the package maintainers of this remaining package could even convert this remaining cron files to systemd-timers ;)
apt-cacher-ng atop cacti cronie-anacron froxlor leafnode logdigest logwatch matomo munin nagios openlmi-providers (openlmi-pcp) patch2mail rkhunter sarg storeBackup texlive-filesystem tmpwatch yast2-ntp-client yum
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? Regards Eric -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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 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
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
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
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 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
26.08.2019 23:17, Brüns, Stefan пишет:
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
bor@bor-Latitude-E5450:~/src/NetworkManager$ systemctl --user start test-empty-service Failed to start test-empty-service.service: Unit test-empty-service.service is not loaded properly: Invalid argument. See user logs and 'systemctl --user status test-empty-service.service' for details. bor@bor-Latitude-E5450:~/src/NetworkManager$ systemctl --user --no-pager status -l test-empty-service ● test-empty-service.service - LogDigest and Rotate Loaded: error (Reason: Invalid argument) Active: inactive (dead) авг 27 07:33:39 bor-Latitude-E5450 systemd[1409]: test-empty-service.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. авг 27 07:33:53 bor-Latitude-E5450 systemd[1409]: test-empty-service.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. авг 27 07:34:13 bor-Latitude-E5450 systemd[1409]: test-empty-service.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. And do not tell me that forcing to add yet another unit definition is an improvement. And what if two timers come from different packages? -- 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 <opensuse@cboltz.de> 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 <adaugherity@tamu.edu> 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
Am 20.08.19 um 13:07 schrieb Thorsten Kukuk:
I moved the /etc/cron.* packages from the filesystem to the cron package.
Why?
1. On MicroOS we don't have cron, but the existing directories did confuse people who where wondering, why their cron scripts where never executed
For cron.d I can see that but for cron.{hourly,daily,weekly,monthly} does it really matter what executes the scripts? A systemd timer could handle that instead of cron just fine. No changes for the admin but we could still get rid of cron.
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? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
participants (10)
-
Andreas Schwab -
Andrei Borzenkov -
Andrew Daugherity -
Brüns, Stefan -
Christian Boltz -
Eric Schirra -
Jan Engelhardt -
Ludwig Nussel -
Michal Kubecek -
Thorsten Kukuk