Monitoring a file?

Scott W wegster at
Sat Nov 22 15:17:08 PST 2003

Cordula's Web wrote:

>Hello list,
>maybe someone knows the answer for the following problem already?
>  What is the canonical way to monitor accesses to a file?
>Problem description:
>  A file, let's say, /path/to/a/file, is being modified by
>  an unknown process P(u) at random times. Unfortunately,
>  the name of the program ran by P(u) is unknown.
>  The goal is to catch P(u) "red-handed," just the moment
>  it accesses /path/to/a/file, e.g. by looking up in the
>  process table with ps(1).
>No solutions:
>  1. Polling /path/to/a/file with stat(), lstat(), fstat(),
>     and running a ps(1) as soon as the access times change;
>     then diff(1) on all ps listings, trying to identify P(u).
>  This solution is not good enough, because P(u) runs faster
>  than the polling interval, and setting this polling interval
>  to very small values is too expensive on a production server.
>  2. NFS mounting /path/to/a/file, and modifying nfsd(1) in such
>     a way, that it runs ps(1) as soon as a request for
>     /path/to/a/file is received. Let's call the modified
>     nfsd nfsd-debug. Of course debug-nfsd and P(u) must run
>     on the same machine.
>  This is not good enough either, because ps(1)-listing
>  is too long, and not always conclusive.
>  3. Using kqueue(2) and kevent(2) in a monitoring process
>     P(m). P(m) would be attached to /path/to/a/file, and
>     would use kevent(2) to receive kernel notifications
>     as soon as /path/to/a/file is touched.
>  Probably not enough either, because it is not possible to
>  know which process triggered the event, only that an
>  event occured on that vnode.
>  -> Is that correct? I'm not familiar enough with kevent(2).
>  I assume that some kind of monitoring process P(m) is
>  needed, which would attach to /path/to/a/file, use kevent(2)
>  to get notifications from the kernel. Now, how could P(m)
>  find out, which process generated the events it gets?
>Alternative question:
>  Is there another, preferably clever, way to solve this problem?
>Thank you.
You may want to take a look at 'fam,' in /usr/ports/devel/fam , as some 
of the code's already been done for this type of monitoring AFAIK...


More information about the freebsd-questions mailing list