From owner-freebsd-questions@FreeBSD.ORG Sun Nov 23 02:14:09 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F00B16A4CE; Sun, 23 Nov 2003 02:14:09 -0800 (PST) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA50B43FBD; Sun, 23 Nov 2003 02:14:07 -0800 (PST) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (localhost [127.0.0.1]) by fw.farid-hajji.net (8.12.10/8.12.10) with ESMTP id hANADTpd097665; Sun, 23 Nov 2003 11:13:30 +0100 (CET) (envelope-from cpghost@cordula.ws) Date: Sun, 23 Nov 2003 11:13:29 +0100 (CET) Message-Id: <200311231013.hANADTpd097665@fw.farid-hajji.net> From: "Cordula's Web" To: grog@FreeBSD.org In-reply-to: <20031123002851.GD82843@wantadilla.lemis.com> (grog@FreeBSD.org) X-Mailer: Emacs-21.3.1/FreeBSD-4.9-STABLE References: <200311222258.hAMMwApd092388@fw.farid-hajji.net> <20031123002851.GD82843@wantadilla.lemis.com> cc: freebsd-questions@freebsd.org Subject: Re: Monitoring a file? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cpghost@cordula.ws List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2003 10:14:09 -0000 > > 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/