Currently it’s expected that local script can give not error-code 0 as return
CRIT - Exit-Code: 1 (!!), Started: 2020-03-01 01:00:01, Real-Time: 1.53 s, User-Time: 220 ms, System-Time: 50.0 ms, Filesystem Reads: 0, Filesystem Writes: 16, Max. Memory: 16.28 MB, Avg. Memory: 0 B, Vol. Context Switches: 40, Invol. Context Switches: 26(!!)
But this is as expected for us, because we can’t control what outside of our network. But it is robust enough that it will catch up on all the work if it run successfully once a day.
Current options for mk-job
We like a option that provide more intelligent based on the error-code output. To delay the change the state to warning/critical.
For example that the job need to run once a day with error-code 0. Or at least once a day with error-code 0.
- normal check interval
- retry check interval
- maximum number of check attempts
according to your needs.
Thanks for the suggestion.
We could find a way to make it work with that option. Due to the fact that the running script return not 0 as error code and mk-job check for error-code always. You can’t ignore the error code with a parameter without disable the mk-job service