On 08/19/2013 09:51 PM, Michal Židek wrote:
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
I forgot to fixup one change.. will post new patch.
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
