Check mk-job result access for both the job user and monitoring agent

Bottom line: Prepare the per-user result directory and independent agent read access before treating an undiscovered mk-job service as a failed scheduled task.

Source fact: what the authority says

The Checkmk job-monitoring guide places mk-job before the real command to record measurements including the last execution and reported job success. The wrapper’s service name must be unique on that host, and service discovery can find it after the job has run and saved its result. For an unprivileged job user, the guide first creates a per-user directory beneath the job-result directory and assigns that user ownership. Its diagnostics inspect retrieved agent output with cmk -d; missing results can reflect an agent user that lacks permission to read the job files.

What the source does not establish

This article checks job-result collection rather than proving the job’s business outcome. It does not approve world-readable result files, assume the agent runs as root or turn a recorded exit result into evidence of a usable backup.

Applicability questions

• Which user actually executes the scheduled job?
• What unique service name and result directory belong to that job?
• Which identity reads the results for the monitoring agent?
• Has an approved execution produced a result that can be traced through the full collection path?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends an identity-and-path record before editing the schedule. Put the job account, wrapper location, service name and intended result directory beside the actual agent reader. Keep a failed job, a missing writer directory and an unreadable result as separate hypotheses rather than changing the task until a service appears.

Prepare the per-user directory through the host’s approved permissions procedure. Have the owner review its exact path and ownership before an unprivileged trial. Keep the agent’s required read access separate from the writer’s access, and review a suitable narrow group or permission arrangement instead of copying a broad read mode without assessment.

Use a harmless representative job with a distinct service name for the first exercise. Arrange an approved execution and preserve its actual result file before beginning service discovery. Avoid substituting a root-run interactive success for evidence of the scheduled user’s normal path.

Follow the data from the result file into the retrieved agent response and then the service configuration. Preserve the first missing checkpoint for investigation. Keep business validation with the job owner: an observed wrapper result and a discovered monitoring service should not silently close the job’s separate backup, export or maintenance acceptance requirement.

Verification and evidence

Proposed verification: run the harmless job through the intended scheduling context and inspect the named per-user result path. Compare file ownership and the actual agent reader’s permitted access with the plan. Retain missing or denied observations without repeatedly launching valuable production work to obtain a sample.

Inspect the retrieved agent response and perform the approved discovery step only after its required data exists. Compare the service identity with the selected unique name. Use a separate authorized read-denial fixture if needed, then restore the reviewed permissions. Keep wrapper evidence and actual business-outcome evidence distinctly labeled.

Official references

• Checkmk — Monitoring time-based processes (cronjobs) — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.