dtrace discuss - Aug 2005 - How to get absolute path?

Is there a simple way to get the absolute path. For example,
I want to monitor opens on a particular file. 

Something like,

 dtrace -n
syscall::open*:entry''/copyinstr(arg0)=="/etc/passwd"/{trace(execname)}''

This will work for cat /etc/passwd but fails for cd /etc; cat passwd.

I understand ''cwd'' but no idea how I''d check if the
patch is relative or absolute.
Is there any subroutines? Where in the kernel is this mapping done? Can I
have a probe in that routine and check for full path?

Also is there an easy way to look for open of any files in a directory. For 
example I''d like to know when there is a open done in any file under
/etc?

Thanks,

Angelo
This message posted from opensolaris.org

> Is there a simple way to get the absolute path. For example,
> I want to monitor opens on a particular file. 
> ...
You can use the new fds[] array, now available in Solaris Express or
OpenSolaris, to do this.  For example:

# dtrace -s /dev/stdin
syscall::open:return
/arg1 != -1/
{
        printf("%s opened %s as %d\n", execname,
fds[arg1].fi_pathname, arg1);
}

This new feature is described in further detail here:

http://blogs.sun.com/roller/page/mws?entry=dtrace_inlines_translators_and_file

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

The following is a code segment that did this.  I have never used it but I 
assume it works.

Regards,

Keith

syscall::creat:return,
syscall::open:return,
syscall::open64:return
     / self->filename == filename
       && errno == 0
     /
{
     /*
      * arg0 is the file descripter
      * fill the fds[pid, fd] with the full path
      */

     fds[pid,arg0] = 
stringof(curthread->t_procp->p_user.u_finfo.fi_list[arg0].uf_file->f_vnode->v_path);
}


-----------------------------------------------------------------
Keith Cantrell                      Sun Microsystems
Engagement Architect/OS Ambassador  Dallas, TX
Email: Keith.cantrell at sun.com       Phone: 972-392-5014
-----------------------------------------------------------------


Angelo Rajadurai wrote:
> Is there a simple way to get the absolute path. For example,
> I want to monitor opens on a particular file. 
> 
> Something like,
> 
>  dtrace -n
syscall::open*:entry''/copyinstr(arg0)=="/etc/passwd"/{trace(execname)}''
> 
> This will work for cat /etc/passwd but fails for cd /etc; cat passwd.
> 
> I understand ''cwd'' but no idea how I''d check if
the patch is relative or absolute.
> Is there any subroutines? Where in the kernel is this mapping done? Can I
> have a probe in that routine and check for full path?
> 
> Also is there an easy way to look for open of any files in a directory. For
> example I''d like to know when there is a open done in any file
under /etc?
> 
> Thanks,
> 
> Angelo
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Hello Angelo Rajadurai,

Is your question answered with regard to absolute path, I have a doubt regarding
how to find the set of all open files only in  my home directory.

awaiting for your reply,
Partha
 
 
This message posted from opensolaris.org

Hm.

I would think
    fuser *
would be the most simple answer to that question.

Was there something more you interesting in finding out?

Perhaps all from that directory downwards? Provided you don''t have
*too*
many files in your home directory, you could:

   fuser `find .` 2>&1 | grep -v ": $"

might help.

Beyond that, if you have lots and lots of files, you might need to use 
some looping in shell or other.

What problem is it that you are trying to solve with this?

Cheers!

Nathan.







Parthasarathy J wrote:
> Hello Angelo Rajadurai,
> 
> Is your question answered with regard to absolute path, I have a doubt
regarding how to
> find the set of all open files only in  my home directory.
> 
> awaiting for your reply,
> Partha
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Hi Nathan,

I was basically interested in knowing the open files in a particular directory
alone using syscall.

Thanks,
Partha
 
 
This message posted from opensolaris.org

Le mer. 15/11/2006 ? 08:28, Parthasarathy J a ?crit :
> Hello Michael,
> 
> Is there any way for getting the absolute path of the files in Solaris 10?
(through dtrace)
If I understand what you want, here is a quick way:

#!/usr/sbin/dtrace -s

syscall::open:entry
/execname=="yourprogram"/
{
        trace(copyinstr(arg0));
}

You run that dtrace script first, and as you go into your program, it
will show all the files opened, full path. For example, here''s for
mozilla-bin on viewing a new web page:
  0  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif14.pcf.Z
  0  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif12.pcf.Z
  0  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif12.pcf.Z
  0  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif14.pcf.Z
  1  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif14.pcf.Z
  1  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif14.pcf.Z
  1  56527                       open:entry  
/usr/openwin/lib/X11/fonts/misc/Serif14.pcf.Z


This will show library loads too, so if you dont care for that you could
add a condition to filter that.

Francois

Hello Michael,

Is there any way for getting the absolute path of the files in Solaris 10?
(through dtrace)

Thanks,
Partha
 
 
This message posted from opensolaris.org

> Hello Michael,
>
> Is there any way for getting the absolute path of the files in Solaris 10?
> (through dtrace)
>
> Thanks,
> Partha
The DTrace structure fileinfo_t has an fi_pathname string member which is
a file''s pathname.  There are several places you can get a fileinfo_t
from
in DTrace to trace the pathname.  Some examples are:

- by using the "io" provider, which exports fileinfo_t * as args[2]
  for its various probes (see dtrace -l -P io)

- by using the built-in fds[] array and a file descriptor from a probe
  that is associated with user process context (e.g. a system call)

- by translating a vnode_t * with the xlate operator

- by translating a buf_t * with the xlate operator

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

Hello all,

Thanks for your mail.  For Instance:

consider the below dtrace script :-
#!/usr/sbin/dtrace -s

syscall::open:entry
/execname=="vi"/
{
trace(copyinstr(arg0));
}

If I open a file named "a"  from a location  /home/MYDIR using vi, the
above script is giving me the filename without its absolute path as shown below
in S10:-
------------------------------------------------------------------------------------------------------------------------------
CPU     ID                    FUNCTION:NAME
  1   2439                       open:entry   /var/ld/ld.config
  1   2439                       open:entry   /usr/lib/libmapmalloc.so.1
  1   2439                       open:entry   /lib/libcurses.so.1
  1   2439                       open:entry   /lib/libc.so.1
  1   2439                       open:entry   /lib/libgen.so.1
  1   2439                       open:entry  
/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
  1   2439                       open:entry   /usr/share/lib/terminfo//x/xterm
  1   2439                       open:entry   //.exrc
  1   2439                       open:entry   /var/tmp/ExqQaatK
  1   2439                       open:entry   /var/tmp/ExrQaatK
---------------------------------------------------------------------------------------------------------
  1   2439                       open:entry   a
---------------------------------------------------------------------------------------------------------

I would like the output to be of the form as:-
 ---------------------------------------------------------------------------------------------------------
1   2439                        open:entry /home/MYDIR/a
---------------------------------------------------------------------------------------------------------

Please do let me know , what modifications are needed in the above script to
achieve the same.

Thanks in advance,
Partha
 
 
This message posted from opensolaris.org

>I would like the output to be of the form as:-
>
---------------------------------------------------------------------------------------------------------
>1   2439                        open:entry /home/MYDIR/a
>---------------------------------------------------------------------------------------------------------
>
>Please do let me know , what modifications are needed in the above script to
achieve the same.
>  
>
There are several ways that you could do this. One of them would be
to use the fds[] array that Mike mentioned:

#!/usr/sbin/dtrace -s

syscall::open:return
/arg1 >= 0/
{
        trace(fds[arg1].fi_pathname);
}


Opening the file ''x.log'' in my home directory gives:

# ./open.d
dtrace: script ''./open.d'' matched 1 probe
CPU     ID                    FUNCTION:NAME
  0     50                      open:return   
/etc/svc/volatile/repository_door
  0     50                      open:return   
/etc/svc/volatile/repository_door
  0     50                      open:return   
/etc/svc/volatile/repository_door
  2     50                      open:return   
/usr/lib/libmapmalloc.so.1      
  2     50                      open:return   
/lib/libcurses.so.1             
  2     50                      open:return   
/lib/libc.so.1                  
  2     50                      open:return   
/lib/libgen.so.1                
  2     50                      open:return   
/usr/share/lib/terminfo/x/xterm 
  2     50                      open:return   
/home/jhaslam/.exrc             
  2     50                      open:return   
/var/tmp/ExsOaa5G               
  2     50                      open:return   
/var/tmp/ExtOaa5G               
  2     50                      open:return   /home/jhaslam/x.log

The above example works for all open() calls that were successful (i.e.
had a non negative return code).  


Cheers.

Jon.

Dear Jhaslam,

Thanks a lot for your mail. 
The script that you gave :
#!/usr/sbin/dtrace -s

syscall::open:return
/arg1 >= 0/
{
trace(fds[arg1].fi_pathname);
}
worked fine for open entry, when I tried the same for write & unlink entry,
its not working.
One more thing is , I am just interested  about my home directory alone( needs
some substring comparison, I believe, but I didn''t suceed) , it should
not give me syscall entries
namely open,create,write,unlink (abs. path) for other directories.

Please kindly help me regarding the same with a suitable script that gives the
absolute path for syscall::open/create/write/unlink entries in /home directory
alone.

Thanks,
Partha
 
 
This message posted from opensolaris.org

Hello Jhaslam,

I tried with my script for getting the abs. path for the following
syscall::open/unlink/write entries in my home directory. But the following
script is working only for Open entry, correct the script if anything wrong for
other syscall entries.

Script
---------
#!/usr/sbin/dtrace -s

syscall::open:return
/ strstr(fds[arg1].fi_pathname, "/home") != NULL && arg1
>=0/
{
        printf("O");
        trace(fds[arg1].fi_pathname);

}

syscall::unlink:return
/ strstr(fds[arg0].fi_pathname, "/home") != NULL && arg0
>=0/
{

        printf("U");
        trace(fds[arg0].fi_pathname);

}

syscall::write:return
/ strstr(fds[arg0].fi_pathname, "/home") != NULL && arg0
>=0/
{

        printf("W");
        trace(fds[arg0].fi_pathname);

}

Script Output: giving entries only for syscall::open alone.
------------------
./sys.d
dtrace: script ''./sys.d'' matched 3 probes
CPU     ID                    FUNCTION:NAME
  1   2440                      open:return O  /home/Patty/add.sh
  0   2440                      open:return O  /home/Patty/ch.sh
  0   2440                      open:return O  /home/Patty/mimeinstall.sh
  0   2440                      open:return O  /home/Patty/pluginstall.sh
  0   2440                      open:return O  /home/Patty/sam.sh
  0   2440                      open:return O  /home/Patty/samp.sh
  0   2440                      open:return O  /home/Patty/sample.sh
  0   2440                      open:return O  /home/Patty/sample1.sh
  0   2440                      open:return O  /home/Patty/sample2.sh
  0   2440                      open:return O  /home/Patty/script.sh

awaiting for your reply,

Thanks in advance,

Partha
 
 
This message posted from opensolaris.org

>I tried with my script for getting the abs. path for the following
syscall::open/unlink/write entries in my home directory. But the following
script is working only for Open entry, correct the script if anything wrong for
other syscall entries.
>  
>
The script works with open(2) because it relies on the fact that
open() returns a file descriptor and it uses the return to index
the fds[] array directly. There are several ways which you can do this
(which may well be better than the following!) but the following
should do what you want:

#!/usr/sbin/dtrace -s

#pragma D option quiet

syscall::open:return
/ strstr(fds[arg1].fi_pathname, "/home/jhaslam") != NULL &&
arg1 >=0/
{
        printf("O %s\n", stringof(fds[arg1].fi_pathname));

}

fbt::fop_remove:entry
/(self->dir = stringof(args[0]->v_path)) == "/home/jhaslam"/
{
        self->file = stringof(args[1]);
}

fbt::fop_remove:return
/self->file != NULL/
{
        printf("U %s/%s\n", self->dir, self->file);
        self->file = 0;
        self->dir = 0;
}

syscall::write:entry
/(self->str = strstr(fds[arg0].fi_pathname, "/home/jhaslam")) !=
NULL/
{
}

syscall::write:return
/ self->str != NULL/
{
        printf("W %s\n", self->str);
        self->str = 0;
}


# ./stuff.d
W /home/jhaslam/.sh_history
W /home/jhaslam/.sh_history
O /home/jhaslam/.exrc
O /home/jhaslam/uname.d
W /home/jhaslam/.sh_history
U /home/jhaslam/solaris_1.iso

I think the above does what you want but I haven''t got much time
at the minute to check it''s fullproof. Let me know if it
doesn''t do
what you want.

Jon.

Dear Jhaslam,

Thanks for your mail. The script works fine for Open,write - syscall entries,
but unlink/remove entry is not working as expected.
Please do let me know regarding the same.


Thanks,
Partha
 
 
This message posted from opensolaris.org

Partha,

This seems to work (just changed John Haslam''s code a bit for the 
''remove'' part).


fbt::fop_remove:entry
/strstr(stringof(args[0]->v_path), "/home") != NULL/
{
        self->dir = stringof(args[0]->v_path);
        self->file = stringof(args[1]);
}

fbt::fop_remove:return
/self->file != NULL/
{
        printf("U %s/%s\n", self->dir, self->file);
        self->file = 0;
        self->dir = 0;
}


Thanks
Siva


Parthasarathy J wrote:
> Dear Jhaslam,
> 
> Thanks for your mail. The script works fine for Open,write - syscall
entries, but unlink/remove entry is not working as expected.
> Please do let me know regarding the same.
> 
> 
> Thanks,
> Partha
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Assuming we lack access to the fds structure, what would an alternative be?  I
ask because I''m using an implementation of dtrace on Mac OS X, which
seems to be a mostly complete port with a few missing pieces.

I''m comfortable building and maintaining my own fds structure,
populating it with the path argument to open that precedes reads and writes on
the fd.  This approach has been met with some success.  However, open accepts
relative paths, meaning sometimes the file name will not be useful.

I tried to bypass this by using the cwd of the accessing process, but even this
was often incomplete!  Is there any way around this?
 
 
This message posted from opensolaris.org

Ian,
You''ll find fewer "missing pieces" in the next Mac OS X
Leopard Seed
Release (I take it you''re a registered Apple developer eligible for  
seeding.) And you''ll find fewer yet in the GM Leopard. The challenge  
in constructing a full path from a DTrace action comes when you try to  
traverse vnodes -- that usually requires taking a lock.

SCP

On Jan 8, 2007, at 3:07 PM, Ian wrote:
> Assuming we lack access to the fds structure, what would an  
> alternative be?  I ask because I''m using an implementation of
dtrace
> on Mac OS X, which seems to be a mostly complete port with a few  
> missing pieces.
>
> I''m comfortable building and maintaining my own fds structure,  
> populating it with the path argument to open that precedes reads and  
> writes on the fd.  This approach has been met with some success.   
> However, open accepts relative paths, meaning sometimes the file  
> name will not be useful.
>
> I tried to bypass this by using the cwd of the accessing process,  
> but even this was often incomplete!  Is there any way around this?
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
Steve Peters
scp at mac.com

Thanks for the response.

I''m unclear about the vnode traversal complication.  Is this something
I would face if I was limiting my scope to file names for files opened, read or
written by any given user process?
 
 
This message posted from opensolaris.org

A little bit of process watching can really help deal with this problem.  What
we want is a process table which maps a pid to the current directory of that
process (the ''cwd'' environment variable, at least on Mac OS X
currently, only reveals the enclosing directory and not its absolute path, so we
need to do the legwork ourselves).

If we look for *forks and execve, we give the new process the cwd of the parent
(assuming we have the cwd of the parent ;).  We can also trap chdir|fchdir to
monitor updates to the cwd of a process.  We can then prepend any relative path
of a file access with the cwd of the accessing process.

I assume that there are cases in which this breaks down; a more obvious one
being when processes that are running before the dtrace session will not reveal
their cwd until a chdir.  But my preliminary testing suggests it is sufficient
as a reasonably accurate solution, especially when dtrace is run early in a
user''s session.
 
 
This message posted from opensolaris.org

>A little bit of process watching can really help deal with this problem. 
What we want is a proces
s table which maps a pid to the current directory of that process (the
''cwd'' environment variable,
at least on Mac OS X currently, only reveals the enclosing directory and not its
absolute path, so
we need to do the legwork ourselves).
>
>If we look for *forks and execve, we give the new process the cwd of the
parent (assuming we have
the cwd of the parent ;).  We can also trap chdir|fchdir to monitor updates to
the cwd of a process
.  We can then prepend any relative path of a file access with the cwd of the
accessing process.
>
>I assume that there are cases in which this breaks down; a more obvious one
being when processes t
hat are running before the dtrace session will not reveal their cwd until a
chdir.  But my prelimin
ary testing suggests it is sufficient as a reasonably accurate solution,
especially when dtrace is
run early in a user''s session.

Solaris does maintain all this information directly of the u. structure, so
there''s no need
to do all that bookkeeping.

This makes me wonder if a dtrace implementation should not simply offer this as
an abstraction.

Casper

I emphasize that my particular issue was with the Mac OS X implementation, which
currently does not provide an obvious parallel.
 
 
This message posted from opensolaris.org

Ian <ian.archer.am.i at gmail.com> wrote:
> I emphasize that my particular issue was with the Mac OS X implementation,
which currently does not provide an obvious parallel.
I don''t know if this did change recently, but 
I found that macos x was the only platform where I could
not find a way to get the absolute path to an object (e.g. program
or shared library).

If there is a way, I would be interested!

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

All the current solutions on OS X are very suboptimal.

It does work to keep track of each process'' cwd and prepend it to all
relative paths. This isn''t particularly easy though, especially because
of fchdir. There isn''t a reliable way to know what path a particular fd
refers to--a table of fdpaths[pid, fd] will not work properly because not all
fds are close-on-exec. With suitable post-processing by a more flexible
language, one can make this work right. I''m working on some perl
modules to deal with this for Fink, I''ll release the code when the NDA
no longer applies.

One interesting note is that on OS X, you can do [i]fcntl(fd, F_GETPATH,
outpath);[/i] on a fd to get the real path. You usually have to do this for
volfs paths, which are otherwise opaque. But if there''s a way to
trigger fcntls on arbitrary fds from dtrace, then that would solve our problem
(subject to certain caveats about the wisdom of realpath when symlinks are
around).

Note also that darwintrace
(http://svn.macosforge.org/repository/darwinbuild/trunk/darwintrace/) already
exists and allows tracing of open and other calls, with full paths. It needs
some fixes for Leopard, but I''m sure kvv is on the ball. It also needs
to use DYLD_FORCE_FLAT_NAMESPACE, which is a serious problem, but I''ve
sent Apple a patch to fix that: http://10.0.1.201/trac/changeset/567. Hopefully
that''s a realistic workaround to dtrace for some of you.
 
 
This message posted from opensolaris.org