TSM does not work with Jessie (was: Debugging segfaults in commercial software on Jessie)
Bernhard Schmidt <berni@birkenwald.de> wrote:
Hi,
[ IBM TSM client segfaults on some Jessie boxes ]
>>>> The weird thing is, my colleague running sid on his desktop has the same
>>>> problem. My desktop, running Jessie, does _not_ have the same problem.
>>>> The VM in question, also running Jessie, does have this problem.
>>>
>>> Interesting... Perhaps there are differences in the package versions?
>>> Subtle ones? I'd say run a "dpkg -l | grep '^ii'" on both (or all 3)
>>> systems and diff the output... It's bound to flag *something* up,
>>> unfortunately most of it is probably insignificant. But there could be
>>> a gold nugget in there.
>>>
>>>>
>>>> I compared strace on both sides and there is no notable difference (more
>>>> filesystems on my desktop, but nothing extraordinary). Library versions
>>>> are the same. I adjusted environment variables to be the same, no
>>>> difference.
>>>
>>> Ah. You've been there already.
>>
>> Just to report back, so far my attempts have been unsuccessful. I've
>> compared the package lists on all three systems. It was quite messy
>> since two of them are vastly differently managed work desktops, and I
>> could not find any clues in there. I also fiddled some more with
>> environment variables, but no go.
>>
>> I'll keep trying.
>
> Found something. Backtrace:
>
> (gdb) bt
> #0 0x0000000000685ad6 in psCreateCryptoKey(unsigned char*, char*) ()
> #1 0x00000000008f58fb in psPasswordFile::readPassword(unsigned char,
> char*, char*, char const*, unsigned char*, bool) ()
> #2 0x00000000006bbcc8 in PasswordFile::getPassword(unsigned char,
> char*&, unsigned int*, char*, char const*, unsigned char*, bool) ()
> #3 0x00000000006b3261 in pswdFGetPassword(Sess_o*) ()
> #4 0x00000000005ede47 in scPswdEncrypt(Sess_o*, unsigned char*,
> unsigned int, unsigned char*, unsigned int*, unsigned char) ()
>
> More googling revealed https://bugzilla.redhat.com/show_bug.cgi?id=1030142
>
> I'll try to open a case with IBM.
Our TSM guy found the bugreport.
http://www-01.ibm.com/support/docview.wss?uid=swg1IC92662&myns=apar&mynp=DO
IC92662: TSM CLIENT CAN CRASH WITH CERTAIN NODENAMES ON LINUX
DISTRIBUTIONS IF USING GLIBC 2.16 OR HIGHER IN THE FUTURE
APAR status
Closed as program error.
Error description
A code defect has been detected in the
TSM Linux x86 client. While it does not manifest
today in any currently-supported Linux distributions,
here would be the symptom:
When PASSWORDACCESS is set to GENERATE, TSM Linux client
could crash when trying to read or write the password file.
This will happen when installed glibc is version 2.16 or higher,
and only with certain node names. It is not possible to
identify the node name pattern triggering the issue. The
crash can occur on short and long names, with and without
non-alpha characters. However, when the failing combination
of characters is used as the node name, the problem is
consistently recreatable.
One class of node names known to trigger the issue are the
names of 3 symbols or less. For example, ABC, F35, R2 etc.
An example of a longer node name is LINUX-123456
Since currently-supported RedHet and SuSE distributions
do not yet support this Glibc level, there is no current
error. However, this APAR is being opened to address
the potential future issue when that Glibc level is
supported.
Local fix
One of the following workarounds can be used:
1. Downgrade glibc to version 2.15 or lower, if possible.
2. Change the node name. In most cases, adding, deleting or
modifying a single character is sufficient.
3. Set PASSWORDACCESS to PROMPT and add PASSWORD option to
your dsm.sys options file. Make sure to restrict file
system access to dsm.sys so non-authorized users can't
see the node password.
Problem summary
****************************************************************
* USERS AFFECTED: All clients versions 6.3 and 6.4 running *
* on Linux platforms with glibc version 2.16 *
* or higher. *
****************************************************************
* PROBLEM DESCRIPTION: See ERROR DESCRIPTION. *
****************************************************************
* RECOMMENDATION: Apply fixing level when available. This *
* problem is currently projected to be fixed *
* in levels 6.3.2 and 6.4.2. Note that until *
* these levels are available, this *
* information is subject to change at the *
* discretion of IBM. *
****************************************************************
*
Problem conclusion
The problem has been fixed so that it no longer occurs.
Best Regards,
Bernhard
Reply to: