From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 5 11:56:13 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA21F61 for ; Fri, 5 Dec 2014 11:56:13 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0090.outbound.protection.outlook.com [65.55.169.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8FEDF57 for ; Fri, 5 Dec 2014 11:56:12 +0000 (UTC) Received: from DM2PR04MB480.namprd04.prod.outlook.com (10.141.105.25) by DM2PR04MB541.namprd04.prod.outlook.com (10.141.100.12) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 11:56:03 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB480.namprd04.prod.outlook.com (10.141.105.25) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 5 Dec 2014 11:55:55 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.29]) by DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.29]) with mapi id 15.01.0026.003; Fri, 5 Dec 2014 11:55:55 +0000 From: Mike Gelfand To: "hackers@freebsd.org" Subject: Re: [BUG] Getting path to program binary sometimes fails Thread-Topic: [BUG] Getting path to program binary sometimes fails Thread-Index: AQHP/y1OF6HbydE23kCBwyNP5wFRKZxeymWAgAEZIgCAAAgTAIAhGtwA Date: Fri, 5 Dec 2014 11:55:54 +0000 Message-ID: <2A50A149-E1E8-4EBD-A6A1-013687CF0648@logicnow.com> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> <20141114102306.GE17068@kib.kiev.ua> In-Reply-To: <20141114102306.GE17068@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [128.140.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB480;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB480; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377454003)(189002)(24454002)(46102003)(21056001)(92566001)(40100003)(122556002)(99396003)(2501002)(97736003)(83716003)(93886004)(120916001)(87936001)(4396001)(19580395003)(19580405001)(2656002)(64706001)(20776003)(86362001)(66066001)(33656002)(101416001)(76176999)(54356999)(68736005)(50986999)(110136001)(62966003)(106356001)(99286002)(77156002)(105586002)(106116001)(36756003)(82746002)(31966008)(2351001)(107046002)(102836002)(85282002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB480; H:DM2PR04MB477.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB541; X-OriginatorOrg: logicnow.com X-Mailman-Approved-At: Fri, 05 Dec 2014 12:51:50 +0000 Cc: Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 11:56:13 -0000 Hello, Sorry for late reply. On Nov 14, 2014, at 1:23 PM, Konstantin Belousov wrot= e: >> 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 guaran= teed 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 s= aying 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=