On Thu, Nov 20, 2014 at 03:54:58PM +0100, Carlos E. R. wrote:
On 2014-11-20 15:17, Anton Aylward wrote:
You can add them to the startup scripts if there were some... Ruben
Carlos has justified why it came about, although I can see ways where it would fail whereas as systemd implementation might work better.
Consider: turning the system on for just a short while, to read mail perhaps, then off again multiple times a day, and it being off when the cron.daily is scheduled, is going to break a lot of assumptions. It may also be off when you have your fixed time crontab entry. I grant you that such usage is inappropriate for a PC and more suited to a smartphone, but yes, some pole will use the PC like that. Live with it.
Well, suppose the jobs ran the last time at 15:15 two days ago.
Yesterday it was powered up at 15:05 and powered off at 15:10. The jobs did not run.
Today I connect it at 15:10 and power off at 15:20: the jobs will start at 15:15:01. And will be killed at 15:20 if not finished.
If instead I power it up today at 20:25, the jobs will run at 20:30. From then on, they will always run at 20:30 unless not running at that time, instead than 15:15.
If it is never up at XX:00, XX:15 XX:30, XX:45, then they will never run.
That was the situation till recently.
Now the difference is that you choose a preferred time to run the jobs (all). If the machine is not running that time (on the quarter), it will wait till the next day, and the next, and the next, waiting for it to be up at the preferred time - up till 15 days (configurable), and then it will run at the first available quarter.
While systemd.timer Has the ability to schedule "30 min after boot then once daily" that too gets buqqered up by repeated short boots as mentioned above. In effect the system has no memory unless you go to lengths to record what has been done. The /usr/lib/cron/run-crons program goes part of the way by having a timestamp, but a proper mechanism needs more granularity than that.
A systemd method would be acceptable, IF there is a single place to configure it. Not having to go in a chase on several, difficult to find, directories and files and symlinks and commands. Features like controlling the amount of resources are interesting.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org