TSM BA Client on Gentoo Linux - sockets not closing

[mccleld]

Team,

Well, have *somehow* managed to get TSM BA Client on to Gentoo Linux for a client (although was heavily reliant upon their Gentoo sysadmin). However, I'm now encountering a problem using dsmcad:

The Tivoli Storage Manager Backup-Archive Web Client is configured (/etc/tivoli/dsm.sys) to listen on port 1581 for incoming requests from web clients. However, when restarting the process ($DSM_DIR/dsmcad - usu via the`start-stop-daemon --start --exec /opt/tivoli/tsm/client/ba/bin/dsmcad` commands) it appears to be binding itself to a different port (as visible in the dsmcad logfile in /var/log/dsmwebcl.log - 'ANS3000I HTTP communications available on port 1837'). Performing a `netstat -a` reveals why:

fileshare-hms log # netstat -a | grep 1581
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1235 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1234 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1233 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1232 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1222 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1221 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1231 FIN_WAIT1
tcp 0 85666 fileshare-hms.win.:1581 rdavison2-hms.win.:1230 FIN_WAIT1

For some reason these sockets aren't getting closed and are hanging around in FIN_WAIT1 from yesterday - I'm guessing this is preventing a restart of the dsmcad process from binding onto this port and therefore is forced to listen on another (it's been choosing 1837 as per the above).

At this point, my TCP/IP and Linux starts to get a little hazy, but my understanding is that there should be a timeout value configured in the kernel after which any sockets in this limbo state should be shut down. The `sysctl -a` command seems to be useful for perusing these kernel parms, and it reveals 'net.ipv4.tcp_fin_timeout = 60'. For some reason, this doesn't seem to be getting obeyed.

I don't seem to be able to find any way of closing these sockets manually - there are no processes in the process listing that I can easily identify, and no commands that I can find to go closing them. From googling, some people suggest that the only resolution here is to reboot...

I don't know if this is a TSM client problem or a Gentoo problem. I've never seen it before, and from searching through the IBM.com TSM support pages and the ADSM.org archives I see nothing either - both of these resources are pretty comprehensive and if this were a known bug, or if others had encountered it I'd have expected this to be documented.

I'm stumped - as a workaround, I've configured /etc/tivoli/dsm.sys to listen on port 1582 instead.

Anyone any bright ideas/experiences?

Also, anyone care to share their /etc/init.d/tsmsched startup script (I made my own up, seems pretty straighforward though):

#!/sbin/runscript
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

depend() {
need net
}

start() {
ebegin "Starting TSM Client Acceptor Daemon"
start-stop-daemon --start --exec /opt/tivoli/tsm/client/ba/bin/dsmcad
eend $?
}

stop() {
ebegin "Stopping TSM Client Acceptor Daemon"
start-stop-daemon --stop --exec /opt/tivoli/tsm/client/ba/bin/dsmcad
eend $?
}

restart() {
ebegin "Restarting TSM Client Acceptor Daemon"
start-stop-daemon --stop --exec /opt/tivoli/tsm/client/ba/bin/dsmcad
start-stop-daemon --start --exec /opt/tivoli/tsm/client/ba/bin/dsmcad
eend $?
}

Rgds,

David Mc