A save group started last night @ 20:00, there is still one client in the incomplete save set list "client: All" & "client: index" after 16+ hours. Group inactivity timeout value is set to the default of 30 minutes.
It was determined that rpcinfo showed nsrexecd to be running and users could attach to the server to logon, but login attempts hung after entering password.
I believe timeout applies to client data backup - not the one belonging to server. What you can do is stop the group and restart it to have it completed.
Thanks for the reply, I agree it applies to the client data backup. I was trying to determine why the savegroup did not time out automatically, thereby causing my client's backup admin to manually intervene.
The savegroup actually failed and began the cloning process without any intervention after we rebooted the client server. My main question centers around why the process seemed to stay hung on the one client. Support's response was to check netstat and see if a TCP connection had been established (which I failed to do before the client was rebooted). Apparently, as long as there is an active TCP connection established, the client will not timeout whether the client is passing data or not. I will be discussing this with support some more tomorrow.
I just noticed that I ignored the fact that saveset All was failing too - this makes my previous post useless.
If you had in group details displayed saveset All that means that savefs didn't yet "resolved" file systems to backup on that host (that usually means some kind of trouble with the box).
As for TCP part, I agree that connection will remain established until client sends close, but then what is the point of inactivity timeout? I believe the problem here was that once savefs reports back what file systems will be backed up they get associated nsrmmd process and inactivity timeout then get's applied to them. If there is no session - nothing happens. Now, I'm quite sure there has to be mechanism for savefs too (otherwise retries would not apply to it). Not sure if TCP state is the one for that. If yes then obviously if you have TCP established state connection stuck it will never end and as consequence... but you better check that with support - a small test will easily tell you if that is the case or not.
ble1
6 Operator
•
14354 Posts
•
56186 Points
182
0
Posted July 17th, 2006 12:00