On Thu, Aug 15, 2013 at 06:42:53PM +0200, Michal Židek wrote:
On 08/15/2013 11:01 AM, Lukas Slebodnik wrote:
>On (14/08/13 18:50), Michal Židek wrote:
>>On 08/14/2013 04:39 PM, Lukas Slebodnik wrote:
>>>On (12/08/13 17:47), Michal Židek wrote:
>>>>Hello,
>>>>
>>>>I think it could be useful to store the corrupted memory cache
>>>>before reset. We have very little info about what was really
>>>>wrong in the cache when it was in inconsistent state. This way we
>>>>could ask users to send us copy of the corrupted cache if they
>>>>hit this issue. It could provide some more answers.
>>>>
>>>>Patch is attached. It stores the corrupted cache in
>>>>/var/lib/sss/mc/<cache_name>_corrupted.
>>>>
>>>>Thanks
>>>>Michal
>>>
>>>Please rebase patch on top of patches from thread
>>>"[PATCH] mmap_cache: Check data->name value in client code"
>>>
>>>It cannot be applied cleanly.
>>>
>>>LS
>>>
>>
>>Ok. New patch is attached. (Rebased on top of the patches in thread
>>[SSSD] [PATCH] mmap_cache: Check data->name value in client code)
>>
>>Thanks
>>Michal
>>
>Backup of memory maped was created (gdb cheating)
>
>ACK
>
>LS
Just sending rebased version.
Michal
The patch looks good to me and I was about to push it but I wonder if we
should call sss_log() to explain to the admin what happened and what are
these strange files sssd created?