On Wed, Nov 21, 2007 at 09:58:49AM -0800, Bryan Cantrill wrote: > > We wanted to develop a dtrace script that would capture the raw data > > that would be used to modify the internal database just before it was > > actually used to update the database. I have written this script, and > > it does dump out the record. However, it turns out that the database > > can be modified by three different methods, and each of these can be run > > many times under different pid numbers of course. The three methods are > > kadmin, kadmin.local and kpasswd. > > Thanks for the use case! One thing to investigate: add an SDT probe in > the common library where the database is modified. Especially with > is-enabled probes, you can construct this such that it provides rich > arguments (e.g., the nature of the query or transaction) -- and then the > ability to dynamically instrument all processes that make the call just > falls out. > > And to be honest, it's such a nasty problem to allow instrumentation of > arbitrary functions across arbitrarily many (and arbitrarily dynamic) > processes that we're unlikely to solve it (at least in the near future) -- > especially with SDT probes providing such a reasonable solution...
I've wanted that myself, but it does seem like a difficult problem! One way to deal with this particular use case might be to use the syscall provider to catch opens for write of that DB, stop caller and start a new instance of dtrace (via system()) that traces the stopped process and pruns it. I've done this sort of thing before and it works OK. It slows down the DB open operation a lot (since system() involves fork/execing), and it requires destructive actions, but it's livable. Nico -- _______________________________________________ dtrace-discuss mailing list [email protected]
