On 08/19/2013 09:10 PM, Jakub Hrozek wrote:
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?
Ok. When the copy of memcache is successfully created a sss_log with
SSS_LOG_NOTICE is called. We already do enough noise in sssd logs so I
think NOTICE level in syslog is sufficient.
New patch attached.
Michal