Date: Thu, 13 Nov 2014 19:07:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mike Gelfand <Mike.Gelfand@LogicNow.com> Cc: "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <20141113170758.GY17068@kib.kiev.ua> In-Reply-To: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 13, 2014 at 10:33:47AM +0000, Mike Gelfand wrote: > Hello, > > I?ve been advised (on #freebsd @FreeNode) to send a mail here with details. > > I?m observing a weird issue where process may not able to determine path to its own binary (and maybe other process binaries as well, thought I didn?t test that) under some [not yet clear to me] conditions. The code I use in production first tries to call sysctl(KERN_PROC_PATHNAME) and if that fails fallback to call readlink(/proc/curproc/file); at some point both calls fail with ENOENT. This happens on two FreeBSD 9 (vanilla 9.1-RELEASE and 9.2-RELEASE) machines, and never happens (or at least never happened in over two years) on FreeBSD 8 (vanilla 8.3-RELEASE-p3); all machines are amd64. I?ve been able to reduce the test case to a sample program [1] which I run using a sample script [2], and the error then happens when I?m building clang-devel from ports. I?ve also recorded a screencast [3]. > > Is this a know defect? Do you need any other information other than provided above to reproduce? > > [1] http://mikedld.com/f/selfpath/selfpath.c > [2] http://mikedld.com/f/selfpath/selfpath.sh > [3] http://mikedld.com/f/selfpath/selfpath.mov This is not a defect. The vnode->path translation uses namecache, which could be purged at any time. The behaviour is typical for most unix implementations. Linux and new Solaris have 'rigid' namecache, where name entry lifetime is the same as the vnode lifetime it is attached to. I am not aware of any useful consequences of such design, except vn_fullpath() working more reliable, but at the cost of increased memory usage. Another possible reason for failed translation is the replacement of the binary while it runs. There, rigid namecache does not help. Typically, less time was spent between exec() and vn_fullpath(), more the chances to get the path back.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141113170758.GY17068>