Date: Sun, 23 Nov 2003 11:13:29 +0100 (CET) From: "Cordula's Web" <cpghost@cordula.ws> To: grog@FreeBSD.org Cc: freebsd-questions@freebsd.org Subject: Re: Monitoring a file? Message-ID: <200311231013.hANADTpd097665@fw.farid-hajji.net> In-Reply-To: <20031123002851.GD82843@wantadilla.lemis.com> (grog@FreeBSD.org) References: <200311222258.hAMMwApd092388@fw.farid-hajji.net> <20031123002851.GD82843@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311231013.hANADTpd097665>