From basch@alum.mit.edu Sun Mar 18 16:46:32 2018 Return-Path: Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.4.204]) by krbdev.mit.edu (Postfix) with ESMTPS id 9A3FC4FDCB for ; Sun, 18 Mar 2018 16:46:32 -0400 (EDT) X-Content-Analysis: v=2.1 cv=UNEgZ3ry c=1 sm=1 tr=0 a=n+6dpZyqN8Ukwn9TnfXj7Q==:117 a=n+6dpZyqN8Ukwn9TnfXj7Q==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=icM1ZLVPIR7WJq5JnfwA:9 a=QEXdDO2ut3YA:10 Received: from [24.190.185.144] ([24.190.185.144:60662] helo=k9.internal.bright-prospects.com) by mta1.srv.hcvlny.cv.net (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 04/8E-04056-820DEAA5; Sun, 18 Mar 2018 16:46:32 -0400 Received: from [192.168.15.187] (unknown [192.168.15.187]) by k9.internal.bright-prospects.com (Postfix) with ESMTP id E7194801F8 for ; Sun, 18 Mar 2018 16:46:31 -0400 (EDT) From: Richard Basch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master key Date: Sun, 18 Mar 2018 16:46:31 -0400 References: To: Greg Hudson via RT In-Reply-To: Message-ID: X-Mailer: Apple Mail (2.3273) RT-Send-Cc: Content-Length: 1556 I already implementing the workaround to use a file-based config after discovering the double-read. I think the test for S_ISREG seems appropriate (just don’t use lstat since you want to follow symlinks). > On Mar 18, 2018, at 4:05 PM, Greg Hudson via RT wrote: > > The profile library is designed to automatically pick up changes to > the profile each time a profile_get_* call is made. This feature is > of dubious usefulness, because our code base is inconsistent about > how long it caches profile results for, but I've been reluctant to > simplify it out. > > To do this, it calls stat() and compares the mtime to the mtime from > the previous stat() result. It does compare fractional timestamps, > so you would think the double-read would happen all the time (since > stat() on /dev/fd/NN appears to just give the current time). > However, there is also a guard against issuing too many stat() system > calls; at prof_file.c:316 we compare the current time to the last > time we read the filed or called stat(), and only issue a new stat() > call if the second has ticked over. > > So I think in your scenario a failure only happens if the second > ticks over between the initial profile open and the profile read to > get the stash filename. > > I think we could fix this scenario from our side by disabling the > stat-and-reread behavior for things that aren't regular files as > determined by S_ISREG(). From your side, you could of course work > around the issue by using a regular file.