Bug 1026521 - Tivoli-Storage-Manager (TSM) Client-Software crashes (seg fault 11)
Tivoli-Storage-Manager (TSM) Client-Software crashes (seg fault 11)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-04 16:33 EST by Heinz-Peter Heidinger
Modified: 2013-11-04 21:03 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-04 21:03:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Heinz-Peter Heidinger 2013-11-04 16:33:12 EST
Description of problem:
All TSM clients (I tried 6.2.2, 6.3.1, 6.4.0.7) crash since Fedora-19.
This happens in the same manner on a workstation that was manually migrated to F19 by a new installation. It happens as well on a notebook (Lenovo T520) that was upgraded with 'fedup' from F17 to F19.

All the versions worked just fine with Fedora-17 and all the years before. 


Version-Release number of selected component (if applicable):
TSM client 6.2.2, 6.3.1, 6.4.0.7. I tried (stepping back)


How reproducible:
-------------------------------------------------------------------------------
[root@hphws ~]# dsmc
IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 4, Level 0.7  
  Client date/time: 11/04/2013 21:02:29
(c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights Reserved.

Node Name: HPHWS
Aborted (core dumped)
-------------------------------------------------------------------------------

===============================================================================
[root@hphws ~]# gdb dsmc
GNU gdb (GDB) Fedora 7.6.1-42.fc19
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/tivoli/tsm/client/ba/bin/dsmc...done.
(gdb) run
Starting program: /bin/dsmc 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffefc49700 (LWP 19338)]
IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 4, Level 0.7  
  Client date/time: 11/04/2013 21:02:41
(c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights Reserved.

Node Name: HPHWS

Program received signal SIGSEGV, Segmentation fault.
0x00000000006961c6 in psCreateCryptoKey(unsigned char*, char*) ()
Missing separate debuginfos, use: debuginfo-install TIVsm-BA-6.4.0-7.x86_64
(gdb) 
==============================================================================


Steps to Reproduce:
1. Find a location with a TSM server
2. Install a TSM client on an F19 based machine and configure
   (Software source ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/client/v6r4/Linux/LinuxX86/BA/v641/)
 
3. run the distributed storage manager client 'dsmc'. 

Actual results:
You should get a 'tsm>' prompt (see below) but the program crashes with a seg fault right after the introduction message.

Firewalls are turned 'off' on client (hphws) and server (clumas) for testing:
------------------------------------------------------------------------
[root@hphws ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@hphws ~]# 
------------------------------------------------------------------------
[root@clumas ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@clumas ~]# 
------------------------------------------------------------------------

'ping' works smoothly in both directions:
------------------------------------------------------------------------
[root@hphws ~]# ping clumas.naslan
PING clumas.naslan (192.168.254.12) 56(84) bytes of data.
64 bytes from clumas.naslan (192.168.254.12): icmp_seq=1 ttl=64 time=0.115 ms
64 bytes from clumas.naslan (192.168.254.12): icmp_seq=2 ttl=64 time=0.130 ms
64 bytes from clumas.naslan (192.168.254.12): icmp_seq=3 ttl=64 time=0.121 ms
^C
--- clumas.naslan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.115/0.122/0.130/0.006 ms
[root@hphws ~]# 
------------------------------------------------------------------------
[root@clumas ~]# ping hphws.naslan
PING hphws.naslan (192.168.254.11) 56(84) bytes of data.
64 bytes from hphws.naslan (192.168.254.11): icmp_seq=1 ttl=64 time=0.190 ms
64 bytes from hphws.naslan (192.168.254.11): icmp_seq=2 ttl=64 time=0.217 ms
64 bytes from hphws.naslan (192.168.254.11): icmp_seq=3 ttl=64 time=0.176 ms
64 bytes from hphws.naslan (192.168.254.11): icmp_seq=4 ttl=64 time=0.194 ms
^C
--- hphws.naslan ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3121ms
rtt min/avg/max/mdev = 0.176/0.194/0.217/0.017 ms
[root@clumas ~]# 
------------------------------------------------------------------------

So all communication conditions match and the crash cannot happen due to
authentication issues against the TSM server.


Expected results:
I have an older notebook (32 bit; Fedora-14) and here it still works fine
as all the years before ...

-------------------------------------------------------------------------------
[root@hphnote ~]# dsmc
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
  Client Version 5, Release 5, Level 2.0  
  Client date/time: 11/04/2013 20:07:10
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved.

Node Name: LINOTE
Session established with server TSM6LNX: Linux/x86_64
  Server Version 6, Release 3, Level 4.0
  Server date/time: 11/04/2013 21:07:12  Last access: 11/04/2013 21:05:20
tsm> inc /etc

Incremental backup of volume '/etc'
Successful incremental backup of '/etc'

                                  
Total number of objects inspected:        1
Total number of objects backed up:        0
Total number of objects updated:          0
Total number of objects rebound:          0
Total number of objects deleted:          0
Total number of objects expired:          0
Total number of objects failed:           0
Total number of bytes transferred:       0  B
Data transfer time:                    0.00 sec
Network data transfer rate:            0.00 KB/sec
Aggregate data transfer rate:          0.00 KB/sec
Objects compressed by:                    0%
Elapsed processing time:           00:00:02
tsm> 

-------------------------------------------------------------------------------

Additional info:

If this gets into any RHEL distribution and/or update it disables
all infected RHEL production servers from doing machine backups in
 datacenters.

I keep a TSM server in my lab for testing purposes and can assist.

Anyway, I am stuck due to the behavior in Fedora-19 while everything
(Client version 6.4.0.7 and the configuration) worked fine in the
Fedora-17 system. It fails badly after the migration to Fedora-19 with
harsh seg faults - and I cannot get a clue 'why' ...
Comment 1 Josh Boyer 2013-11-04 21:03:22 EST
I'm unclear as to why you think this is a kernel problem.  There are many software components that change between each Fedora release.  Perhaps you should take this up with IBM to start with.  They should be able to get you a full backtrace and at least help narrow the problem down according to whatever level of support your contract provides.

If you are having issues with TSM on a RHEL product, please open a bug against RHEL.

Note You need to log in before you can comment on or make changes to this bug.