Project

General

Profile

Actions

Bug #2185

closed

Job Scheduler PT: for jobs that take less than 5 minutes, there can be a gap in the reporting

Added by Jonathan CLARKE almost 13 years ago. Updated almost 13 years ago.

Status:
Released
Priority:
2
Assignee:
Jonathan CLARKE
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

When we run a job via the Job Scheduler PT, it is put into the background. When it finished, it's result classes are set for 24 hours exactly.

However, reporting on these classes only happens on the next CFEngine run, ie 5 minutes later. This is fine the first time, but after several executions, there is a run when the command is launched again, but the result classes have already expired.

We need to make these classes last just a little bit longer!


Related issues 1 (0 open1 closed)

Related to Rudder - User story #2184: jobManagement PT : Create a PT that enables a user to select a time interval during which a command should be runReleasedMatthieu CERDA2012-01-20Actions
Actions #1

Updated by Jonathan CLARKE almost 13 years ago

OK, actually I misinterpreted this by not reading the dates (doh). It turns out that the gap was not 5 minutes, but 1 day and 5 minutes!

This is because CFEngine does not currently re-set persistent classes... ie, if a "job_success" class is set at 22:30 one day, for 24 hours, then it is set again at 22:29 the next day, CFEngine will say "job_success" is already set, and just ignore the request to set it again.

According to the documentation of 'timer_policy' (see http://cfengine.com/manuals/cf3-reference.html#classes-in-_002a and search for the next occurence of timer_policy), using timer_policy => "reset" (the default) should make this class be set for 24 hours from each time we ask it to be set.

Actions #2

Updated by Jonathan CLARKE almost 13 years ago

I've patched and reported this bug to CFEngine: https://cfengine.com/bugtracker/view.php?id=923

I'll be including the fix in our packages.

Actions #3

Updated by Jonathan CLARKE almost 13 years ago

  • Status changed from In progress to Pending technical review
  • % Done changed from 0 to 100

Applied in changeset commit:4a39d441a3f30c733eb94ec117f93d6ea8b6c295.

Actions #4

Updated by Jonathan CLARKE almost 13 years ago

Applied in changeset commit:2276c6930b01155b78a4ac48bf096fd1a795c816.

Actions #5

Updated by Matthieu CERDA almost 13 years ago

Well I do not have the complete C source file to try to understand the patch but it looks syntaxically correct, compiles and outputs reports like expected. So all good !

Actions #6

Updated by Jonathan CLARKE almost 13 years ago

  • Status changed from Pending technical review to Released
Actions

Also available in: Atom PDF