Revision 9269d118
| 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