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.) The fix
shown below takes care of this bug, but it means that the target
process will also be killed on a good exit from dtrace. (For example,
dtrace -n ''fbt::dnlc_dir_lookup:entry/pid
=$target/{stack();exit(0);}'' -c "ls -l/foo/bar".)
Anyone willing to give some guidance?
Thanks,
Chad
--- a/usr/src/lib/libdtrace/common/dt_proc.c Tue Oct 21 12:07:10 2008 -0700
+++ b/usr/src/lib/libdtrace/common/dt_proc.c Fri Mar 20 12:26:43 2009 -0400
@@ -712,9 +710,12 @@
if (!(Pstatus(dpr->dpr_proc)->pr_flags & (PR_KLC | PR_RLC))) {
dt_dprintf("abandoning pid %d\n",
(int)dpr->dpr_pid);
rflag = PRELEASE_HANG;
+ } else if (Pstatus(dpr->dpr_proc)->pr_flags & PR_KLC) {
+ dt_dprintf("killing pid %d\n", (int)dpr->dpr_pid);
+ rflag = PRELEASE_KILL; /* apply kill-on-last-close */
} else {
dt_dprintf("releasing pid %d\n",
(int)dpr->dpr_pid);
- rflag = 0; /* apply kill or run-on-last-close */
+ rflag = 0; /* apply run-on-last-close */
}
if (dpr->dpr_tid) {
> 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? 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. ;-) It seems like it would be a better fix to not start the "-c" program until the D script compiles cleanly. Is that possible? Chip
On Fri, Mar 20, 2009 at 2:35 PM, Chip Bennett <cbennett at laurustech.com> 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
> > 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".The process should be killed: this is a (dumb) bug in my code. If something is attached to by a debugger, the default behavior should be to release it and set it running again. If something is created by the debugger, the default behavior should be to kill it if the debugger exits. This is how all p-tools, truss, mdb, etc. all behave. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/