Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Nov 2003 18:16:59 -0500
From:      Scott W <wegster@mindcore.net>
To:        cpghost@cordula.ws
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Monitoring a file?
Message-ID:  <3FBFEE6B.4000803@mindcore.net>
In-Reply-To: <200311222258.hAMMwApd092388@fw.farid-hajji.net>
References:  <200311222258.hAMMwApd092388@fw.farid-hajji.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Cordula's Web wrote:

>Hello list,
>
>maybe someone knows the answer for the following problem already?
>
>Summary:
>========
>  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).
>
>Question:
>=========
>
>  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...

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FBFEE6B.4000803>