Condor provides a number of other important features to its users. Code does not have to be modified in any way to take advantage of these benefits, though it must be linked with the Condor libraries. Once re-linked, jobs gain two crucial abilities: they can checkpoint and perform remote system calls. These jobs are called "standard" Condor jobs. Condor also provides a mechanism to run binaries that have not been re-linked, which are called "vanilla" jobs. Vanilla jobs do not gain any of these benefits, but they are still scheduled by Condor to run on idle machines. However, since vanilla jobs do not support remote system calls, the mechanism by which Condor overcomes distributed ownership, they must operate in an environment of a shared filesystem and common UID space.
-{subection: What is Checkpointing?}
+{subsection: What is Checkpointing?}
Simply put, checkpointing involves saving all the work a job has done up until a given point. Normally, when performing long-running computations, if a machine crashes, or must be rebooted for an administrative task, all the work that has been done is lost. The job must be restarted from scratch which can mean days, weeks, or even months of computation wasted. With checkpointing, Condor ensures that positive progress is always made on jobs, and that you only loose the computation that has been performed since the last checkpoint. Condor can be configured to periodically checkpoint, you can issue a command to asynchronously checkpoint a job on any given machine, or you can even call a function within your code to perform a checkpoint as it runs. Checkpointing also happens whenever a job is moved from one machine to another, which is known as "process migration". (See footnote 2).
