Revision 9269d118 doc/design-daemons.rst
b/doc/design-daemons.rst | ||
---|---|---|
490 | 490 |
|
491 | 491 |
There is a possibility that a job will finish performing its task while LuxiD |
492 | 492 |
and/or WConfD will not be available. |
493 |
In order to deal with this situation, each job will write the results of its |
|
494 |
execution on a file. The name of this file will be known to LuxiD before |
|
495 |
starting the job, and will be stored together with the job ID, and the |
|
496 |
name of the job-unique socket. |
|
497 |
|
|
498 |
The job, upon ending its execution, will signal LuxiD (through the socket), so |
|
499 |
that it can read the result of the execution and release the locks as needed. |
|
500 |
|
|
501 |
In case LuxiD is not available at that time, the job will just terminate without |
|
502 |
signalling it, and writing the results on file as usual. When a new LuxiD |
|
503 |
becomes available, it will have the most up-to-date list of running jobs |
|
504 |
(received via replication from the former LuxiD), and go through it, cleaning up |
|
505 |
all the terminated jobs. |
|
506 |
|
|
493 |
In order to deal with this situation, each job will update its job file |
|
494 |
in the queue. This is race free, as LuxiD will no longer touch the job file, |
|
495 |
once the job is started; a corollary of this is that the job also has to |
|
496 |
take care of replicating updates to the job file. LuxiD will watch job files for |
|
497 |
changes to determine when a job as cleanly finished. To determine jobs |
|
498 |
that died without having the chance of updating the job file, the `Job death |
|
499 |
detection`_ mechanism will be used. |
|
507 | 500 |
|
508 | 501 |
.. vim: set textwidth=72 : |
509 | 502 |
.. Local Variables: |
Also available in: Unified diff