On Fri, Mar 20, 2009 at 2:35 PM, Chip Bennett <[email protected]> wrote: >> What should the behavior of 'dtrace -c' be when dtrace(1M) exits >> before the target command? Should the target process be killed, or >> should the target process continue running? >> >> Currently, the target process keeps running, but this also happens in >> the case when dtrace(1M) exits with an error (see >> http://bugs.opensolaris.org/view_bug.do?bug_id=6712247.) ... > > IMHO, I think it should work just like it does now. I don't want the D > program that is monitoring my process to have that kind of control, > unless I specifically tell it to do so. What if I'm only interested in > monitoring the first part of the execution?
Note that this only applies to commands that have been spawned by dtrace(1M) via -c, not existing processes that we've attached to with -p. The kill-on-last-close flag would apply for -c, and the release-on-last-close flag would apply for -p. BTW, for a good demonstration of how annoying this bug can be, run "dtrace -n jarod -c prstat". > > Also, even if my D program exits with an error, I'm still not sure I > want it killing my process. What if my application had already started > doing something that was part of a bigger transaction that needed to > complete in order to not leave a file in a precarious state. I realize > the odds are against that, but the idea just bothers me on principle. > ;-) The best answer I can come up with for this is, if the application is that crucial, don't run it under dtrace. :-) The only good analogy I have here is with truss(1) and ptime(1). If you run a command under either of these and hit ctrl-C, the signal is passed along to kill the command. This isn't the best analogy, given that a ctrl-C is a pretty clear indication that you want to kill things. OTOH, explicitly using exit() inside a D script is similarly clear. > > It seems like it would be a better fix to not start the "-c" program > until the D script compiles cleanly. Is that possible? Not really. Consider the case of, "dtrace -n 'pid$target::foo:entry' -c bar" when bar doesn't have a foo(). You need to do the fork and exec so that you can instrument the process, and it's really only then that you determine that the probe point doesn't exist. (In this case, you could replicate the work performed by the runtime linker in order to determine that, but that would be a lot of work for little gain.) Chad _______________________________________________ dtrace-discuss mailing list [email protected]
