Perhaps try adding some traceflags to your dsm.opt/dsm.sys, and/or try tracing it at the RHEL level with strace. One or both may shed light on where it's getting stuck.
IIRC, I've seen some odd client hangs (and other weird client failures) when there was a stuck/wedged/borked filesystem mount. A reboot would typically clear those without you realizing what happened. Maybe check "df" and "mount" output, look for oddities, compare the two, etc. (I've seen busted SMB mounts that no longer appear in "df", still appear in "mount", and caused dsmc failures). =Dave On 02/06/2015 01:30 PM, Tim Brown wrote: > This just happed, had been working for months. If I use ./dsmc q fi > I get nada, hangs! Will guarantee a reboot of linux will fix it. > Also no other locations is there another tsm log file > > > Tim > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Sims, Richard B > Sent: Friday, 06 February, 2015 8:45 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM issue with RedHat > >>From my experience, this likely has nothing to do with the TSM server, but >>rather either configuration issues with the client or permissions on the >>dsmerror.log, or its location. > Start with a simple command like ‘dsmc q fi’, as an ordinary user and then > root, to see if there are issues with dsmerror.log access, and expand from > there. ‘dsmc q inclexcl’ will in particular exercise your client > configuration files, as well as attempt to query the server. > We don’t know if your client system ever had viable sessions with the TSM > server or if this is a new system attempting its first interactions. > > Richard Sims, Boston University > -- Hello World. David Bronder - Systems Architect Segmentation Fault ITS-EI, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
