| 1 |
On 2017-10-29 14:16, Michael Orlitzky wrote: |
| 2 |
|
| 3 |
> On 10/29/2017 07:46 AM, Remy Blank wrote: |
| 4 |
|
| 5 |
>> |
| 6 |
|
| 7 |
>> I attached a patch to the bug, but considering how old the bug is, and |
| 8 |
|
| 9 |
>> from the tone of the discussion there, I have little hope that it gets |
| 10 |
|
| 11 |
>> applied. If you would like to see this fixed, it may be worth chiming |
| 12 |
|
| 13 |
>> in |
| 14 |
|
| 15 |
>> on the bug. Or if you're a kind Gentoo developer listening to affected |
| 16 |
|
| 17 |
>> users, to take action. |
| 18 |
|
| 19 |
>> |
| 20 |
|
| 21 |
> |
| 22 |
|
| 23 |
> If only it were that easy. First: vapier is the only member of the cron |
| 24 |
|
| 25 |
> project, and he's happy with the way cronbase works. |
| 26 |
|
| 27 |
|
| 28 |
|
| 29 |
This shows the lack of maintainers only. Don't wanna start a discussion |
| 30 |
|
| 31 |
about the reasons. IMHO the cronbase ebuild is faulty by design - sorry. |
| 32 |
|
| 33 |
> |
| 34 |
|
| 35 |
> And then the real issue: no one knows what our cronbase is doing, and |
| 36 |
|
| 37 |
> it |
| 38 |
|
| 39 |
> does whatever it does all wrong -- but some people are probably relying |
| 40 |
|
| 41 |
> on it. My proposal was to make cronbase stupider, with something like |
| 42 |
|
| 43 |
> |
| 44 |
|
| 45 |
> 9 5 * * * root find /etc/cron.daily -execdir '{}' \; |
| 46 |
|
| 47 |
> |
| 48 |
|
| 49 |
> That says: run everthing in cron.daily[0], every day, at 05:09. It does |
| 50 |
|
| 51 |
> exactly that: it has DST issues, if your machine is off the jobs won't |
| 52 |
|
| 53 |
> run, etc. But it's predictably stupid and works as advertised, unlike |
| 54 |
|
| 55 |
> the run-crons shell script we have now. |
| 56 |
|
| 57 |
|
| 58 |
|
| 59 |
Looks a bit like a concept. As I have to work with different OS's I |
| 60 |
|
| 61 |
defined for me: |
| 62 |
|
| 63 |
|
| 64 |
|
| 65 |
1. a crontab entry have to call a shell script always, at least a |
| 66 |
|
| 67 |
(minimal) wrapper |
| 68 |
|
| 69 |
2. the shell script have to do some checks, e.g. the last run - I did |
| 70 |
|
| 71 |
wrote a small 'include' script for that |
| 72 |
|
| 73 |
|
| 74 |
|
| 75 |
Thus it's portable. The job have to be done once. |
| 76 |
|
| 77 |
|
| 78 |
|
| 79 |
> |
| 80 |
|
| 81 |
> Do you need something smarter? Install anacron, fcron, cronie, or |
| 82 |
|
| 83 |
> whatever. But the worst thing we can do is try to mimic those |
| 84 |
|
| 85 |
> intelligent crons and have it fail to do so randomly. That's still your |
| 86 |
|
| 87 |
> best option, by the way: rewrite your crontab to avoid run-crons, and |
| 88 |
|
| 89 |
> install a smart cron implementation that does what you want. |
| 90 |
|
| 91 |
|
| 92 |
|
| 93 |
*I* recommend fcron, it is a bit under estimated. Beside its progressive |
| 94 |
|
| 95 |
design and w/o consulting the man page now again - AFAIR it can handle |
| 96 |
|
| 97 |
DST issues like above through options in fcrontab. But with my concept I |
| 98 |
|
| 99 |
don't need/use it. Be aware that some options could show an unexpected |
| 100 |
|
| 101 |
behavior too - nothing is perfect. Anyhow, by using fcron it is possible |
| 102 |
|
| 103 |
to eliminate the whole cronbase ebuild - it is part of the 20 percent |
| 104 |
|
| 105 |
(round about) which are faulty in Gentoo. |
| 106 |
|
| 107 |
|
| 108 |
|
| 109 |
Just an opinion. |
| 110 |
|
| 111 |
> |
| 112 |
|
| 113 |
> |
| 114 |
|
| 115 |
> |
| 116 |
|
| 117 |
> [0] In practice, you would want to pass "-type f", "-executable", and |
| 118 |
|
| 119 |
> "-maxdepth 1" to the "find" command as well. |
| 120 |
|
| 121 |
|
| 122 |
|
| 123 |
-- |
| 124 |
|
| 125 |
Sent with eQmail-1.10 |
Archives