dsmc hangs when starting?

[ldmwndletsm]

This is on Linux. We encountered this problem for the first time last night (haven't seen it on any other clients yet), when after configuring the TSM client (dsm.sys, .opt and all that) for the first time on this particular box, I then tried to run /bin/dsmc, and it hung interminably. I was unable to cancel or suspend it. I had to login in from another shell and terminate it with a '-9'. There was nothing in the dsmerror.log. An admin finally tracked it down to a stale NFS mount point (soft, automounted). The problem was resolved by adding 'nfstimeout 10' to the dsm.sys file. The mount point is still hung. Someone else will need to fix that.

We use domain statements to explicitly enumerate the file spaces to be backed up. We do not back up any NFS mounted file systems.

[ Question ]
Clearly, given that we use individual domain statements, TSM is not going to back up anything under any area that we don't enumerate, NFS or local. This has been my experience on all our clients. I have NEVER once seen that happen, so that's good. BUT why does it care if there's a stale mount point (NFS or local) if that file system is not specified in dsm.sys (i.e. no domain statement for that)? Why would that cause it to hang?

[ Question ]
Can we reliably depend on this 'nfstimeout 10' parameter to help us in these cases? In other words, if the mount point doesn't respond within 10 seconds then TSM will skip it and move on, never mind the fact that it's not even trying to backup anything under there anyway?

[ Question ]
What's the worst case?

Maybe if there was an NFS mount point that we really did want to back up then it would skip it if it didn't get a response in 10 seconds so we would not have any backups for that file system on that particular night?

[ Question ]
Is there some kind of statement to tell TSM to not attempt any status calls on any NFS file systems -- some kind of negation like '-nfs' or something like that -- and instead just pretend like it only has the local file systems?

I thought local only was the default behavior. We do NOT specify 'domain all-local'. Again, we enumerate each local file system with its own domain statement. This avoids a large, unplanned backup if someone creates a new file system that we might not want backed up. I was looking at all-auto-nfs and all-nfs, but these appear the opposite of what we want. Is there some magical statement that I can add to dsm.sys to tell TSM to stop trying to go to outer space. I supposed I could add exclude.dir statements for the automounted parent directories for these NFS areas, but to me that's telling TSM not to back them up, and it's already avoiding them, so that seems moot; it's just for whatever reasons trying to at least get some kind of status on them.

Thank you.

 

[dcabro]

Is this NFS mount a hard one? I've seen system commands hang when waiting on NFS filesystem.

 

[ldmwndletsm]

Thanks, Dcabro. No, it's a soft mount via automounter. There's a number of similar comments out there when doing an internet search on this phenomenon, but what I was really getting at is why does TSM care? I've used EMC NetWorker extensively, and you pretty much tell it 'All', in which case it backs up everything that's a local entry in /etc/fstab, excluding certain ones like tmpfs file systems, or you enumerate the local file systems that you want backed up for that client. Regardless, I've never seen it care about an NFS file system not being available. Now, of course, if NFS is down, then the client itself will probably be having fits, but one specific automounted file system that has a stale mount point? Seems odd. But maybe there's a valid reason?

And it's not as if TSM is trying to back up anything under any of those NFS areas. I see no evidence of that. Instead, it only backups up what I have listed in the dsm.sys file, e.g. 'domain /filesystem_name', and those are all local file systems listed in /etc/fstab. It just seems perplexing that TSM would concern itself with some NFS mount point. Now, it would be one thing, of course, if you were using an NFS mount (soft or hard) for one of the TSM directories, e.g. where the logs are stored and/or the client user or systems option file, etc. Yes, in that case, if the mount point was not responding then I would expect to see it complain or in this case, hang.

Do we have any ideas for this behavior and/or a way to tell TSM not to care about whether any NFS areas are unavailable?