| 1 |
On 05/11/2017 16:28, Kai Peter wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On 2017-11-04 18:42, Ian Zimmerman wrote: |
| 5 |
> |
| 6 |
>> On 2017-11-04 01:39, Kai Peter wrote: |
| 7 |
> |
| 8 |
>> |
| 9 |
> |
| 10 |
>>> > If you want to run a monthly job on a host that is not always on, do |
| 11 |
> |
| 12 |
>>> > you have to pretend it's an hourly job and check in the script |
| 13 |
> |
| 14 |
>>> > itself? |
| 15 |
> |
| 16 |
>>> |
| 17 |
> |
| 18 |
>>> This is a special case to me. IMHO special cases have to be handled |
| 19 |
> |
| 20 |
>>> special or much better: avoid it. |
| 21 |
> |
| 22 |
>> |
| 23 |
> |
| 24 |
>> Sorry, I don't get this. How do you avoid this situation? By not |
| 25 |
> |
| 26 |
>> having any monthly jobs? |
| 27 |
> |
| 28 |
> No, monthly jobs are fine, but you mentioned a special case as the host |
| 29 |
> is may be off at that time. Perhaps you can do: run all jobs which |
| 30 |
> didn't run because the host was off at next startup once. fcron has such |
| 31 |
> an option. Depending on the exact situation it could require additional |
| 32 |
> configuration/checks. |
| 33 |
|
| 34 |
|
| 35 |
It is not really cron's job to figure out what it thinks the user might |
| 36 |
want if the machine was off when the job should have run. That is |
| 37 |
expecting far too much intelligence from cron. |
| 38 |
|
| 39 |
Cron is wall-clock time and time based: |
| 40 |
|
| 41 |
When the time is *this*, then do *that* |
| 42 |
|
| 43 |
anacron has some logic for this case of jobs not run but to do it, it |
| 44 |
had to give up it's strictly wall-clock time based approach |
| 45 |
|
| 46 |
There are other schedulers out there that succeed where cron fails (eg |
| 47 |
Control-M, chronos, quartz), but those are all large, bulky, designed |
| 48 |
for big complex installs/requirements and probably not suited for simple |
| 49 |
things you'd deploy out of a base in portage |
| 50 |
|
| 51 |
cron is stupid and deliberately so. We really ought to let it remain stupid |
| 52 |
|
| 53 |
> The decision what have to be done MUST be made by the user/sysadmin |
| 54 |
> first. Than you can do the config to reach your goal. But that does go |
| 55 |
> to far now. |
| 56 |
|
| 57 |
+1 agreed. |
| 58 |
|
| 59 |
I've always maintained that cron cannot possibly know what the scripts |
| 60 |
it launches deem to be correct. It's a countdown time and launcher, not |
| 61 |
an orchestrator. It can figure out what to do if 2am happens twice (just |
| 62 |
don't do it the second time), but not what should happen if 2am was |
| 63 |
missed for any reason, including DST or poweroff or overeager ntpdate |
| 64 |
|
| 65 |
The simplest approach to fixing missed jobs is to have the script itself |
| 66 |
track what is correct. If it's lock and records files indicate something |
| 67 |
didn't happen when it should, the script can do it's own repair or do |
| 68 |
it's work twice. Or whatever else is appropriate. |
| 69 |
|
| 70 |
|
| 71 |
-- |
| 72 |
Alan McKinnon |
| 73 |
alan.mckinnon@×××××.com |
Archives