[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