I opened PMR 40544,122 for this crash.


On 07/13/2016 04:37 PM, Andrew Raibeck wrote:
> Dave, thanks for that feedback, much appreciated.
>
> And yes, we intended it to default to a maximum size of 25 MB. In most
> situations (not all, depends on volume of work), we figured that was a good
> size to contain many days worth of data without requiring explicit action
> to enable the pruning.
>
> Back to the lab...
>
> Regards,
>
> Andy
>
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2016-07-13
> 16:34:52:
>
>> From: David Bronder <david-bronder AT UIOWA DOT EDU>
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Date: 2016-07-13 16:36
>> Subject: Re: Re: 7.1.6 client default changed?
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>> I'm using the term "rotate" loosely.  Unlike other log files, which prune
>> older contents based on size and age, when the dsminstr.log reaches the
>> configured maximum size, the file is renamed to dsminstr.log.bak and a
> new
>> log is created.
>>
>> At least on RHEL 6.8, the dsmc command that triggers the rotation crashes
>> with a glibc "double free or corruption" error.  Further, if the user
> running
>> that dsmc command can't rename the file (e.g. the file is root-owned and
> mode
>> 666, and in /var/tmp or similar with the sticky bit set, but dsmc is
> running
>> as another user), the dsmc crash happens every time until the file is
> renamed
>> (manually or by a dsmc run by a user with rights to rename it).
>>
>> Not sure if I explained that clearly or not.  To reproduce the crash
> itself
>> (in a timely manner), set "INSTRLOGMAX 1" so the rename happens sooner,
> then
>> run enough dsmc activity to generate 1 MB of instrumentation data and
> trigger
>> the log renaming.
>>
>> Also, the INSTRLOGMAX documentation seems contradictory.  It says if you
>> don't specify the option, the log can grow without limit, but later it
> says
>> the default value is 25 MB (which seems to be correct).
>>
>> =Dave
>>
>>
>> On 07/13/2016 01:30 PM, Andrew Raibeck wrote:
>>> Hi David,
>>>
>>> What is this "rotating" of logs you refer to? Is this related to log
>>> retention and pruning?
>>>
>>> dsminstr.log is managed in a fashion similar to dsmerror.log with
> regard to
>>> user permissions and file locking. Is this causing a problem? Or are
> you
>>> just making an observation?
>>>
>>> Yes, please open a PMR. But if you can elaborate on these issues (how
> we
>>> can try to reproduce them), I can forward them to the appropriate
>>> developer, then hopefully meet in the middle regarding the PMR.
>>>
>>> Regards,
>>>
>>> Andy
>>>
>>>
>>>> From: David Bronder <david-bronder AT UIOWA DOT EDU>
>>>> To: ADSM-L AT VM.MARIST DOT EDU
>>>> Date: 2016-07-13 13:59
>>>> Subject: Re: 7.1.6 client default changed?
>>>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>>>
>>>> Yes, they turned it on by default in 7.1.6 and changed configuration
> from
>>> a
>>>> testflag to a new option (ENABLEINSTRUMENTATION):
>>>>
>>>>
>>>> https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.6/client/
>>>> r_new_for_version.html
>>>>
>>>> One more pain point when supporting client operations for non-root
> users
>>> (log
>>>> file permissions and a lock file).  Plus, I need to open a PMR about a
>>>> dsmc/glibc crash when it tries to rotate the dsminstr.log file.
>>>>
>>>>
>>>> On 07/13/2016 12:32 PM, Lee, Gary wrote:
>>>>> Tsm client 7.1.6
>>>>> Os rhel 6.8
>>>>> Tsm server 6.3.4
>>>>>
>>>>> Looks like client instrumentation is defaulted to on.
>>>>> Is this new?
>>>>>
>>>>> No flags in my dsm.opt or dsm.sys.
>>>>>
>>>>
>>

--
Hello World.                                David Bronder - Systems Architect
Segmentation Fault                                      ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder AT uiowa 
DOT edu