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. +When the ProcD starts up, it looks up its parent PID and begins monitoring that process and any child processes. Child processes are discovered by polling the system. The interval at which the ProcD polls the system can be specified via the the command line (actually this is the maximum interval; see below about registering subfamilies). -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. +For a family that the ProcD is monitoring, clients can request the following actions: + +*: Get resource usage totals for the processes in the family +*: Send a signal to the family's "root" process +*: Suspend / continue all the family's processes +*: Kill all the family's processes + +The ProcD supports nested families (or subfamilies). For example, the Master may start a ProcD which then begins monitoring the Master's family. When the Master starts a daemon like the StartD, it will want to be able to act on the StartD and all it's children in the ways listed above. So it registers a subfamily with the ProcD. The StartD will similarly register a nested family when it spawns the Starter, as will the Starter when it spawns the job. + +After registering a new subfamily, a client of the ProcD can tell the ProcD what "tracking methods" it should use in discovering what processes belong to the family. Methods include things like using environment variables, UIDs, or GIDs. Without specifying any additional methods, only PPIDs will be used. + +There are some important consequences of the ProcD's PrivSep heritage. 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.
