public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug runtime/13017] New: process().attach/detach probe
@ 2011-07-22  9:10 mjw at redhat dot com
  2011-07-22 14:26 ` [Bug runtime/13017] " dsmith at redhat dot com
  2011-07-22 14:34 ` mjw at redhat dot com
  0 siblings, 2 replies; 3+ messages in thread
From: mjw at redhat dot com @ 2011-07-22  9:10 UTC (permalink / raw)
  To: systemtap

http://sourceware.org/bugzilla/show_bug.cgi?id=13017

           Summary: process().attach/detach probe
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap@sourceware.org
        ReportedBy: mjw@redhat.com


Sometimes it is useful to be able to see which processes staps vma tracker will
be monitoring. Just so you know whether or not you can expect any other probe
triggers.

The use case would be with processes that are mostly idle. So you might run a
script like:

probe process("lazy_daemon").function("*") { printf("%d: %s\n", pid(), pp()) }

But now you don't get any feedback if the lazy_daemon is just sleeping.

So you would like to add something like:

probe process("lazy_daemon").attach { printf("monitoring %d\n", pid()) }
probe process("lazy_daemon").detach { printf("%d is gone\n", pid()) }

These should just trigger when the stap runtime vma tracker
registers/deregisters a process.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug runtime/13017] process().attach/detach probe
  2011-07-22  9:10 [Bug runtime/13017] New: process().attach/detach probe mjw at redhat dot com
@ 2011-07-22 14:26 ` dsmith at redhat dot com
  2011-07-22 14:34 ` mjw at redhat dot com
  1 sibling, 0 replies; 3+ messages in thread
From: dsmith at redhat dot com @ 2011-07-22 14:26 UTC (permalink / raw)
  To: systemtap

http://sourceware.org/bugzilla/show_bug.cgi?id=13017

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #1 from David Smith <dsmith at redhat dot com> 2011-07-22 14:25:44 UTC ---
(In reply to comment #0)
> Sometimes it is useful to be able to see which processes staps vma tracker will
> be monitoring. Just so you know whether or not you can expect any other probe
> triggers.
> 
> The use case would be with processes that are mostly idle. So you might run a
> script like:
> 
> probe process("lazy_daemon").function("*") { printf("%d: %s\n", pid(), pp()) }
> 
> But now you don't get any feedback if the lazy_daemon is just sleeping.
> 
> So you would like to add something like:
> 
> probe process("lazy_daemon").attach { printf("monitoring %d\n", pid()) }
> probe process("lazy_daemon").detach { printf("%d is gone\n", pid()) }
> 
> These should just trigger when the stap runtime vma tracker
> registers/deregisters a process.

The process("lazy_daemon").{begin,end} probes fire at 2 times:

1) When lazy_daemon starts/ends.
2) If lazy_daemon is running (or sleeping) when the systemtap script starts,
the begin probe will fire the next time lazy_daemon stops (job control, syscall
entry/exit, etc.).

If you look in __stp_utrace_task_finder_target_quiesce(), you'll see the
following:

        /* Call the callbacks.  Assume that if the thread is a                  
         * thread group leader, it is a process. */                             
        __stp_call_callbacks(tgt, tsk, 1, (tsk->pid == tsk->tgid));             

        /* If this is just a thread other than the thread group leader,         
           don't bother inform map callback clients about its memory map,       
           since they will simply duplicate each other. */                      
        if (tgt->mmap_events == 1 && tsk->tgid == tsk->pid) {                   
                __stp_call_mmap_callbacks_for_task(tgt, tsk);                   
        }                                                                       

That 1st function calls any begin probes.  The 2nd calls the vma tracer stuff.

Does .begin not already do what you want?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug runtime/13017] process().attach/detach probe
  2011-07-22  9:10 [Bug runtime/13017] New: process().attach/detach probe mjw at redhat dot com
  2011-07-22 14:26 ` [Bug runtime/13017] " dsmith at redhat dot com
@ 2011-07-22 14:34 ` mjw at redhat dot com
  1 sibling, 0 replies; 3+ messages in thread
From: mjw at redhat dot com @ 2011-07-22 14:34 UTC (permalink / raw)
  To: systemtap

http://sourceware.org/bugzilla/show_bug.cgi?id=13017

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Mark Wielaard <mjw at redhat dot com> 2011-07-22 14:34:02 UTC ---
(In reply to comment #1)
> Does .begin not already do what you want?

It does exactly what I wanted. Thanks!

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-07-22 14:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-22  9:10 [Bug runtime/13017] New: process().attach/detach probe mjw at redhat dot com
2011-07-22 14:26 ` [Bug runtime/13017] " dsmith at redhat dot com
2011-07-22 14:34 ` mjw at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).