Hi On Tue, Nov 19, 2013 at 10:14:22AM +0000, Bernhard Schmidt wrote: > Hi, > > I'm a bit at a loss here, maybe someone has an idea how to look. > > We run a commercial software called IBM Tivoli Storage Manager (TSM) for > Backup purposes. It is quite an ugly beast, but it works just fine on > Wheezy.
Oh. You have my condolences. Anything starting with "IBM Tivoli" is... bad. > When upgrading to Jessie, it produces a segfault on most systems > > root@lxmhs70:~# dsmc q fi > IBM Tivoli Storage Manager > Command Line Backup-Archive Client Interface > Client Version 6, Release 4, Level 0.7 > Client date/time: 11/19/2013 10:57:01 > (c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights > Reserved. > > Node Name: LXMHS70 > Aborted You may be able to make some headway by using strace, to see which systems calls it uses: root@lxmhs70:~# strace dsmc q fi But it is bound to be a long slog.... (nice hostname by the way...) > 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. > > My colleague "fixed" it by using an older libc, using this method > (http://www.debian-administration.org/users/lee/weblog/30) and the > following packages > > libc6_2.13-38_amd64.deb > libgcc1_4.7.2-5_amd64.deb > libstdc++6_4.7.2-5_amd64.deb > libtinfo5_5.9-10_amd64.deb > > but as I said, it works for me just fine. When running such software, I find it handy to relegate it to a chroot environment: commercial software tends to be very fickle with dependencies - many of which are undeclared. So to avoid too many distracting discussions, I'd be sorely tempted to set up a debian stable chroot to do stuff in. Or go the whole hog and use a LxC instance... > Does anyone have an idea how to debug this? I don't want to open a bug > report right now on either side because its commercial software on a > non-stable distribution version. Well - if the developers are worth their salt, they probably *want* to know about this not working on the next version of Debian. I know that I would.... Best bet would probably be to look at migrating away from it... But I suspect that the golden rule[1] applies and you're stuck with it because that's what the PHB wanted... [1] The golden rule: Those with the gold make the rules. -- Karl E. Jorgensen -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131119133329.GA2041@hawking
