Werk #22106: job: fix age levels, exit code mapping, missing start times and jobs without a completed run
| Component | Checks & agents | ||
| Title | job: fix age levels, exit code mapping, missing start times and jobs without a completed run | ||
| Date | Aug 11, 2026 | ||
| Level | Trivial Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
This werk bundles several unrelated fixes to the Job ... services:
- the age levels apply to the longest-running instance again,
- running jobs and runs with a missing start time no longer suppress the information that is available,
- the configured exit code mapping is no longer overruled for exit code
0 - and incomplete data is spelled out in the service details.
The age levels are applied to the longest-running job again.
Maximum time since last start of job execution is meant to apply to the longest-running instance - that is what werk #7477 introduced the levels for. Since 2.0.0 they were applied to the instance that started last instead, so a job that kept spawning new instances could stay below the levels indefinitely.
A running file without a usable start time is reported.
While a job runs, mk-job keeps a <job>.<pid>running file holding the start
time. Agents shipped with 2.4.0 and older determine that time with perl and write
an empty one if perl is not installed - on a minimal RHEL 8/9 installation, for
example. Such a file used to be ignored; the service now goes to WARN with
1 running file without a usable start time (PID 12345). The instance is not
counted among the running ones because there is no telling since when it runs.
Updating the agent on the monitored host, or installing perl there, clears it.
The metrics of the last completed run are no longer lost depending on file order.
The agent collects the files of the <<<job>>> section with find, which does
not sort them. If the <job>.<pid>running file of a running instance happened to
come before the file of the last completed run, every metric of that run was
silently dropped and the service reported nothing but the exit code and the job
age.
Jobs that have not completed yet are OK.
A job that is currently running but has never completed has no exit code, so the
service went to UNKNOWN with Got incomplete information for this job. It now
reports OK together with the start time and the age of the running job. Job
data that is incomplete in other ways - a missing exit code for a job that is not
running, for example - still goes to UNKNOWN.
An exit code of 0 is only OK if the configured mapping says so.
Contrary to its inline help, Explicit mapping of job exit codes to states did
not make an unlisted exit code 0 result in CRIT: 0 was hardwired to OK on top of
whatever the rule said. The mapping now decides on its own. This only affects
hosts with that rule configured - if your rule does not list exit code 0 and
you want jobs that succeed to stay OK, add an entry mapping 0 to OK.
Without the rule nothing changes: 0 is OK and anything else is CRIT, as
before.
The details say which information is missing.
Got incomplete information for this job was reported for three different things, each of them something else having gone wrong on the monitored host:
- no file of a completed run at all,
- one without an exit code
- and one without a start time.
The summary is unchanged, but the details now name what is missing and the most likely reason for it.
The outcome of a run is reported even if its start time is missing.
Werk #22105 made a completed run without a readable start time report UNKNOWN
and nothing else, even though the exit code and the metrics of that run were
there to be read - so on a host without perl every failing job showed up as
UNKNOWN rather than CRIT. Such a run now reports its exit code and its
metrics as usual; only the job age is missing, which still keeps a successful run
at UNKNOWN.