> > 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). > > That's not exactly red-handed, it's just not too long afterwards.
Right. Ideally, the kernel should block P(u), notify P(m), and then unblock P(u). Of course, this doesn't happen with the current kernels (?). > I don't think you're going to find a simple answer to this one. If I > had this problem, I'd probably build a kernel with special code to > recognize opens on this file (so that you can get the address of the > file table) and writes to it (though this may be redundant). The code > would enter the kernel debugger or maybe just panic, depending on the > environment. That way you'd really catch the culprit red-handed. Yes, that was the idea with the debug nfsd. P(u) would block as long as debug-nfsd didn't reply, and would be hanging around in the process table. Surely, P(u) would still not be directly identifiable by debug-nfsd. Modifying the kernel really seems to be the only solution here. > An alternative might depend on knowledge of what the file does. It is a DNS map. On that special host, named is not even running, so I suspect some rogue program. And no, there's nothing in crontab either.... However, the problem is more general than this. I just hoped that a generic solution exists. > Greg Thank you for all the help. -- Cordula's Web. http://www.cordula.ws/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
