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? _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
