> Given the definition from the documentation My question was not how anybody read what the documentation says. I /did/ read the documentation. Multiple times. My question was what the code actually does (or was intended to do). So given no-one replied who actually read (or better: designed or wrote) the code, I read the code myself. It's a big mess^W°W^Wthe result of historical development, I guess.
So, what (according to my analysis), the code (as of 2.8.1) /actually/ does, is: If there's an unfulfilled /explicit/ dependency, and the check isn't forced, re-schedule the thing. Otherwise, schedule the check for execution. [In the following, "succeeds" doesn't mean OK result. It only means no exec failures or the like.] Shortly before the check is actually going to be executed, then, before actually executing it, re-check the dependencies for an unfulfilled explicit /or implicit/ dependency and store that into what is to be read as last_reachable (but will be over-written shortly after the check succeeded, in case it succeeds). After the check /has actually been successfully executed/, re-check the dependencies again (again for explicit or implicit dependencies). Store the re-checked dependency into what will be read as the "last_reachable" attribute. [Extract certain values from last time visiting this code, see below.] Store the re-checked dependency into what becomes vars_after.reachable. Store the extracted values into what becomes vars_before. Stuff away what has been stored for vars_after, so it cat be recalled next time and stored into vars_before. > Note that somewhat misleadingly, the attribute 'state' will tell you > the state of the object at that last check, whereas 'last_state' will > tell you the state at the *previous* check. Yes, that's only "somewhat" misleading given that there's no 'reachable' attribute and 'last_reachable' actually refers to the /last/ check, not the previous one like the other 'last_*' attributes. So: -- last_reachable will reflect whether shortly /before/ the last check was actually tried to be executed, should the check really have been executed (at that point in time, which is later than the decision at scheduling time, which in turn ignored implicit dependencies), taking into account implcit and explicit dependencies, but not forced checks. -- vars_after.reachable will reflect the same thing shortly after the check was /successfully/ executed. -- vars_before.reachable will relect vars_after.reachable from the last time the check succeeded. Can someone who actually understands, designed or wrote that code tell me whether my analysis is correct, and, if so, what the intended use is? I can't make any sense out of it. The only thing I'm sure of after spending half a working day digging through the code is that there's no such thing as what I'm looking for: A way to tell a check was not scheduled for execution due to dependency constraints (that would need to go into the "if (!check)" block in CheckerComponent::CheckThreadProc). _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
