[BUG] Getting path to program binary sometimes fails

Mike Gelfand Mike.Gelfand at LogicNow.com
Fri Dec 5 12:01:27 UTC 2014


John,

Sorry for late reply.

On Nov 20, 2014, at 7:25 PM, John Baldwin <jhb at freebsd.org> wrote:
> 
>> Since you’re saying that current behavior is not a defect, maybe 
>> documentation is wrong (incomplete, misleading) then? I will readily accept 
>> the “not a defect” explanation, but only if one wouldn’t have to ask you every 
>> time this oddity is met. If this is the expected 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?
> 
> Is this over NFS?  NFS is more aggressive than local filesystems in purging
> name cache entries because there are inherent races in NFS with certain 
> fileservers (ones that don't use sub-second timestamps), so by default entries 
> always expire after about a minute.  You can change that via the 'nametimeo' 
> mount option (takes a count in seconds).

No, not NFS but ZFS. Could that be an issue? The FreeBSD 8 machine I mentioned before has UFS.

Also, as you can see from the video I recorded (and from the code I provided), path resolution succeeds and fails within fractions of a second after process startup.

Regards,
Mike


More information about the freebsd-hackers mailing list