[SSSD] RFC: Talloc reports

Jakub Hrozek jhrozek at redhat.com
Thu Sep 3 11:19:25 UTC 2015


On Thu, Sep 03, 2015 at 01:11:23PM +0200, Pavel Březina wrote:
> On 09/03/2015 01:04 PM, Pavel Reichl wrote:
> >
> >
> >On 09/03/2015 12:48 PM, Pavel Březina wrote:
> >>Hi,
> >>due to recent memory leak issues, I think it would be good to provide
> >>a built-in way to store talloc full report in a file. It proved to be
> >>very helpful in detection of the location where memory leak occurs,
> >>but we always obtained it from custom built.
> >+1
> >>
> >>I would very much like to write a patch, but I'd like to hear your
> >>opinion on how it should be obtains. I have few ideas:
> >>
> >>1) Periodic task -- periodically (1 hour?) store talloc full report
> >>into a file.
> >Some leaks might take too much memory to last more than a couple of
> >minutes. Some "semi" leaks could be freed when their parent context is
> >freed - but they should be freed way earlier on their own.
> >>
> >>2) Generate report on signal.
> >Do you have any signal in mind? I mean can we abuse some "standard"
> >signals?
> >Using SIGUSR works nice, alas we can steal it...unless we add new
> >configuration option?
> 
> Well, it is possible to abuse SIGUSR signal or some other, but I would
> prefer not to do it anymore, since we have nice D-Bus support.

But do you think the workflow would be nicely digestable by admins?

The situation we're trying to cover would be admin who notices sssd
processes consume too much memory. We should have a nicely documented
approach to help this admin..


More information about the sssd-devel mailing list