How would I replicate `lsof` functionality with DTrace?
I tried for example
dtrace -n ''syscall::open:entry /execname == $1/ {printf("%s",
copyinstr(arg0));}'' named
but that does not seem to work, at least not in the way I expect. What I
expected to see was a list of open files that $1 has open, but instead I just
got how many probes DTrace matched. And no further output.
This message posted from opensolaris.org
On Tue, Aug 15, 2006 at 07:05:58AM -0700, UNIX admin wrote:> How would I replicate `lsof` functionality with DTrace?Have you looked at the pfiles(1) command? I suspect one could find out most of what one needs with that. Dan
Sean McGrath - Sun Microsystems Ireland
2006-Aug-15 14:32 UTC
[dtrace-discuss] DTrace instead of `lsof`?
UNIX admin stated:
< How would I replicate `lsof` functionality with DTrace?
<
< I tried for example
<
< dtrace -n ''syscall::open:entry /execname == $1/
{printf("%s", copyinstr(arg0));}'' named
<
You may need to match against open64 as well (32bit apps opening files on
64bit OS)..
Regards,
< but that does not seem to work, at least not in the way I expect. What I
expected to see was a list of open files that $1 has open, but instead I just
got how many probes DTrace matched. And no further output.
<
<
< This message posted from opensolaris.org
< _______________________________________________
< dtrace-discuss mailing list
< dtrace-discuss at opensolaris.org
--
Sean.
.
With that syntax, you won''t get info on existing processes. Try the same with bash, for instance, then exec a new instance of bash. You''ll get some output. On 8/15/06, Sean McGrath - Sun Microsystems Ireland <sean.mcgrath at sun.com> wrote:> > UNIX admin stated: > < How would I replicate `lsof` functionality with DTrace? > < > < I tried for example > < > < dtrace -n ''syscall::open:entry /execname == $1/ {printf("%s", > copyinstr(arg0));}'' named > < > > You may need to match against open64 as well (32bit apps opening files > on > 64bit OS).. > > Regards, > > < but that does not seem to work, at least not in the way I expect. What I > expected to see was a list of open files that $1 has open, but instead I > just got how many probes DTrace matched. And no further output. > < > < > < This message posted from opensolaris.org > < _______________________________________________ > < dtrace-discuss mailing list > < dtrace-discuss at opensolaris.org > > -- > Sean. > . > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060815/a0a4216c/attachment.html>
Sean McGrath - Sun Microsystems Ireland
2006-Aug-15 14:53 UTC
[dtrace-discuss] DTrace instead of `lsof`?
Ian Campbell stated:
< With that syntax, you won''t get info on existing processes. Try
the same
< with bash, for instance, then exec a new instance of bash. You''ll
get some
< output.
Really ? Why would you think that ?
Running dtrace after firefox has been started :
bash-3.00# dtrace -n ''syscall::open*:entry /execname == $1/
{printf("%s", copyinstr(arg0));}'' firefox-bin
dtrace: description ''syscall::open*:entry '' matched 2 probes
CPU ID FUNCTION:NAME
1 44814 open:entry
/usr/openwin/lib/X11/fonts/Type1/cour.pfa
0 45200 open64:entry /export/home/comix/cronly
1 45200 open64:entry
/home/sm97610/.mozilla/firefox/pluginreg.dat
1 44814 open:entry
/home/sm97610/.mozilla/firefox/c5clxi2a.default/extensions.ini
0 45200 open64:entry /usr/share/mime/aliases
0 45200 open64:entry /usr/share/mime/subclasses
0 45200 open64:entry /usr/share/gnome//mime/aliases
0 45200 open64:entry /usr/share/gnome//mime/subclasses
0 45200 open64:entry /usr/sfw/share/mime/aliases
.
.
.
.
.
Regards,
<
< On 8/15/06, Sean McGrath - Sun Microsystems Ireland <sean.mcgrath at
sun.com>
< wrote:
< >
< >UNIX admin stated:
< >< How would I replicate `lsof` functionality with DTrace?
< ><
< >< I tried for example
< ><
< >< dtrace -n ''syscall::open:entry /execname == $1/
{printf("%s",
< >copyinstr(arg0));}'' named
< ><
< >
< > You may need to match against open64 as well (32bit apps opening
files
< >on
< > 64bit OS)..
< >
< >Regards,
< >
< >< but that does not seem to work, at least not in the way I expect.
What I
< >expected to see was a list of open files that $1 has open, but instead
I
< >just got how many probes DTrace matched. And no further output.
< ><
< ><
< >< This message posted from opensolaris.org
< >< _______________________________________________
< >< dtrace-discuss mailing list
< >< dtrace-discuss at opensolaris.org
< >
< >--
< >Sean.
< >.
< >_______________________________________________
< >dtrace-discuss mailing list
< >dtrace-discuss at opensolaris.org
< >
--
Sean.
.
On Tue, Aug 15, 2006 at 07:05:58AM -0700, UNIX admin wrote:> How would I replicate `lsof` functionality with DTrace? > > I tried for example > > dtrace -n ''syscall::open:entry /execname == $1/ {printf("%s", copyinstr(arg0));}'' named > > but that does not seem to work, at least not in the way I expect. What > I expected to see was a list of open files that $1 has open, but > instead I just got how many probes DTrace matched. And no further > output.DTrace and lsof are fundamentally different tools. One traces activity as it happens, the other displays current state. The proc(1) tools (e.g., pfiles(1)) provide much of lsof''s functionality, but not all of it, specifically there''s no tool to query what processes have specific files or sockets open -- but you can approximate what lsof does to provide that functionality: pfiles(1) every process and process its output. Your dtrace oneliner would only trace open(2)s starting from the point where you start that dtrace command. Also, it wouldn''t work well because the string pointed to by arg0 may not be paged in (see the many DTrace resources around about this, not least the developer''s guide on docs.sun.com). Nico --
You will see files that firefox-bin opens *after* you run dtrace, not files that firefox-bin already has opened when you run dtrace. At least, that is what I get on S10U1. On 8/15/06, Sean McGrath - Sun Microsystems Ireland <sean.mcgrath at sun.com> wrote:> > Ian Campbell stated: > < With that syntax, you won''t get info on existing processes. Try the > same > < with bash, for instance, then exec a new instance of bash. You''ll get > some > < output. > > Really ? Why would you think that ? > > Running dtrace after firefox has been started : > > bash-3.00# dtrace -n ''syscall::open*:entry /execname == $1/ {printf("%s", > copyinstr(arg0));}'' firefox-bin > dtrace: description ''syscall::open*:entry '' matched 2 probes > CPU ID FUNCTION:NAME > 1 44814 open:entry > /usr/openwin/lib/X11/fonts/Type1/cour.pfa > 0 45200 open64:entry /export/home/comix/cronly > 1 45200 open64:entry > /home/sm97610/.mozilla/firefox/pluginreg.dat > 1 44814 open:entry > /home/sm97610/.mozilla/firefox/c5clxi2a.default/extensions.ini > 0 45200 open64:entry /usr/share/mime/aliases > 0 45200 open64:entry /usr/share/mime/subclasses > 0 45200 open64:entry /usr/share/gnome//mime/aliases > 0 45200 open64:entry > /usr/share/gnome//mime/subclasses > 0 45200 open64:entry /usr/sfw/share/mime/aliases > . > . > . > . > . > > > Regards, > > < > < On 8/15/06, Sean McGrath - Sun Microsystems Ireland < > sean.mcgrath at sun.com> > < wrote: > < > > < >UNIX admin stated: > < >< How would I replicate `lsof` functionality with DTrace? > < >< > < >< I tried for example > < >< > < >< dtrace -n ''syscall::open:entry /execname == $1/ {printf("%s", > < >copyinstr(arg0));}'' named > < >< > < > > < > You may need to match against open64 as well (32bit apps opening > files > < >on > < > 64bit OS).. > < > > < >Regards, > < > > < >< but that does not seem to work, at least not in the way I expect. > What I > < >expected to see was a list of open files that $1 has open, but instead > I > < >just got how many probes DTrace matched. And no further output. > < >< > < >< > < >< This message posted from opensolaris.org > < >< _______________________________________________ > < >< dtrace-discuss mailing list > < >< dtrace-discuss at opensolaris.org > < > > < >-- > < >Sean. > < >. > < >_______________________________________________ > < >dtrace-discuss mailing list > < >dtrace-discuss at opensolaris.org > < > > > -- > Sean. > . >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060815/e8e1ea25/attachment.html>
Sean McGrath - Sun Microsystems Ireland
2006-Aug-15 15:07 UTC
[dtrace-discuss] DTrace instead of `lsof`?
Ahh. Sorry. Wrong mind thinking there..
Ian Campbell stated:
< You will see files that firefox-bin opens *after* you run dtrace, not files
< that firefox-bin already has opened when you run dtrace. At least, that is
< what I get on S10U1.
<
< On 8/15/06, Sean McGrath - Sun Microsystems Ireland <sean.mcgrath at
sun.com>
< wrote:
< >
< >Ian Campbell stated:
< >< With that syntax, you won''t get info on existing
processes. Try the
< >same
< >< with bash, for instance, then exec a new instance of bash.
You''ll get
< >some
< >< output.
< >
< > Really ? Why would you think that ?
< >
< > Running dtrace after firefox has been started :
< >
< >bash-3.00# dtrace -n ''syscall::open*:entry /execname == $1/
{printf("%s",
< >copyinstr(arg0));}'' firefox-bin
< >dtrace: description ''syscall::open*:entry '' matched 2
probes
< >CPU ID FUNCTION:NAME
< > 1 44814 open:entry
< >/usr/openwin/lib/X11/fonts/Type1/cour.pfa
< > 0 45200 open64:entry /export/home/comix/cronly
< > 1 45200 open64:entry
< >/home/sm97610/.mozilla/firefox/pluginreg.dat
< > 1 44814 open:entry
< >/home/sm97610/.mozilla/firefox/c5clxi2a.default/extensions.ini
< > 0 45200 open64:entry /usr/share/mime/aliases
< > 0 45200 open64:entry /usr/share/mime/subclasses
< > 0 45200 open64:entry
/usr/share/gnome//mime/aliases
< > 0 45200 open64:entry
< >/usr/share/gnome//mime/subclasses
< > 0 45200 open64:entry /usr/sfw/share/mime/aliases
< >.
< >.
< >.
< >.
< >.
< >
< >
< >Regards,
< >
< ><
< >< On 8/15/06, Sean McGrath - Sun Microsystems Ireland <
< >sean.mcgrath at sun.com>
< >< wrote:
< >< >
< >< >UNIX admin stated:
< >< >< How would I replicate `lsof` functionality with DTrace?
< >< ><
< >< >< I tried for example
< >< ><
< >< >< dtrace -n ''syscall::open:entry /execname == $1/
{printf("%s",
< >< >copyinstr(arg0));}'' named
< >< ><
< >< >
< >< > You may need to match against open64 as well (32bit apps
opening
< >files
< >< >on
< >< > 64bit OS)..
< >< >
< >< >Regards,
< >< >
< >< >< but that does not seem to work, at least not in the way I
expect.
< >What I
< >< >expected to see was a list of open files that $1 has open, but
instead
< >I
< >< >just got how many probes DTrace matched. And no further
output.
< >< ><
< >< ><
< >< >< This message posted from opensolaris.org
< >< >< _______________________________________________
< >< >< dtrace-discuss mailing list
< >< >< dtrace-discuss at opensolaris.org
< >< >
< >< >--
< >< >Sean.
< >< >.
< >< >_______________________________________________
< >< >dtrace-discuss mailing list
< >< >dtrace-discuss at opensolaris.org
< >< >
< >
< >--
< >Sean.
< >.
< >
--
Sean.
.
G''Day, On Tue, 15 Aug 2006, UNIX admin wrote:> How would I replicate `lsof` functionality with DTrace? > > I tried for example > > dtrace -n ''syscall::open:entry /execname == $1/ {printf("%s", > copyinstr(arg0));}'' namedThat test should really be, /execname == $$1/ so that $1 is treated as a double quoted string... As Nico said, DTrace is really an event-based tool; listing the entire (and idle) state of a system is something else. I could make DTrace do it, but it wouldn''t be pretty. ;) A while back I did write a Perl/procfs lsof-like tool for Solaris 10, http://www.brendangregg.com/Solaris/lsfd - but it''s not terribly exciting, and the path it uses (the cached vnode path) isn''t 100% accurate. no worries, Brendan
On 16/08/2006, at 1:35 AM, Brendan Gregg wrote:> A while back I did write a Perl/procfs lsof-like tool for Solaris 10, > http://www.brendangregg.com/Solaris/lsfd - but it''s not terribly > exciting, > and the path it uses (the cached vnode path) isn''t 100% accurate.As a kind of mental ECC, are you saying this because the paths are cached at open time and the files may have been renamed or unlinked since then? Boyd
G''Day Boyd, On Fri, 18 Aug 2006, Boyd Adamson wrote:> On 16/08/2006, at 1:35 AM, Brendan Gregg wrote: > > A while back I did write a Perl/procfs lsof-like tool for Solaris 10, > > http://www.brendangregg.com/Solaris/lsfd - but it''s not terribly > > exciting, > > and the path it uses (the cached vnode path) isn''t 100% accurate. > > As a kind of mental ECC, are you saying this because the paths are > cached at open time and the files may have been renamed or unlinked > since then?Yes. Another issue is: $ grep brendan /usr/bin/w # dtrace -n ''fbt::fop_read:entry /execname == "grep"/ { trace(stringof(args[0]->v_path)); }'' dtrace: description ''fbt::fop_read:entry '' matched 1 probe CPU ID FUNCTION:NAME 0 16173 fop_read:entry /usr/sbin/ipf 0 16173 fop_read:entry /usr/sbin/ipf Why is grep reading ipf?. Of course, it is technically correct - ipf has the same inode as w (it''s that wrapper), so it really is reading this file. But not via that pathname. We''d need to cache the path for each file descriptor in uf_entry_t as well (which is only 64 bytes to start with). I''m not sure the overheads incured will be allowed, on the basis it makes us DTrace people happier. The cached vnode path is correct, so long as we remember what it is. Brenadn
>Why is grep reading ipf?. Of course, it is technically correct - ipf has >the same inode as w (it''s that wrapper), so it really is reading this >file. But not via that pathname.How can you tell and do we really care about the distinction? If the file was renamed later, is the vnode path not more accurate and more correct than the "filename at open". (Consider, e.g., /tmp files which have been unlinked, or lockfiles which have been renamed after first being created as tempfiles) Casper