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

Let's consider the scenario of Multi User Pilot Jobs (MUPJs). Before the existence of the LCMAPS Tracking GroupID plugin gLExec would perform the setuid, setgid and the setgroups system calls to change the ownership of a process from the Pilot Job user to the Payload user during a job execution on a batch system. As gLExec is looking at the LCMAPS configuration to