On Tue, Sep 29, 2015 at 02:12:48PM +0200, Pavel Reichl wrote:
On 09/29/2015 02:04 PM, Pavel Březina 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.
>>
>>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.
>>
>>2) Generate report on signal.
>>
>>3) Generate report on D-Bus method.
>>
>>4) Provide a tool that would do 2) or 3).
>>
>>I personally favor 1).
>
>Hi,
>I'd like to bring back this discussion and create a ticket from it. I've gone
through those mails again and I'd like to sum it up here:
>
>1) Create a new option debug_talloc_report_interval that defaults to 0 (disabled).
This option says how often SSSD captures talloc report.
+1
>
>2) Periodically obtain talloc full report
+1
>
>3) Store the report -- from the discussion it seems that you would like to made the
report as part of logs. I'd rather store it in a separate file since in case of a
memory leak it may get very large. It would be also simpler to process, in my opinion.
Definitely separate file.
+1
>
>I think it is OK to override the talloc report on each period so the file can be
named just $process.talloc.
It might show useful in future to have 'history' of talloc reports, but for first
version overwriting is fine by me.
We can later add a format for the new file maybe, which might include
some kind of timestamp that would automatically change over time,
providing unique filename. But if, from your experience debugging these
issues you think a single fine is enough, then fine by me.