[SSSD] [PATCHES] sss_cache tool invalidates records in memory cache

Simo Sorce ssorce at redhat.com
Mon Sep 17 16:02:10 UTC 2012


----- Original Message -----

> Ok. I changed it all a bit. The mechanism is now as follows:
> 1. sss_cache creates a file, that serves as flag with the meaning
> "It was me, who sended SIGHUP".
> 2. monitor receives sighup and checks if the flag (file) exist
>      - exists: signal (dbus signal) nss to clear memory cache
>      - not exists: rotate logs and  signal other services to rotate
>        logs too
> 
> To achieve this the te_server_hup is no longer used by monitor, all
> what monitor uses to handle SIGHUP is monitor_hup. Other services
> still remain using te_server_hup.
> 
> With the file flag, there is no need for nss_hup function. NSS will
> remain using the old te_server_hup function and new
> nss_clear_memcache
> function is introduced to handle the caches.
> 
> The flag (file) is removed in the sss_mmap_cache_init function. The
> reason for not placing it to the monitor_hup handler was to avoid
> this
> scenario:
> 1. Someone by mistake calls sss_cache tool when sssd is not running
> 2. The flag (file) is created
> 3. after that, sssd is turned on
> 4. someone sends SIGHUP to monitor to rotate logs
> 5. monitor sees the flag (file)
> 6. sssd clears memory cache and does not rotate anything
> 7. someone thinks how good he cleared the caches (?!NOoo!?)
> 
> When unlink is moved to init function, this will never happen (reinit
> calls init, so it should be OK).
> 
> New patches are in attachment.

Hi Michal,
you bring up a good point about the race with startup, but I am not
totally convinced about the approach you used to address it.

The race you point out could be easily resolved by having the init code
unlink() the reset file w/o acting on it. That would address the problem
of cleaning up stale file.

Your solution though has another race, if someone runs sss_cache and at
the same time the system wants to rotate logs you may get the monitor to
ignore the legit SIGHUP and only clean the cache but not rotate the logs.

This is why I planned to have the check in sssd_nss and always do log 
rotation (monitor always sends the SIGHUP around).

The other 'problem' with the current code is that you are 'leaking'
information specific to the sssd_nss backend into the monitor code.
This is not really a major issue, but I prefer to avoid these 'shortcuts'
and keep the monitor dumber wrt frontend or provider specific features.

Other nitpicks: in the current code if you get a fatal error do not do
anything if the stat fails with an error different from ENOENT. I think
the SIGHUP should always be sent (as I said above) and the failure should
only be logged, not be fatal (of course this is not a problem if we move
back checks into sssd_nss).

Simo.

-- 
Simo Sorce * Red Hat, Inc. * New York



More information about the sssd-devel mailing list