Migrating from run-crons to run-parts
Cronie package ships an ad-hoc script made for openSUSE that runs the hourly/daily/weekly jobs. -*/15 * * * * root test -x /usr/libexec/cron/run-crons && /usr/libexec/cron/run-crons >/dev/null 2>&1 This script contains some strange behaviour and it isn't really reliable due to the usage of ctime. Relevant bugs: - bsc#972984 - bsc#980873 - bsc#1080490 Other distributions are using run-parts executable from the debianutils package (which hasn't been packaged in openSUSE) but there is also the run-parts script from upstream. http://ftp.debian.org/debian/pool/main/d/debianutils/ https://github.com/cronie-crond/crontabs/blob/master/run-parts run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it: 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly My proposal is to package debianutils and add a dependency on it in the cronie package; the default config will be updated to use run-parts. run-crons script will be provided by the cronie package for some time to allow users to switch. Any feedback on this change? Regards, Danilo
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it. For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead. Regards, Danilo
On Mon, Jul 26, Danilo Spinella wrote:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it.
That's not fully correct. On openSUSE Tumbleweed we don't install cronie by default anymore, on other openSUSE projects we even don't ship it anymore. So we are not only able to remove it, we did it already for the first products.
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Mon, Jul 26, 2021 at 6:35 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Mon, Jul 26, Danilo Spinella wrote:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it.
That's not fully correct. On openSUSE Tumbleweed we don't install cronie by default anymore, on other openSUSE projects we even don't ship it anymore. So we are not only able to remove it, we did it already for the first products.
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
Putting aside the fact people shouldn't be using cron anymore, I'm pretty sure cronie has its own mechanism to run hourly/daily/weekly/monthly jobs. I know that Fedora doesn't use debianutils' run-parts for cron job execution at all, and it also uses cronie as its cron service. Why not just use that? -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, 2021-07-26 at 06:45 -0400, Neal Gompa wrote:
On Mon, Jul 26, 2021 at 6:35 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Mon, Jul 26, Danilo Spinella wrote:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it.
That's not fully correct. On openSUSE Tumbleweed we don't install cronie by default anymore, on other openSUSE projects we even don't ship it anymore. So we are not only able to remove it, we did it already for the first products.
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
Putting aside the fact people shouldn't be using cron anymore, I'm pretty sure cronie has its own mechanism to run hourly/daily/weekly/monthly jobs. I know that Fedora doesn't use debianutils' run-parts for cron job execution at all, and it also uses cronie as its cron service. Why not just use that?
-- 真実はいつも一つ！/ Always, there's only one truth!
cronie itself doesn't have it. But upstream provide "crontabs" that contains a run-parts script. That's what Fedora is using. https://github.com/cronie-crond/crontabs/blob/master/run-parts https://src.fedoraproject.org/rpms/crontabs/blob/rawhide/f/crontabs.spec Personally I consider the debianutils run-parts program to be more reliable than the script from upstream.
Le 26/07/2021 à 12:35, Thorsten Kukuk a écrit :
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
but why change investment already done? jdd -- http://dodin.org
On 7/26/21 12:35 PM, Thorsten Kukuk wrote:
On Mon, Jul 26, Danilo Spinella wrote:
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
What about containers without systemd? No CRON-like function therein? Ciao, Michael.
On Mon, 2021-07-26 at 14:02 +0200, Michael Ströder wrote:
On 7/26/21 12:35 PM, Thorsten Kukuk wrote:
On Mon, Jul 26, Danilo Spinella wrote:
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
What about containers without systemd? No CRON-like function therein?
Ciao, Michael.
If a container needs to run something periodically, there are programs that allows that without using cron. https://github.com/leahneukirchen/snooze Regards, Danilo
On 7/26/21 3:31 PM, Danilo Spinella wrote:
On Mon, 2021-07-26 at 14:02 +0200, Michael Ströder wrote:
On 7/26/21 12:35 PM, Thorsten Kukuk wrote:
On Mon, Jul 26, Danilo Spinella wrote:
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
What about containers without systemd? No CRON-like function therein?
If a container needs to run something periodically, there are programs that allows that without using cron.
From the above web page: "snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)." AFAICS neither snoooze nor runit is available as package in Tumbleweed. Ciao, Michael.
On Mon, 2021-07-26 at 15:42 +0200, Michael Ströder wrote:
On 7/26/21 3:31 PM, Danilo Spinella wrote:
On Mon, 2021-07-26 at 14:02 +0200, Michael Ströder wrote:
On 7/26/21 12:35 PM, Thorsten Kukuk wrote:
On Mon, Jul 26, Danilo Spinella wrote:
For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
It would be better if the last people who use it would switch to systemd-timers instead to invest in deprecated technology ;)
What about containers without systemd? No CRON-like function therein?
If a container needs to run something periodically, there are programs that allows that without using cron.
From the above web page:
"snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)."
AFAICS neither snoooze nor runit is available as package in Tumbleweed.
Ciao, Michael.
No need to when using docker. You usually use docker-compose in place of runit. And snooze could be adedd to TW. Example usage: docker -it <container> run -- \ snooze <settings> <my-periodic-command> Run automatically: CMD ["snooze", "<settings>", "<my-periodic-command>"] Regards, Danilo
On Monday 2021-07-26 15:42, Michael Ströder wrote:
From the above web page:
"snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)."
Sounds just like at(1) ;-)
On Tue, 2021-07-27 at 16:11 +0200, Jan Engelhardt wrote:
On Monday 2021-07-26 15:42, Michael Ströder wrote:
From the above web page:
"snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)."
Sounds just like at(1) ;-)
Yes, just without a daemon running.
On Tuesday 2021-07-27 18:00, Danilo Spinella wrote:
On Tue, 2021-07-27 at 16:11 +0200, Jan Engelhardt wrote:
On Monday 2021-07-26 15:42, Michael Ströder wrote:
From the above web page:
"snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)."
Sounds just like at(1) ;-)
Yes, just without a daemon running.
Which means it's probably gone after reboot.
On Tue, 2021-07-27 at 19:33 +0200, Jan Engelhardt wrote:
On Tuesday 2021-07-27 18:00, Danilo Spinella wrote:
On Tue, 2021-07-27 at 16:11 +0200, Jan Engelhardt wrote:
On Monday 2021-07-26 15:42, Michael Ströder wrote:
From the above web page:
"snooze is a new tool for waiting until a particular time and then running a command. Together with a service supervision system such as runit, this can be used to replace cron(8)."
Sounds just like at(1) ;-)
Yes, just without a daemon running.
Which means it's probably gone after reboot.
It is made to work with a supervision system like runit, s6, supervisord. And it could run the same way inside a container as entrypoint. It supports ctime too.
On Mon, Jul 26, Michael Ströder wrote:
What about containers without systemd? No CRON-like function therein?
Why do you want to run cron inside containers? If your container runs on a Kubernetes cluster, I would use the cron functionality from kubernetes for this. Somebody wrote already that there is also a solution for docker-compose, but I don't use that. Else I use systemd timers to run the container peridically, e.g. to update my "let's encrypt" certificates. All of this is much more robust than cron inside a container. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On 7/27/21 9:02 AM, Thorsten Kukuk wrote:
On Mon, Jul 26, Michael Ströder wrote:
What about containers without systemd? No CRON-like function therein?
Why do you want to run cron inside containers?
Yes, I know about pods and all the container paradigm of one process per container. There are openSUSE packages where a main services depends on periodically executed background jobs. For example unbound with its sub-package unbound-anchor. With the transition to systemd timers it's more difficult for admins to execute this in a container simply based on openSUSE packages. Ciao, Michael.
On Tue, 27 Jul 2021 09:02:07 +0200, Thorsten Kukuk wrote:
What about containers without systemd? No CRON-like function therein?
Why do you want to run cron inside containers?
Because it's familiar and easy to do for a simple task. I've got a process that goes out and periodically grabs info from various sources on the Internet - it's in a container all by itself, with the output being handled by a second container. Could I do it differently? Sure, but cron is easy to setup and understand, and is very lightweight. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Am Montag, 26. Juli 2021, 12:02:33 CEST schrieb Danilo Spinella:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it. For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
Complete agreement. I don't use systemd.timers. I don't like systemd.times. And cron is adjusted and configured a lot faster. And I will use it as long as it is available or create my own packages. So. And now you could attack me :-) Regards Eric
On Mon, 26 Jul 2021 15:42:42 +0200, Eric Schirra <ecsos@opensuse.org> wrote:
Am Montag, 26. Juli 2021, 12:02:33 CEST schrieb Danilo Spinella:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
[...]
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it. For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
Complete agreement. I don't use systemd.timers. I don't like systemd.times. And cron is adjusted and configured a lot faster.
+1 !
And I will use it as long as it is available or create my own packages.
Same here One more argument: if you (have to) maintain many systems, including (very) old distributions, having the same tool THAT JUST WORKS AS EXPECTED on all systems makes a lot of a difference. I still have piles of cronfiles in my backup if users (and customers) break things, so I can just restore that file with `crontab foo.cron` and be done with it. There are even (java) applications that support (and recognize) cron-files, so I can just import them. As long as cron is available either from core or from 3rd-party providers, I will keep using it.
So. And now you could attack me :-)
Regards Eric
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
On 7/26/21 3:42 PM, Eric Schirra wrote:
Am Montag, 26. Juli 2021, 12:02:33 CEST schrieb Danilo Spinella:
On Mon, 2021-07-26 at 11:39 +0200, Carlos E. R. wrote:
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
openSUSE will ship systemd timers with the packages but can't remove cronie because a lot of users still use it. For this reason I think it's good to deprecate run-crons and use a well-maintaned program instead.
Complete agreement. I don't use systemd.timers. I don't like systemd.times.
Drawback of systemd timers are that you always have to maintain two files foo.timer and foo.service. And in containers there is most times no systemd (except Kata containers or similar). The advantage is that you have way better control over the timing, e.g. run a script more than once during a minute, or run stuff after time-sync, etc. Another advantage is that like with any other .service you can use systemd's sandboxing service directives for your systemd timer jobs. But still I'd prefer to keep cronie around because many people are used to this very basic service. Ciao, Michael.
Dne 26. 07. 21 v 11:39 Carlos E. R. napsal(a):
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
Which are such PITA, that I am planning to switch to switch to cronie. Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 kakistocracy, n.: Government by the least qualified or most unprincipled citizens. -- first used by Thomas Love Peacock in 1829
On 27/07/2021 08.28, Matěj Cepl wrote:
Dne 26. 07. 21 v 11:39 Carlos E. R. napsal(a):
On 26/07/2021 11.21, Danilo Spinella wrote:
Any feedback on this change?
openSUSE is moving to systemd timers, AFAIK.
Which are such PITA, that I am planning to switch to switch to cronie. Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM?
I have no idea. I also use cron for things. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 27.07.21 08:28, Matěj Cepl wrote:
Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM?
Yes. Either enable lingering with loginctl or add an "autologin on console" hack (raspbian style). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Dne 27/07/2021 v 21:55 Stefan Seyfried napsal(a):
On 27.07.21 08:28, Matěj Cepl wrote:
Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM?
Yes. Either enable lingering with loginctl or add an "autologin on console" hack (raspbian style).
Hmm, jeronym:~ # loginctl show-user mcepl UID=1000 GID=100 Name=mcepl Timestamp=Thu 2021-07-22 10:12:22 UTC TimestampMonotonic=8027677 RuntimePath=/run/user/1000 Service=user@1000.service Slice=user-1000.slice Display=13 State=closing Sessions=13 IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Linger=yes jeronym:~ # and mcepl@jeronym:~> systemctl --user list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2021-07-28 01:39:00 UTC 4h 1min left n/a n/a find_non_integrated.timer find_non_integrated.service Sun 2021-08-01 02:12:00 UTC 4 days left Sun 2021-07-25 02:12:04 UTC 2 days ago pypi_updates.timer pypi_updates.service 2 timers listed. Pass --all to see loaded but inactive timers, too. mcepl@jeronym:~> And yet, those two tasks are not run automagically. Any ideas? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 understand, v.: To reach a point, in your investigation of some subject, at which you cease to examine what is really present, and operate on the basis of your own internal model instead.
Hi Matěj, On 27.07.21 23:38, Matěj Cepl wrote:
Dne 27/07/2021 v 21:55 Stefan Seyfried napsal(a):
On 27.07.21 08:28, Matěj Cepl wrote:
Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM?
Yes. Either enable lingering with loginctl or add an "autologin on console" hack (raspbian style).
Hmm,
jeronym:~ # loginctl show-user mcepl ... Linger=yes jeronym:~ #
and
mcepl@jeronym:~> systemctl --user list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2021-07-28 01:39:00 UTC 4h 1min left n/a n/a find_non_integrated.timer find_non_integrated.service Sun 2021-08-01 02:12:00 UTC 4 days left Sun 2021-07-25 02:12:04 UTC 2 days ago pypi_updates.timer pypi_updates.service
2 timers listed. Pass --all to see loaded but inactive timers, too. mcepl@jeronym:~>
And yet, those two tasks are not run automagically.
Any ideas?
No, not really. It works for me on a raspbian system, but there I have a console autologin enabled and not switched to logind lingering, just because it was configured like that from the beginning. So I was actually speaking from theory. Maybe you found a bug in logind? The autologin is done with a dropin file: # cat /etc/systemd/system/getty@tty1.service.d/autologin.conf [Service] ExecStart= ExecStart=-/sbin/agetty --autologin pi --noclear %I $TERM but yes, it's a workaround for lingering not working as expected for you. Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 27.07.21 um 23:38 schrieb Matěj Cepl:
On 27.07.21 08:28, Matěj Cepl wrote:
Do you know how to make reliably work user timers on the remote SSH-access-only rarely visited VM?
Hmm,
jeronym:~ # loginctl show-user mcepl
...
And yet, those two tasks are not run automagically.
Any ideas?
Matěj
Since you obviously have superuser privileges on the VM, why don't you register the timer and service unit with the system-wide systemd instead? You can still run the executable as user [1]: # cat /etc/systemd/system/pypi_updates.service [Unit] Description=Check PyPI packages for updates [Service] Type=oneshot User=mcepl ExecStart=/path/to/your/executable [Install] WantedBy=basic.target # Ben [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User/Grou...
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then 42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done might just be as sufficient, not requiring debianutils. On the other hand, this would be an opportunity for systemd to just automatically scan those directories, similar to what systemd-fstab-generator does with /etc/fstab.
On Mon, 2021-07-26 at 15:34 +0200, Jan Engelhardt wrote:
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then
42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done
might just be as sufficient, not requiring debianutils.
However this does not preserve the old behaviour.
On the other hand, this would be an opportunity for systemd to just automatically scan those directories, similar to what systemd-fstab- generator does with /etc/fstab.
There could be a systemd timer for each folder, it can be done.
On Mon, Jul 26, 2021 at 10:13 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then
42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done
might just be as sufficient, not requiring debianutils.
On the other hand, this would be an opportunity for systemd to just automatically scan those directories, similar to what systemd-fstab-generator does with /etc/fstab.
I am a little surprised that we don't have a generator for cron to systemd timers. Is there a particular reason we don't have that? -- 真実はいつも一つ！/ Always, there's only one truth!
On 26.07.21 16:50, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs.
Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11. I'm not sure that Walmart is the biggest SLES customer, and if they are stuck on SLES11, they are not going to care about what will be dropped in tumbleweed anyway, but there are other SLES customers, that also consider themselves as the biggest or most important ;-), who would certainly dislike the removal of cron jobs without a drop-in replacement.
And I just checked, all available SLES versions up to 15-SP3 still contain a working cron daemon. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out: openSUSE has no SLES customers. openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support) SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base. openSUSE being maintained by all kind of contirbutors (some sponsored by various companies, SUSE being one of them, but not the only one) is free to maintain in their repositories anything they wish (for as long as there are actively maintainers taking care of it); so even if SUSE were to decide to drop cronie from their products, openSUSE, the community, would be free to keep cronie in the openSUSE distributions. This *might( require a new set of maintainers looking after it though, as the people sponsored to look after cronie might no longer be assigned said task (as there is no benefit for the sponsor). Cheers, Dominique
On 26/07/2021 17.21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
Not fully correct :-) openSUSE Leap derives from SLES, not the other way round, and as such I expect it to continue having a cron daemon if SLES continues having it. And Leap has pledged compatibility with SLES. Tumbleweed is different and as you describe. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On Mon, Jul 26, 2021 at 1:52 PM Carlos E. R. <carlos.e.r@opensuse.org> wrote:
On 26/07/2021 17.21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
Not fully correct :-)
openSUSE Leap derives from SLES, not the other way round, and as such I expect it to continue having a cron daemon if SLES continues having it.
And Leap has pledged compatibility with SLES.
Tumbleweed is different and as you describe.
And Tumbleweed is the start of the journey for openSUSE Leap, as all Leap major releases begin life as a fork of a particular Tumbleweed snapshot. So our decisions in Tumbleweed still do matter for the next major SLE version, which becomes the next major Leap version. -- 真実はいつも一つ！/ Always, there's only one truth!
On 27/07/2021 04.54, Neal Gompa wrote:
On Mon, Jul 26, 2021 at 1:52 PM Carlos E. R. <carlos.e.r@opensuse.org> wrote:
On 26/07/2021 17.21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
Not fully correct :-)
openSUSE Leap derives from SLES, not the other way round, and as such I expect it to continue having a cron daemon if SLES continues having it.
And Leap has pledged compatibility with SLES.
Tumbleweed is different and as you describe.
And Tumbleweed is the start of the journey for openSUSE Leap, as all Leap major releases begin life as a fork of a particular Tumbleweed snapshot. So our decisions in Tumbleweed still do matter for the next major SLE version, which becomes the next major Leap version.
I am aware: but I imagine that if SLES customers demand cron, SUSE will keep cron on their own for SLES even if factory doesn't. :-) -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 7/27/21 8:11 PM, Carlos E. R. wrote:
On 27/07/2021 04.54, Neal Gompa wrote:
On Mon, Jul 26, 2021 at 1:52 PM Carlos E. R. <carlos.e.r@opensuse.org> wrote:
On 26/07/2021 17.21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
Not fully correct :-)
openSUSE Leap derives from SLES, not the other way round, and as such I expect it to continue having a cron daemon if SLES continues having it.
And Leap has pledged compatibility with SLES.
Tumbleweed is different and as you describe.
And Tumbleweed is the start of the journey for openSUSE Leap, as all Leap major releases begin life as a fork of a particular Tumbleweed snapshot. So our decisions in Tumbleweed still do matter for the next major SLE version, which becomes the next major Leap version.
I am aware: but I imagine that if SLES customers demand cron, SUSE will keep cron on their own for SLES even if factory doesn't. :-)
If SUSE want's to keep something on SLES they will also keep it on Tumbleweed otherwise when they create the next SLES the package wont be there anymore. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello, On 2021-07-26 17:21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
openSUSE being maintained by all kind of contirbutors (some sponsored by various companies, SUSE being one of them, but not the only one) is free to maintain in their repositories anything they wish (for as long as there are actively maintainers taking care of it); so even if SUSE were to decide to drop cronie from their products, openSUSE, the community, would be free to keep cronie in the openSUSE distributions. This *might( require a new set of maintainers looking after it though, as the people sponsored to look after cronie might no longer be assigned said task (as there is no benefit for the sponsor).
Yes in theory but in practice "tertium datur" (basically always): In practice without SUSE customers who pay money openSUSE would be much less than what it is. So in practice openSUSE depends (to some extent) on SUSE customers. openSUSE is intentionally set up so that it can exist without SUSE but I assume that is not what is wanted in practice. openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward. I think in reality openSUSE and SUSE depend on each other so I would hope both cooperate. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer
On 7/27/21 3:06 PM, jsmeix wrote:
Hello,
On 2021-07-26 17:21, Dominique Leuenberger / DimStar wrote:
On Mon, 2021-07-26 at 09:50 -0500, Larry Len Rainey wrote:
Don't forget that root is not the only user that runs cron jobs. Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
Well, since this is an openSUSE mailing list, I have to point out:
openSUSE has no SLES customers.
openSUSE is a community, producing community-backed distributions (openSUSE Leap, openSUSE Tumbleweed, Kubic. MicroOS) and has no 'customers' (in the sense of paying and support 'entitled' customers). We call them simply users (who often become contributors by the fact that they help each other out and give each other support)
SUSE, the main sponsor of openSUSE, produces own products based on openSUSE's distributios and packages. One such product being SLES (SUSE Linux Enterprise Server) and SUSE has a customer base.
openSUSE being maintained by all kind of contirbutors (some sponsored by various companies, SUSE being one of them, but not the only one) is free to maintain in their repositories anything they wish (for as long as there are actively maintainers taking care of it); so even if SUSE were to decide to drop cronie from their products, openSUSE, the community, would be free to keep cronie in the openSUSE distributions. This *might( require a new set of maintainers looking after it though, as the people sponsored to look after cronie might no longer be assigned said task (as there is no benefit for the sponsor).
Yes in theory but in practice "tertium datur" (basically always):
In practice without SUSE customers who pay money openSUSE would be much less than what it is.
So in practice openSUSE depends (to some extent) on SUSE customers.
Yes but only to the extent that under SUSE's "Factory First" policy SUSE pays people to contribute things to openSUSE that it believes will be useful to its customers. Although its worth noting that occasionally SUSE customers also contribute directly to openSUSE. Having said that in the context of this discussion its reasonable to presume that if SUSE believes a package is useful for its customers then it will continue to pay someone to maintain it, if it doesn't think its useful for customers (or useful enough to cover the cost) then its likely they won't at the same time they won't stop someone in the openSUSE community from doing it.
openSUSE is intentionally set up so that it can exist without SUSE but I assume that is not what is wanted in practice.
Well practice its actually not, while it does have the freedom to make decisions on its own it doesn't have a legal entity which means it can't do things like setup a bank account, collect funds, own hardware or intellectual property such as trademarks. So openSUSE very much needs to depend on SUSE for all these things.
openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward.
Well yes and no, you are correct that openSUSE is intentionally setup without paying attention to what SUSE customers need, however in practice SUSE pays a not insignificant number of employees to work in the openSUSE community and care about what its customers need, again the factory first policy is a good example of how SUSE cares that the things important to its customers do end up in openSUSE. At the end of the day the openSUSE community is made up largely of the people that contribute to it and currently a significant percentage of those people are SUSE employees caring about what SUSE customers need so at the moment its hard to see a world where the openSUSE community or atleast significant parts of it don't care about openSUSE customers.
I think in reality openSUSE and SUSE depend on each other so I would hope both cooperate.
Yes in general they do cooperate quite well other then the occasional minor issues, i'm yet to see anything in this thread that would indicate they are not cooperating... -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tue, 2021-07-27 at 07:36 +0200, jsmeix wrote:
openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward.
Considering that SUSE's current customer base is extremely conservative, I think if openSUSE paid attention to what SUSE current customers need then that would have two clear outcomes 1. openSUSE would never move forward 2. SUSE would never get more customers Given we know for a fact that SUSE wants #2 in order to be able to grow, I most certainly think it's in SUSE's best interest to faciliate #1 and enable openSUSE's moving forward. Hence fellows like Thorsten driving long term changes in openSUSE as part of his SUSE responsibilities as SLE Architect perhaps... Regards, Richard
Hello, On 2021-07-27 10:11, Richard Brown wrote:
On Tue, 2021-07-27 at 07:36 +0200, jsmeix wrote:
openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward.
Considering that SUSE's current customer base is extremely conservative, I think if openSUSE paid attention to what SUSE current customers need then that would have two clear outcomes
1. openSUSE would never move forward 2. SUSE would never get more customers
Again "tertium datur": If openSUSE did not pay attention to what SUSE current customers need then that would have one clear outcome: 3. SUSE would lose customers I think a SUSE goal should be "support existing customers" that gets at least as much attention as "get new customers" because only existing customers pay the current costs and likely existing customers will pay most of the future costs. But this is an openSUSE mailing list which is not the right place to talk about SUSE things so I better stop here. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer
On Tue, Jul 27, jsmeix wrote:
Hello,
On 2021-07-27 10:11, Richard Brown wrote:
On Tue, 2021-07-27 at 07:36 +0200, jsmeix wrote:
openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward.
Considering that SUSE's current customer base is extremely conservative, I think if openSUSE paid attention to what SUSE current customers need then that would have two clear outcomes
1. openSUSE would never move forward 2. SUSE would never get more customers
Again "tertium datur":
If openSUSE did not pay attention to what SUSE current customers need then that would have one clear outcome:
3. SUSE would lose customers
No, it wouldn't because you forgot one important point: (SLES <=> Leap) != Tumbleweed. From SUSEs point of view Tumbleweed needs to move forward to be able to create the next SLES from it with all the new stuff customers want, which are to intrusive to implement in current, froozen SLES/Leap distributions. And this also means new areas like Embedded, Edge and Kubernetes. Not only traditional Desktop and Server. Tumbleweed should not fulfill the requirements of the old very conservative SLES customers, for them we will continue to support old SLES versions in parallel. Like we have/had SLES11 with SysV init for all the customers who didn't wanted to switch to systemd because it was to new for them, while SLES12 with systemd fulfilled the requirements of the customers, which were to restricted by SysV init and needed something modern and flexible. And from openSUSE's point of view Tumbleweed needs to move forward to not fall behind the other Linux distributions. For the conservative openSUSE users, we have openSUSE Leap instead. And for the venturesome openSUSE users we have MicroOS, MicroOS Desktop and Kubic :)
I think a SUSE goal should be "support existing customers" that gets at least as much attention as "get new customers" because only existing customers pay the current costs and likely existing customers will pay most of the future costs.
Correct. And for this we have SLES on the SUSE and Leap on the openSUSE side. For new customers, and especially to fullfill the requirements of current, moving forward customers and to integrate new technology wanted by this customers, Tumbleweed is the vehicle to implement new things, especially if they are not compatible, and either use it for the next SLES or backport to an old SLES. openSUSE Tumbleweed will never fulfill the requirements of SUSEs conservative customers, because it's moving to fast forward. Already only by having always the latest upstream kernel. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Tue, 2021-07-27 at 10:45 +0200, jsmeix wrote:
Hello,
On 2021-07-27 10:11, Richard Brown wrote:
On Tue, 2021-07-27 at 07:36 +0200, jsmeix wrote:
openSUSE is intentionally set up so that it can exist without paying any attention to what SUSE customers need but I think that is not helpful to move forward.
Considering that SUSE's current customer base is extremely conservative, I think if openSUSE paid attention to what SUSE current customers need then that would have two clear outcomes
1. openSUSE would never move forward 2. SUSE would never get more customers
Again "tertium datur":
If openSUSE did not pay attention to what SUSE current customers need then that would have one clear outcome:
It is not the responsibility of the openSUSE community, but rather the interest of SUSE as a contributor to the community, and the upstream projects (i.e. Tumbleweed) to get the things SUSE wants to see, ready and usable. SUSE with its sponsored work force clearly has some 'power to steer the boat', but it is definitively NOT THE ONLY body doing so (just look at the work done to get dnf fully ready for use: clearly nothing SUSE initiated, yet, it might well be that SUSE adapts to it in the end)
3. SUSE would lose customers
Then I'm sorry to say: SUSE would not have taken care of playing nice with upstream, would have failed to communicate the interest, not have taken care of the code in first place or not have taken the chance to diverge from upstream when it made sense. Nobody but SUSE to blame in this case (hypotetical - this is clearly not what is happening now)
I think a SUSE goal should be "support existing customers"
Sure, SUSE's goal - not openSUSE's goal. openSUSE's goal is to make a distribution (or two, or three) for the openSUSE user base. The fact that we are allowed to re-use the binaries from SLE, and extend thiem with community-maintained packagehub packages is a welcome offer from SUSE - which was gladly accepted for 15.3. But still does not make SUSE the power over openSUSE.
that gets at least as much attention as "get new customers" because only existing customers pay the current costs and likely existing customers will pay most of the future costs.
Still SUSE's business - not openSUSE.
But this is an openSUSE mailing list which is not the right place to talk about SUSE things so I better stop here.
Tpo this I agree :) Cheers, Dominique
On Mon, Jul 26, 2021 at 10:50 AM Larry Len Rainey <llrainey15@gmail.com> wrote:
Your biggest SLES customer has 10 different cron users and has C programs that add and delete entries to cron to emulate the old IBM Series 1 applications that they have run since 1984 on Unix and now SLES 11.
All released enterprise products still contain a working cron daemon..it will continue to work, but systemd-timers while they require more tying and configuration files.. offer waay more flexibility and features..
I doubt that there are anyone left that remember the crash development to go from Series 1 to Unix - With over 10,000 store world wide
Legacy code is a pain that every enterprise faces.. I',m not particularly concerned about those from a multi-billon dollar corporation , which has enough money to rewrite EOL software withj something modern.
On Mon, Jul 26, 2021 at 10:17:08AM -0400, Neal Gompa wrote:
On Mon, Jul 26, 2021 at 10:13 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then
42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done
might just be as sufficient, not requiring debianutils.
On the other hand, this would be an opportunity for systemd to just automatically scan those directories, similar to what systemd-fstab-generator does with /etc/fstab.
I am a little surprised that we don't have a generator for cron to systemd timers. Is there a particular reason we don't have that?
The most obvious reason is that somebody would have to write it, and so far nobody has, afaik. But there's also the consideration that crond/anacron/cronie/… have various additional functionality like automatic sending of mails, custom reporting, etc. I think that the thinking was that people who use cron might want to have those things, and will be happier using cron than trying to provide similar-but-different functionality using systemd. The cost of running a cron daemon is pretty low, so there didn't seem to be any pressing need to move. One particular feature that works quite differently is user tasks: with cron the user can just schedule tasks. With systemd, the user session provides equivalent functionality, but only when it's active. Lingering allows user tasks without a session, but it has other effects and is a more heavy-weight solution. We generally think that tasks that were often handled using a user crontab entry should instead be converted to a system unit with User=…. The summary is: the functionality is somewhat different, and having cron in parallel to systemd timers is not a problem. If somebody wants to investigate various options and provide some converter, I expect it would be useful to some people, but it's not trivial and some people will not be happy with the changes. Zbyszek
Hello, Am Montag, 26. Juli 2021, 15:34:36 CEST schrieb Jan Engelhardt:
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then
42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done
might just be as sufficient, not requiring debianutils.
It's not that easy ;-) The above works for systems that are running 24/7, but will fail for systems that get switched on at "random" times (whenever their user is awake and/or in the office). If the system was switched off for a while ("missing" the calculated time of a cron.daily run), the cron.daily jobs will run some minutes after boot. With using fixed times, they will never run if the system is switched off at this time. I'd guess if you indeed use 4:02 for cron.daily, it's quite likely that the system is switched off - and no, you can't fix that by picking a seemingly "better" time ;-)
On the other hand, this would be an opportunity for systemd to just automatically scan those directories, similar to what systemd-fstab-generator does with /etc/fstab.
If it's really fully compatible with what cronie does, and doesn't get marked as deprecated and/or unsupported in some years, I have no objections. Unfortunately this is exactly what happened to initscript support, therefore I tend to prefer keeping cronie ;-) Regards, Christian Boltz -- Foot: A device for finding furniture in the dark
On Mon, 2021-07-26 at 21:37 +0200, Christian Boltz wrote:
Hello,
Am Montag, 26. Juli 2021, 15:34:36 CEST schrieb Jan Engelhardt:
On Monday 2021-07-26 11:21, Danilo Spinella wrote:
run-parts program from debian seems reliable and well-written. However, the crontab needs to be updated to use it:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
If that is all we need to do, then
42 4 1 * * root for i in /etc/cron.monthly/*; do [ -x "$i" ] && [ -f "$i" ] && "$i"; done
might just be as sufficient, not requiring debianutils.
It's not that easy ;-)
The above works for systems that are running 24/7, but will fail for systems that get switched on at "random" times (whenever their user is awake and/or in the office).
If the system was switched off for a while ("missing" the calculated time of a cron.daily run), the cron.daily jobs will run some minutes after boot.
off at this time. I'd guess if you indeed use 4:02 for cron.daily, it's quite likely that the system is switched off - and no, you can't fix that by picking a seemingly "better" time ;-)
I think you're looking for anacron (which is provided as a subpackage of cronie).
participants (22)
-
Ben Greiner -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Cristian Rodríguez -
Danilo Spinella -
Dominique Leuenberger / DimStar -
Eric Schirra -
H.Merijn Brand -
Jan Engelhardt -
jdd＠dodin.org -
Jim Henderson -
jsmeix -
Larry Len Rainey -
Matěj Cepl -
Michael Ströder -
Neal Gompa -
Richard Brown -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk -
Zbigniew Jędrzejewski-Szmek