1 |
J. Roeleveld <joost@××××××××.org> wrote: |
2 |
> |
3 |
> With the kind of schedules I am working with (and I believe Alan will |
4 |
> also end up with), restarting the whole process from the start can |
5 |
> lead to issues. |
6 |
> Finding out how far the process got before the service crashed can become |
7 |
> rather complex. |
8 |
|
9 |
I am not sure whether I understand this correctly: |
10 |
schedule has not a problem to display which tasks have |
11 |
finished/failed/are still running at any time. |
12 |
Of course, a finer granulation than tasks are not possible ("how far |
13 |
has a certain task got?") because this would require knowledge |
14 |
about the task and how to check it - you need to be able to |
15 |
split your tasks into more shell commands to make a finer granulation |
16 |
available for "schedule". |
17 |
|
18 |
You can just rerun your "driving" script with the effect that the |
19 |
tasks which already are finished/failed will actually not be |
20 |
restarted, but the behaviour is as if they would finish immediately |
21 |
and report that they are finished/failed. (When you plan to do this, |
22 |
I would suggest to schedule things like "sleep" as separate tasks, |
23 |
too, and not build them into the "driving" script.) |
24 |
|
25 |
If there is an unexpected problem, and e.g. you want to re-run |
26 |
a failed task anyway, you can just re-queue your new task on |
27 |
the same place as there was the previous task, e.g. |
28 |
schedule remove jobnr |
29 |
schedule -j jobnr queue commmand to do your task |
30 |
Then the old job (and its state) is replaced by the new queued job, |
31 |
and your (identical as before) driving script will start it instead |
32 |
of assuming that the job is already finished. |
33 |
|
34 |
In order to avoid races, I would recommend to do the above only |
35 |
while your driving script is not running (e.g., you can put it |
36 |
in the background with ctrl-z if you have written it in (...) or |
37 |
if it is really a "classical" script, and then continue it with "fg"; |
38 |
or you even stop it completely with Ctrl-c and re-run it, depending |
39 |
on what you want): The problem is that between the above two commands |
40 |
the jobs after "jobnr" are renumbered. |
41 |
Alternatively, you can insert your new job at the end of the joblist |
42 |
and then use something like (untested) |
43 |
schedule -jjobnr insert 0 jobnr+1:-1 |
44 |
schedule remove 0 |
45 |
to to re-sort your job list: The "insert" is race-free, |
46 |
and having added a job at the end for some time will hopefully not |
47 |
disturb anything. |