Trace operations on a particular file/device?

[Grant Edwards]

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
state info.

> 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[23]() is called as
well.

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
has proposed).

> 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!!