Trace operations on a particular file/device?
grant.b.edwards at gmail.com
Tue Feb 1 23:43:07 UTC 2011
On 2011-02-01, Roland McGrath <roland at redhat.com> wrote:
> No, there is no way that strace can do that for you.
That's what I thought.
[Thanks for the quick answer, BTW]
> Based on the fundamental mechanisms that strace uses, it really can't
> do what you are looking for. It just doesn't know anything about the
> level of distinction you want to make. The system call arguments are
> all it has.
Yea, I sort of gathered that strace doesn't attempt to maintain any
> For most i/o-related calls that you are probably looking for, there
> is nothing distinctive in the arguments except for an integer that is
> a file descriptor. It has no way to know what file or device that
> descriptor refers to.
In the general case, I agree. But, for most (if not all) of the
situations I run into it could...
> A really fancy post-processing could look at previous calls to
> open/dup/etc and keep track for each file descriptor seen what past
> calls were involved in creating it, and surmise the association with
> a file from that.
That's basically what I do.
> We don't have anything like that at all.
Would you like to?
> Even if we did, it still can't tell about file descriptors received
> by inheritance or SCM_RIGHTS or whatever, where strace didn't trace
> the creation.
True. But for all the use-cases I run into, simply remembering what
path was associated with an descriptor returned by open() would
suffice. Though I never need it, one could remember descriptors
returned by creat(), and copy path info when dup() is called as
Were I to write such a feature, would it be likely to be accepted?
I'd obviously prefer not to maintain a forked version of strace, but
it would probably beat writing something from scratch (which somebody
> In Linux, it's possible to deduce some information about descriptors
> by looking at the /proc/PID/fd/FD symlink target. strace doesn't do
> anything like that.
Yup. I could attempt to write some sort of front-end that figures out
file descriptors based on that and then runs strace, but that only
works for long-running processes and capturing the initial open() and
ioctl() calls would be difficult.
> When what you are interested in doing is more intelligent filtering
> at the time of each call to avoid producing voluminous traces, then
> you may do better with a completely different tool, such as Systemtap
> (search for it).
While I can (and have) used systemtap in-house, it isn't an option in
this case. I can't expect my customers to have their machines in the
field set up with systemtap (nor can I ask them to set up systemtap).
Grant Edwards grant.b.edwards Yow! My Aunt MAUREEN was a
at military advisor to IKE &
gmail.com TINA TURNER!!
More information about the Strace-devel