DOCS : WRAPPER JOBS

Wrapper jobs

justIN's wrapper jobs are extensions of the jobsub/glideInWMS jobs developed at Fermilab and inherit their properties. There is a one to one mapping between an instance of a wrapper job in justIN and the corresponding HTCondor job. Consequently justIN uses jobsub style string IDs when referring to jobs in log files, the Dashboard, environment variables exposed to user scripts etc, and these take the form NNNNNN.N@host.name where N are integers.

Within justIN, a wrapper job is in one of several allocation states given here:

• submitted - the job has been submitted by the justIN Job Factory but not yet allocated a workflow/stage
• started - the job has succesfully been allocated a stage within a workflow to work on by the allocator service and the supplied jobscript should be running
• processing - the jobscript has successfully been allocated at least one input file to process by the allocator service.
• outputting - the jobscript has finished and the wrapper job has reported to the allocator service the list of input files it processed and the names of the output files it intends to register with MetaCat and Rucio and to upload
• finished - the wrapper job has successfully registered and uploaded the output files and confirmed this to the allocator service.
• notused - the wrapper job was unable to find a suitable workflow/stage to work on and exited.
• aborted - the wrapper job failed in some way and reported this to the allocator service.
• stalled - the Finder agent has identified that the job stopped sending regular heartbeats and has marked it as stalled. This may be because the job was killed by a local batch system for exceeding limits on memory usage etc.