Monitoring a file?

[Cordula's Web]

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