Does anyone use nscd?
bushman at freebsd.org
Fri Oct 7 10:30:35 UTC 2011
While I agree that nscd negative caching bug should be fixed, it won't
help with the problem that users encounter during ports installation.
When, for example, user "x" is added during port install, the
following steps are involved:
1. Script checks if "x" is present in the users list. Nscd is queried,
it returns negative and caches negative answer.
2. Script adds user "x".
3. Script checks that "x" have indeed been added. Nscd is queried,
cachned negative answer is returned. Script fails as a result.
So unless negative caching time is less than the time between steps 1)
and 3) the issues during ports installation will persist. I like
perryh@ idea of fixing it within ports. If we introduce some standard
way of adding users/groups then this standard routine can take care of
nscd. I don't know how much work this will require though...
On Fri, Oct 7, 2011 at 11:51 AM, Tom Evans <tevans.uk at googlemail.com> wrote:
> On Fri, Oct 7, 2011 at 3:05 PM, <perryh at pluto.rain.com> wrote:
>> Ivan Voras <ivoras at freebsd.org> wrote:
>>> On 05/10/2011 09:38, Trond Endrest??l wrote:
>>> > On Wed, 5 Oct 2011 12:54+1030, Daniel O'Connor wrote:
>>> >> In my experience ncsd seems to cache negative hits forever,
>>> >> regardless of the setting for negative-time-to-live.
>>> > I'm glad to see I'm not the only one who has noticed this odd
>>> > behaviour of nscd. Shame on me for not speaking up sooner, but
>>> > I feared I might be proved wrong (again), and yes, that's a
>>> > lame excuse. :-/
>>> It's very annoying when installing ports which add users - the
>>> port adds it then in some future code checks it and it fails.
>>> I've noticed it with at least CUPS.
>> Sounds as if there ought to be a unified mechanism for ports
>> to use when adding users, so that necessary notifications --
>> e.g. restarting nscd if it is running -- can be done in a
>> standardized way and any necessary customizations can be done
>> in a single place.
> Or nscd fixed to not permanently cache negative hits. Seems more correct.
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers