DTrace script to trace processes entering vfs::vop_remove

[Mark Johnston]

On Wed, Dec 03, 2014 at 03:19:31PM -0800, dteske at FreeBSD.org wrote:
> Hi markj, list,
> 
> I wrote a script for $work to help me find out "who on Earth
> keeps deleting files XYZ?" from a particular storage server.
> 
> Please find attached a copy of watch_vop_remove.d which
> has the following sample output:
> 
> 2014 Dec  3 11:58:52 rm[75596]: /tmp/foo
>  -+= 72846 0.0 -bash
>   \-+= 75589 0.0 /bin/bash /usr/home/support/bash_script
>     \-+= 75596 0.0 rm -f /tmp/foo
> 
> The above sample output was displayed when executing the following shell
> script:
> 
> #!/bin/bash
> touch /tmp/foo
> rm -f /tmp/foo
> 
> The output format displayed for each vop_remove() call is as follows:
> 
> DATE process[PID]: PATH_TO_DELETE
>  -+= GPID UID.GID grandparent_process [arguments (up to 3)]
>   \-+= PPID UID.GID parent_process [arguments (up to 3)]
>     \-+= PID UID.GID process [arguments (up to 3)]

This is neat. I just had a few comments:
- You can use walltimestamp when printing the date and time, instead of
  timestamp + blah.
- It's possible to get the full argv of the current process with
  curpsinfo->pr_psargs. It can be done for other processes too; see
  /usr/lib/dtrace/psinfo.d. (This might not be true depending on the
  FreeBSD version you're on.)
- Running this script with a make -j4 buildkernel causes dtrace to run
  out of dynamic variable space.

I'd really really like to fix name resolution so that we don't have to
jump through so many hoops to write scripts like this, though. One
approach is to do what Solaris does, which is keep a cached path in the
vnode itself (v_path).

> 
> NB: Requires "kldload dtraceall" to be performed prior to execution

(libdtrace automatically kldloads dtraceall on head and stable/10.)