MaxJobRetirementTime = 24*3600
{endcode}
-{subsection: Accounting}
+{subsection: Accounting and Monitoring}
The above policies rely on job suspension. Should the jobs be "charged" for the time they spend in a suspended state? This affects the user's fair-share priority and the accumulated number of hours reported by condor_userprio. As of Condor 7.4, the default behavior is to charge the jobs for time they spend in a suspended state. There is a configuration variable, NEGOTIATOR_DISCOUNT_SUSPENDED_RESOURCES that can be used to get the opposite behavior.
@@ -132,6 +132,7 @@
When looking at condor_status, the extra slot representing the whole machine is visible. Notice that it appears in the Owner state, because the start expression we have configured is false unless presented with a whole-machine job. We could modify the IS_OWNER expression to make the slot appear as Unclaimed rather than Owner, but we find that Owner is a nice reminder that this slot is special and is not available to run "normal" jobs.
{verbatim}
+$ condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime
slot1@execute.node LINUX X86_64 Unclaimed Idle 0.750 2006 0+00:00:04
@@ -154,6 +155,9 @@
When the whole-machine slot is claimed, the other slots will appear in the Owner state, because they are configured to not start any new jobs while the whole-machine slot is claimed. Again, we could make them appear as Unclaimed by changing the IS_OWNER expression, but the Owner state serves as a useful reminder that these slots are reserved during this time.
{verbatim}
+$ condor_status
+Name OpSys Arch State Activity LoadAv Mem ActvtyTime
+
slot1@execute.node LINUX X86_64 Owner Idle 0.870 2006 0+00:00:04
slot2@execute.node LINUX X86_64 Owner Idle 0.000 2006 0+00:00:05
slot3@execute.node LINUX X86_64 Owner Idle 0.000 2006 0+00:00:06
@@ -164,3 +168,5 @@
slot8@execute.node LINUX X86_64 Owner Idle 0.000 2006 0+00:00:03
slot9@execute.node LINUX X86_64 Claimed Busy 0.000 16054 0+00:00:04
{endverbatim}
+
+Since the whole-machine policy depends on STARTD_SLOT_EXPRS, it can take a few iterations of =ClassAd= updates for the state of the slots to converge. For this reason, the information visible in condor_status may lag behind the true state of the slots when conditions have recently changed. It is therefore useful to use the -direct option to condor_status when verifying that the whole-machine policy is correctly working.
