On Mon, Aug 19, 2013 at 10:14:07PM +0200, Jakub Hrozek wrote:
On Mon, Aug 19, 2013 at 09:56:23PM +0200, Michal Židek wrote:
On 08/19/2013 09:52 PM, Michal Židek wrote:
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.
This is the correct one.
Michal
Pushed to master sssd-1-10 and sssd-1-9