From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 4 19:13:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4424C1065670 for ; Tue, 4 Sep 2012 19:13:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 18FAB8FC1B for ; Tue, 4 Sep 2012 19:13:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 83DC6B992; Tue, 4 Sep 2012 15:12:59 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 4 Sep 2012 12:10:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120904101429.GV33100@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201209041210.07555.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Sep 2012 15:12:59 -0400 (EDT) Cc: Sam Varshavchik Subject: Re: What happened to my /proc/curproc/file? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:13:00 -0000 On Tuesday, September 04, 2012 7:10:42 am Sam Varshavchik wrote: > Konstantin Belousov writes: > > > The procfs links, as well as any other user of vn_fullpath(9) function, > > can only translate a vnode to path if namecache contains useful data. > > As such, the facilities are not guaranteed to success all the time. > > > > In case of rmdir(2), UFS explicitely purges the cache for directory which > > contained direntry of the removed directory. I suspect that you have > > your test program binary located in the same directory which was the parent > > of the removed one. > > Correct. Looks like the same thing applies if I try to use sysctl to get > KERN_PROC_PATHNAME. > > I need some reliable way to get a process's executable file's name, as long > as it's meaningful (the executable file hasn't been removed). There isn't one. What if the file is renamed, or what if it was executed via a symlink that has been removed? What if there are multiple hard links, which one is the "correct" path to return? The namecache bits are a best effort, but if those are purged, the only approach are left with is a brute-force crawl of the filesystem looking for a file whose stat() results match your executable. -- John Baldwin