Page History
This page will serve as my brain dump of all things ProcD. My goal is to highlight things that aren't obvious from looking at the code. In addition, I'm neither dying nor moving farther than 0.2 miles from the Condor project's home in the CS building so please feel free to let me know if something is glaringly missing from this page.
The ProcD was born out of the PrivSep project. The idea was that while most root-enabled things could be accomplished with a stateless root-owned setuid binary (the condor_root_switchboard), our process family tracking code needed a root-running daemon. In hindsight, I think this may have been a mistake (see ticket #110). Even without the ProcD's supposed benefit for PrivSep it is still a big win for scalability, particularly as we move toward more and more cores. Previously, Condor was executing the process tracking code in each Starter in addition to in the StartD and Master. In addition, the ProcD has some other performance advantages over the older process tracking code, like using a hash table when snapshotting to "remember" whether processes that have been seen before as in families we are interested in or not.
There are a couple important consequences of the ProcD's PrivSep heritage. First, the fact that the ProcD is included in the "trusted" portion of the PrivSep architecture inspired us to make it include as little code as possible. As such, it does not use dprintf logging, doesn't use Condor's configuration subsystem, and doesn't (currently) use some handy features like the Google cored dumper. Logging is handled in a very basic way and is missing crucial features that dprintf has like rotation. As a result, the ProcD's log file is disabled by default. Configuration is handled via the command line. A Condor daemon starting the ProcD will read its configuration parameters out of the Condor config file then place those on the ProcD's command line.
Another consequence of the ProcD's PrivSep heritage is that it is the ProcD's responsibility (in PrivSep mode) to ensure that the Condor's daemons are not asking it to act on processes that Condor should not be allowed to act on. The result is that whenever a Condor daemon asks the ProcD to register a new process family the ProcD first makes sure that the given "root" process is already considered part one of the families that the ProcD is monitoring. Of course, this responsibility is no longer important if ticket #110 is resolved.