Overview

Flight checks, AKA preflights and postflights, new in Qube 6.6, are programs and/or scripts that are run on the worker just before and after the actual job or agenda starts.

The exit codes of flight checks determine the processing and exit status of their respective job instances or agendas.  

System-wide vs Job-specific

System-wide flight checks are installed by the site administrator into predefined locations on the worker systems, and are run for every job. By default, system-wide flight checks are installed in one of four subdirectories under $QBDIR/flightCheck on the worker. More precisely:

...

The postflight checks are still run if an instance or agenda-item fails.

Instance-level vs Agenda-level flight checks and the effect of their exit codes

Instance-level preflights and postflights are run on the worker just before and after job instances are processed, respectively. Similarly, agenda-level preflights and postflights are run just before and after agendas are processed, respectively.

...

• If an instance-level preflight exits non-zero, any additional preflights for the job instance are skipped, the execution of the job instance is canceled, and the job instance is reported to the supervisor as "failed".
• If an agenda-level preflight program exits non-zero, any addtional preflights for the agenda are skipped, the agenda will be unprocessed, and reported as "failed". The job instance will move onto processing the next agenda.
• If an instance-level postflight exits non-zero, any additional postflights for the job instance are skipped, and the job instance is reported to be "failed".
• If an agenda-level postflight exits non-zero, any additional postflights for the agenda are skipped, and the agenda is reported as "failed". The job instance will move onto processing the next agenda.

Qube-specific environment variables set in the flightCheck environments

Variables in both instance-level and agenda-level flightChecks:

• QBDIR
• QBJOBID
• QBPGRPID
• QBSUBID
• QB_ALLOCATIONS (a reservation-style string, e.g, 'host.processors=1')
• QB_DIR
• QB_DOMAIN
• QB_FRAME_PADDING
• QB_JOBSLOTS (how many job slots got allocated, can vary when using the "host.processors=N+" reservation)
• QB_SUPERVISOR

Additional variables in agenda-level flightChecks:

• QB_FRAME_END
• QB_FRAME_NUMBER
• QB_FRAME_PADDING
• QB_FRAME_RANGE
• QB_FRAME_START
• QB_FRAME_STEP
• QB_PADDED_FRAME_END
• QB_PADDED_FRAME_NUMBER
• QB_PADDED_FRAME_START
• QB_PADDED_FRAME_STEP

Addtional variables in postFlight checks

• QB_INSTANCE_STATUS
• QB_FRAME_STATUS
• QB_SYSTEM_EXIT_CODE (only set by cmdline and cmdrange jobs)

In postflight scripts, access the status of the last-processed frame or instance via the QB_FRAME_STATUS and QB_INSTANCE_STATUS environment variables, respectively. These will be set to strings such as "complete" and "failed".

Tips 

When writing postflight scripts for cmdline and cmdrange jobs, you can query the environment variable QB_SYSTEM_EXIT_CODE to find out the numerical exit code of the last command that was run.

Also, in postflight scripts, access the status of the last-processed frame or instance via the QB_FRAME_STATUS and QB_INSTANCE_STATUS environment variables, respectively. These will be set to strings such as "complete" and "failed".