In an ideal situation, the marked check should not be needed, and
we should just be able to validate if the client is connected or not.
Unfortunately, the boinc_client code does not gracefully handle the case
of the remote end not being connected, so we need to check at a lower
level that the TCP connection is still in a CONNECTED state.
This simplifies the code a bit.
THe `reconnect()` method is being explicitly kept for clarity reasons,
and includes a comment that a disconnect is not mandatory when trying to
reconnect.
* Fixed build for sane platforms which have case sensitive VFS layers.
* Fixed two issues in web/dashboard_info.js
* SImplified code to determine if the connection is alive.
* Simplified code so we don't use copy.deepcopy()
This adds a python.d module for monitoring Berkeley Open Infrastructure
Network Computing clients. This is the framework utilized by a vast
majority of publicly run distributed computing projects (including
SETI@Home and World Community Grid).
This only tracks the number of tasks in various task states on the
system, as almost everything else is trivial to track using other
existing plugins (such as apps.plugin). It utilizes the same RPC
mechanism that the official GUI management tool for BOINC clients uses.
In most cases, the data this tracks is not hugely interesting (it doesn't
change very often, and generally doesn't change very much on any given
system), but there are a handful of situations that it lets us provide
alerts for that are of particular interest to users running BOINC on
headless systems (namely computational errors, reporting failures,
and running out of tasks to run).
Internally, BOINC has 3 state-machines that a given task will advance
through, the task state, scheduling state, and process state. The task
state tracks the high-level status of the task (is it new, ready to run,
finished running and being reported, hit a computational error, etc).
the scheduling state tracks whether the scheduling algorithm says the
task can run or not, and the process state tracks the status of the
aassociated process for the task that does the actual computing. This
module provides charts tracking task counts in each state for each of
these state machines, as well as one counting total number of local
tasks, and how many tasks are 'active' (that is, how many are being
considered for processing).
We also provide a set of default alarms to alert on compute errors,
upload/reporting failures, an empty local task queue, and a low number
of active tasks.
Currently, the module only runs on Linux systems because it relys on a
Linux specific hack to detect a disconnected socket, but it can monitor
BOINC clients on any platform remotely (including Windows systems).
