LCMAPS Tracking GroupID plugin

Tracking Group IDs are added to batch jobs to be able to track them regardless if they escape the process tree.

Batch systems that use this feature are:

• Sun Grid Engine (SGE, now known as the Oracle Grid Engine)
• Condor-C batch system

Other batch systems are known to have the feature, but it doesn't seem to be used in (known) Grid deployments:

• LSF
• Torque/PBS

What's a Tracking Group ID?

A tracking Group ID is a group ID issued by the batch system and attached to the first process that is the batch job of a user. When a process spwans a child process, then the set of secondary GroupIDs is also inherited by the process image copy of the fork() system call. All stray processes can be rounded up by the secondary Group ID that each of the user's process own.

Process tree example

Here is an example process tree on a PBS/Torque based cluster Worker Node. For illustration purposes all non-relative processes are removed from the tree:

init-+
     ├─pbs_mom
     │   ├─bash
     │   │   └─1337.stro.n /var/spool/pbs/mom_priv/jobs/1337.stro.nikhef.nl.SC
     │   │       └─jobwrapper /opt/lcg/libexec/jobwrapper ./CREAM31337_jobWrapper.sh
     │   │           └─CREAM31337_ -l ./CREAM31337_jobWrapper.sh
     │   │               └─glexec /bin/bash payload.sh
     │   │                   ├─payload.sh

gLExec's involvement

The problem is that gLExec ignores the tracking Group ID issued by the batch system. gLExec will use LCMAPS to decide to which Unix account the payload needs to be mapped. The Tracking Group ID plug-in will make LCMAPS aware of the tracking Group IDs and preserve them when LCMAPS is building the Unix account mapping resolution.