Date: Fri, 5 Dec 2014 11:55:54 +0000 From: Mike Gelfand <Mike.Gelfand@LogicNow.com> To: "hackers@freebsd.org" <hackers@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com> Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <2A50A149-E1E8-4EBD-A6A1-013687CF0648@logicnow.com> In-Reply-To: <20141114102306.GE17068@kib.kiev.ua> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> <B655709E-0D6F-4DE1-A746-9A20B897BEA8@logicnow.com> <20141114102306.GE17068@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Sorry for late reply. On Nov 14, 2014, at 1:23 PM, Konstantin Belousov <kostikbel@gmail.com> wrote: >> error condition, what should I do to get the path reliably? Should I >> retry (and how many times)? You?re saying cache is being purged; does >> it mean that when I ask for path then cache is populated again? Does >> it guarantee then that I?ll be able to get the path on next call? >> Could you guarantee that I?ll be able to get the path at all if I fail >> two or more times? Should I rely on ENOENT specifically when retrying? > After the path resolution failed, it can only succeed later if the cache > is populated again. Cache cannot be populated by the vnode->path > request, just think where to get the data ? The cache is populated > when lookup is performed, so if nothing accessed the file by name > between your two calls, second translation fails as well. Still no answer to the very first question: how do I get path to current or any other process binary reliably? The fact that this sysctl is not guaranteed to work and there's no way to make it work if all I know is process ID makes it quite useless for programs which need this information. Are you saying that this information cannot at all be reliably retrieved in FreeBSD? Is there a way to at least prolong cache entry lifetime or increase cache size so that eviction happens as rarely as possible (if at all)? Regards, Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A50A149-E1E8-4EBD-A6A1-013687CF0648>