Hello list,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...
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.
Scott
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
