For wisdom regarding the ProcD in general, see ProcdWisdom.
-*Update* The osg procd fork was merged into mainline Condor for Condor 7.5.6.
+*Update* The osg procd fork was merged into mainline HTCondor for HTCondor 7.5.6.
{section: Introduction}
-The OSG ProcD is a forked version of the ProcD used in Condor. (Ideally, of course, we'd only have a single ProcD; See #111). The OSG ProcD is made available as part of the VDT, and is currently used by a GLExec plugin authored by {wiki: IgorSfiligoi Igor Sfiligoi} that is used to improve accounting in OSG in the presence of pilot jobs. The paper {link: http://www.cs.wisc.edu/condor/doc/grid-08-pilot-accounting.pdf here} describes this work in detail. The last
+The OSG ProcD is a forked version of the ProcD used in HTCondor. (Ideally, of course, we'd only have a single ProcD; See #111). The OSG ProcD is made available as part of the VDT, and is currently used by a GLExec plugin authored by {wiki: IgorSfiligoi Igor Sfiligoi} that is used to improve accounting in OSG in the presence of pilot jobs. The paper {link: http://www.cs.wisc.edu/condor/doc/grid-08-pilot-accounting.pdf here} describes this work in detail. The last
release of the software was {link: http://vdt.cs.wisc.edu/software/procd/0.3 here}.
{section: Differences from the Mainline ProcD}
-The OSG ProcD does not differ much from what we ship with Condor. There are really only two things:
+The OSG ProcD does not differ much from what we ship with HTCondor. There are really only two things:
-First, the OSG ProcD uses Condor's configuration subsystem and dprintf logging. It would be really nice to have this in the mainline ProcD as well. (See #110).
+First, the OSG ProcD uses HTCondor's configuration subsystem and dprintf logging. It would be really nice to have this in the mainline ProcD as well. (See #110).
-Second, the way GID-based process tracking works is different. In mainline Condor, the ProcD takes care of maintaining a pool of GIDs and allocating them as needed. When a Condor daemon asks for GID-based tracking, the ProcD allocates a free GID from its pool and returns it to the daemon, which then inserts this GID into the supplementary group list of its child process. In the OSG ProcD, a tool called gidd_alloc is used to probe the system for a free GID within a specified range. This GID can then be inserted into a process's group list then given to the ProcD to use for GID-based tracking.
+Second, the way GID-based process tracking works is different. In mainline HTCondor, the ProcD takes care of maintaining a pool of GIDs and allocating them as needed. When a HTCondor daemon asks for GID-based tracking, the ProcD allocates a free GID from its pool and returns it to the daemon, which then inserts this GID into the supplementary group list of its child process. In the OSG ProcD, a tool called gidd_alloc is used to probe the system for a free GID within a specified range. This GID can then be inserted into a process's group list then given to the ProcD to use for GID-based tracking.
Note that the gidd_alloc tool is built from gidd_alloc.c in the condor_gidd directory of V7_1-procd_osg-branch. There's a bunch of other code in there too, but none of it made it to prime time and it can be ignored.
