Bug 119695 - pw(8) does not interact with nscd(8)
Summary: pw(8) does not interact with nscd(8)
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 7.0-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Allan Jude
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-15 19:20 UTC by Sven Berkvens-Matthijsse
Modified: 2020-07-11 18:44 UTC (History)
2 users (show)

See Also:


Attachments
reset_cache.diff (449 bytes, patch)
2011-10-03 10:11 UTC, Nali Toja
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Berkvens-Matthijsse 2008-01-15 19:20:01 UTC
I was installing the print/cups port when the portupgrade failed because
the group 'cups' disappeared after it was added.

This happened because I have a /etc/nsswitch.conf with the following in it:

#
# nsswitch.conf(5) - name service switch configuration file
# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $
#
group: cache compat
group_compat: nis
hosts: cache files dns
networks: cache files
passwd: cache compat
passwd_compat: nis
shells: files
services: cache compat
services_compat: nis
protocols: cache files
rpc: cache files

This causes the following line, which the port tried to do:

    if ! pw groupshow cups ; then pw groupadd cups -g 193 ; fi

to fail, because the groupshow command causes the nscd to cache a
negative lookup entry. The groupadd command then adds the user to the
/etc/group file, but FAILS to inform the nscd(8) daemon that all cached
entries in the group file should be purged from memory. Next, the port
checks whether the group 'cups' now exists, but gets a 'NO' because the
negative answer is still in the cache.

I'm not sure whether the vipw(8) utility or similar other utilities
exhibit the same problems.

Fix: 

The pw(8) utility should inform the nscd(8) daemon of the changes that
it makes. So should any system utilities that edit the password or group
files in any way.
How-To-Repeat: Set up the /etc/nsswitch.conf file as above (or similar, at least adding
'cache' to the passwd or group lines). Make sure the nscd daemon is
running. Then try something similar to the command above.
Comment 1 Nali Toja 2011-10-03 10:11:47 UTC
How about the following workaround?
Comment 2 Mark Felder freebsd_committer freebsd_triage 2015-09-18 16:36:56 UTC
assigning to Allan as we chatted about this at vBSDCon 2015
Comment 3 Jov 2016-03-10 01:50:52 UTC
I think the negative-confidence-threshold configuration is introduced to solve problems like this.

from the man page:
negative-confidence-threshold [cachename] [value]
             The number of times a query must have failed before the cache
             accepts that the element can not be found.  At the default value
             of 1 each negative query result is cached and immediately
             returned from the cache on further queries.  Higher numbers cause
             queries to be retried at the configured data sources the given
             number of times, before the negative result is returned from the
             cache on further queries.  This allows to probe for the existence
             of an entry, and then to create it if it did not exist, without
             the negative probe result preventing access to the new entry for
             the duration of the negative TTL.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:23 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 5 Allan Jude freebsd_committer freebsd_triage 2020-07-11 18:44:52 UTC
nscd now supports a negative-confidence-threshold and the negative cache entries properly timeout, so this is less of an issue now.