By user12618589 on May 06, 2008
"It looks like Dirtracer is bound to one process id (pid) in the config file, but what if the server is restarted, does it know the new pid number dynamically"?
Currently, no. Dirtracer was built to trace one pid at a time and must be changed in the dirtracer.config file before running.
I thought more on this and came to the conclusion it is possible in a future version of Dirtracer. If you have a dirtracer.config or dirtracer.config.last (the config from the last run dirtracer capture) but the process id has changed, I could back track using the pid file located in the <slapd instance name>/logs location to use the current pid.
This would be based on the dirtracer.config file parameter INSTANCENAME.
If the INSTANCENAME parameter was not set (would be in a dirtracer.config.last or dirtracer.config.x) then I would have to abort the run.
While possible, it would however have limitations (gotchyas) that could prevent data capture. If the directory server was hung/deadlocked and an old dirtracer.config file was using with BORKED="0" (Not Hung) then when launched, Dirtracer would attempt an ldapsearch and itself hang waiting on the search return.
Note: because Dirtracer is a shell script and relies on ldapsearch as opposed to an internal search mechanism it is limited to the ldapsearch capabilities therefor does not have an option (currently) to timeout a connection. I have been thinking recently of using my timer function for this issue.
This dynamic pid check would mostly be useful for a couple scenarios I can think of.
1) Dirtracer run's to gather historical/config info using a cron without having to check/recheck the running pid vs config file setting (in the event the ds was restarted).
2) To set up Problem Type config files in advance without the current ns-slapd process's pid number embedded in the config file. In this case the admin could just run ./dirtracer -f ./dirtracer.config.hang with very short notice and capture data quicker than having to edit the config file and change the pid parameter.
I will think this idea over some more but it has merit so it could make its way into the next release.