Re: [Networker] 7.4.5 nsrck hangs
2009-09-04 17:15:08
When I remove a client, I also move the client index to a different
directory. Once my advertised retention time is up, I remove any
remaining media index entries for those clients from the volumes that
are onsite. The only remaining entries will be for the DR volumes
that are offsite. I wish NetWorker had a "NUKE CLIENT" option in the
NMC that would totally cleanup after a client.
I guess it is the "nsrim -X", which kicks off a "nsrck -X" at the
end, that hangs. Issuing a "nsrck -X" from the command line only
picks up the defined clients ...
Working with EMC support is very frustrating. Triple that when you
tell them you aren't allowed to do "webex" ...
So I guess I will just go through and create the dead clients ...
At 3:36 PM -0500 9/4/09, Tim Mooney wrote:
In regard to: Re: [Networker] 7.4.5 nsrck hangs, Roberta Gold said (at...:
Does EMC intend to fix this? Or is this considered bad
house-keeping on our part?
NetWorker has allowed old client indexes to be kept around since the early
days of the product. If they're going to change the behavior now, you
would think that it would warrant a mention in the release notes.
Also, when you delete a client, NetWorker doesn't delete the client file
index -- it doesn't even prompt you to delete it. It just leaves it. If
that's bad practice, you would think the GUI would prompt you to delete
it.
I really want to keep information on our DR tapes in our media index ...
I could be misunderstanding what's going on, but isn't it the client file
index that nsrck is hanging on, though? There's no reason why you can't
keep the media information in the media index -- it's the actual saveset
contents in the client file index that's triggering the issue.
If you have index savesets for your older, deleted clients on tape
somewhere, then it should be trivial to pull them back if you ever need
them. You should be able to safely remove the client file index directories
for old clients that are no longer defined.
Should I still open a case with EMC to express my displeasure for
turning what should have continued to be ignorable warnings to something
requiring immediate attention?
Depends on what your frustration level is. As Francis said in an earlier
email, lately it seems to be a real fight just to get EMC to acknowledge
that something even is a problem. Then the fight to get a fix begins.
Tim
--
Tim Mooney Tim.Mooney AT ndsu DOT
edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
To sign off this list, send email to listserv AT listserv.temple DOT edu
and type "signoff networker" in the body of the email. Please write
to networker-request AT listserv.temple DOT edu if you have any problems
with this list. You can access the archives at
http://*listserv.temple.edu/archives/networker.html or
via RSS at http://*listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--
Roberta Gold
Lawrence Livermore National Laboratory
Integrated Computing and Communications
HPSD - Security Technologies Group
gold11 AT llnl DOT gov
(925) 422-0167
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|