Summary: How to work with the name service cache on SLES.
Date: Around 2010
Refactor: 16 April 2025: Checked links and formatting.

Most times, with linux server you can flush dns and other name services cache by simply restarting the name service cache daemon. However, as you can see here, this does not work on SLES for LDAP group cache:

List the LDAP groups of the user:

# groups sjoerd
sjoerd : LDAPUsers autoyast server2

Stop the NSC Daemon:

# /etc/init.d/nscd stop
Shutting down Name Service Cache Daemon                                                                                                                                done

Now see what the real group memberships are:

# groups sjoerd
sjoerd : LDAPUsers server2

Start the NSC Daemon:

# /etc/init.d/nscd start
Starting Name Service Cache Daemon                                                                                                                                     done

List the LDAP groups of the user:

# groups sjoerd
sjoerd : LDAPUsers autoyast server2

When the daemon does not run you can see that user sjoerd is a member of 2 groups. When the cache daemon does run it's suddenly a member of three groups. That's not correct, and the service has just been restarted! Although I've been searching extensively, I couldn't find why the cache wouldn't flush.

Since there is no real solution to the problem (bug or feature?), the solution is to prevent the LDAP groups from being cached. The settings for this are in /etc/nscd.conf:

/etc # cat nscd.conf | grep -v '^[#]'


logfile                 /var/log/nscd.log
        debug-level             3
        paranoia                no

        enable-cache            passwd          yes
        positive-time-to-live   passwd          600
        negative-time-to-live   passwd          20
        suggested-size          passwd          211
        check-files             passwd          yes
        persistent              passwd          yes
        shared                  passwd          yes
        max-db-size             passwd          33554432
        auto-propagate          passwd          yes

        enable-cache            group           yes
        positive-time-to-live   group           600
        negative-time-to-live   group           60
        suggested-size          group           211
        check-files             group           yes
        persistent              group           yes
        shared                  group           yes
        max-db-size             group           33554432
        auto-propagate          group           yes

        enable-cache            hosts           yes
        positive-time-to-live   hosts           600
        negative-time-to-live   hosts           0
        suggested-size          hosts           211
        check-files             hosts           yes
        persistent              hosts           no
        shared                  hosts           yes
        max-db-size             hosts           33554432

        enable-cache            services        yes
        positive-time-to-live   services        28800
        negative-time-to-live   services        20
        suggested-size          services        211
        check-files             services        yes
        persistent              services        yes
        shared                  services        yes
        max-db-size             services        33554432

You can set the

enable-cache            group           yes

line to “no” and then restart the nsc daemon. This will prevent the issue from happening.

Note: This change will increase the load on your LDAP server. You should monitor the LDAP server to watch for the impact.

If things get really nasty you might want to consider to do no caching at all. This means to turn off the daemon and prevent it from starting up again on a reboot:

Prevent the service from starting up automatically:

# chkconfig nscd
nscd  on
# chkconfig nscd off
# chkconfig nscd
nscd  off

Stop the NSC Daemon:

# /etc/init.d/nscd stop
Shutting down Name Service Cache Daemon                                                                                                                                done

I found this in the manpages from SLES, the reason I post this here is that the group command might get obsolete in future releases:

File: coreutils.info,  Node: id invocation,  Next: logname invocation,  Up: User information

20.1 `id': Print user identity

==============================

`id' prints information about the given user, or the process running it
if no user is specified.  Synopsis:

     id [OPTION]... [USERNAME]

   By default, it prints the real user ID, real group ID, effective
user ID if different from the real user ID, effective group ID if
different from the real group ID, and supplemental group IDs.

   Each of these numeric values is preceded by an identifying string and
followed by the corresponding user or group name in parentheses.

   The options cause `id' to print only part of the above information.
Also see *note Common options::.

`-g'
`--group'
     Print only the group ID.

`-G'
`--groups'
     Print only the group ID and the supplementary groups.

`-n'
`--name'
     Print the user or group name instead of the ID number.  Requires
     `-u', `-g', or `-G'.

`-r'
`--real'
     Print the real, instead of effective, user or group ID.  Requires
     `-u', `-g', or `-G'.

`-u'
`--user'
     Print only the user ID.


   An exit status of zero indicates success, and a nonzero value
indicates failure.

   Primary and supplementary groups for a process are normally inherited
from its parent and are usually unchanged since login.  This means that
if you change the group database after logging in, `id' will not
reflect your changes within your existing login session.  Running `id'
with a user argument causes the user and group database to be consulted
afresh, and so will give a different result.