1 |
Michael Orlitzky wrote on 2017-10-29 14:16: |
2 |
> And then the real issue: no one knows what our cronbase is doing, and it |
3 |
> does whatever it does all wrong -- but some people are probably relying |
4 |
> on it. My proposal was to make cronbase stupider, with something like |
5 |
> |
6 |
> 9 5 * * * root find /etc/cron.daily -execdir '{}' \; |
7 |
> |
8 |
> That says: run everthing in cron.daily[0], every day, at 05:09. It does |
9 |
> exactly that: it has DST issues, if your machine is off the jobs won't |
10 |
> run, etc. But it's predictably stupid and works as advertised, unlike |
11 |
> the run-crons shell script we have now. |
12 |
|
13 |
This may solve my problem, but it also changes other behavior that |
14 |
people rely on, as you note, so I understand that there is some |
15 |
resistance to change. My patch only solves the precise issue of |
16 |
double-running jobs on DST to non-DST transition, without changing |
17 |
behavior that people rely on (unless they do rely on the double-running, |
18 |
of course <https://xkcd.com/1172/>). |
19 |
|
20 |
> Do you need something smarter? Install anacron, fcron, cronie, or |
21 |
> whatever. But the worst thing we can do is try to mimic those |
22 |
> intelligent crons and have it fail to do so randomly. That's still your |
23 |
> best option, by the way: rewrite your crontab to avoid run-crons, and |
24 |
> install a smart cron implementation that does what you want. |
25 |
|
26 |
No, my best option is to apply my patch locally and run with that, which |
27 |
is what I've done, but it's always nice to reduce the number of patches |
28 |
to keep track of. My own cron jobs are configured in /etc/cron.d anyway, |
29 |
so they aren't affected. But at least I won't get the email from |
30 |
logwatch twice anymore. |
31 |
|
32 |
-- Remy |