MaxJobRetirementTime = 24*3600
{endcode}
+{subsection: Suspension at Startup}
+
+In the first example policy above, the whole-machine job is suspended while single-core jobs finish running. This suspension happens within POLLING_INTERVAL (default 5) seconds of the job start. For many applications, being suspended a few seconds after startup and then resuming later is not a problem. However, this may be problematic for some applications: for example, a job that is intended to measure how much real time an algorithm takes to run.
+
+One solution to this problem is to have the job sleep for at least POLLING_INTERVAL seconds before doing anything that should not be interrupted. Rather than requiring the job to be modified, the administrator can use USER_JOB_WRAPPER to do the sleeping before the job starts.
+
+The file =whole_machine_job_wrapper= could then be created with the following contents. Adjust the setting of condor_history and sleep_time at the top of the script to be appropriate for your situation. Be sure to add execute and read permission to this file for all users. If you already have a USER_JOB_WRAPPER, you will need to merge together this new script with the existing one.
+
+{code}
+#!/bin/sh
+
+# Set this to the full path to condor_history:
+condor_history=condor_history
+
+# Set this to something greater than POLLING_INTERVAL (default 5)
+sleep_time=10
+
+if ! [ -x "${condor_history}" ]; then
+ echo "USER_JOB_WRAPPER has incorrect path to condor_history" 2>&1
+ exit 1
+fi
+
+if ! [ -f "${_CONDOR_MACHINE_AD}" ]; then
+ echo "USER_JOB_WRAPPER cannot fine machine ad" 2>&1
+ exit 1
+fi
+
+is_whole_machine_slot=`"${condor_history}" -f "${_CONDOR_MACHINE_AD}" -format "%d\n" CAN_RUN_WHOLE_MACHINE`
+
+if [ "${is_whole_machine_slot}" = "1" ]; then
+ # Sleep for at least POLLING_INTERVAL seconds (default 5) before
+ # starting whole-machine jobs so that if we are going to get
+ # suspended while the machine drains, we suspend here before
+ # starting the actual job.
+ sleep $sleep_time
+fi
+
+exec "$@"
+{endcode}
+
+The configuration then needs to be modified to point to the full path of the job wrapper script.
+
+{code}
+USER_JOB_WRAPPER = /path/to/whole_machine_job_wrapper
+{endcode}
+
{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.
