On 05/11/2017 16:28, Kai Peter wrote: > > > On 2017-11-04 18:42, Ian Zimmerman wrote: > >> On 2017-11-04 01:39, Kai Peter wrote: > >> > >>> > If you want to run a monthly job on a host that is not always on, do > >>> > you have to pretend it's an hourly job and check in the script > >>> > itself? > >>> > >>> This is a special case to me. IMHO special cases have to be handled > >>> special or much better: avoid it. > >> > >> Sorry, I don't get this. How do you avoid this situation? By not > >> having any monthly jobs? > > No, monthly jobs are fine, but you mentioned a special case as the host > is may be off at that time. Perhaps you can do: run all jobs which > didn't run because the host was off at next startup once. fcron has such > an option. Depending on the exact situation it could require additional > configuration/checks.
It is not really cron's job to figure out what it thinks the user might want if the machine was off when the job should have run. That is expecting far too much intelligence from cron. Cron is wall-clock time and time based: When the time is *this*, then do *that* anacron has some logic for this case of jobs not run but to do it, it had to give up it's strictly wall-clock time based approach There are other schedulers out there that succeed where cron fails (eg Control-M, chronos, quartz), but those are all large, bulky, designed for big complex installs/requirements and probably not suited for simple things you'd deploy out of a base in portage cron is stupid and deliberately so. We really ought to let it remain stupid > The decision what have to be done MUST be made by the user/sysadmin > first. Than you can do the config to reach your goal. But that does go > to far now. +1 agreed. I've always maintained that cron cannot possibly know what the scripts it launches deem to be correct. It's a countdown time and launcher, not an orchestrator. It can figure out what to do if 2am happens twice (just don't do it the second time), but not what should happen if 2am was missed for any reason, including DST or poweroff or overeager ntpdate The simplest approach to fixing missed jobs is to have the script itself track what is correct. If it's lock and records files indicate something didn't happen when it should, the script can do it's own repair or do it's work twice. Or whatever else is appropriate. -- Alan McKinnon alan.mckin...@gmail.com
