Thanks for the response (sorry for the delay in my reply here).
As it turns out, if I wait long enough, typically 45 minutes to an hour,
nsrindexd and nsrmmdbd eventually start and things look normal enough. However,
I cannot figure out why they're taking that long to start. No relevant log
entries, etc. It's not that those two daemons are spawned early and chug for a
while; they just don't launch at all until much later. Apparently nsrd just
isn't spawning them until after a long while... ??
I thought it might be (some of) the licenses causing the delay, so I deleted
every one but the base enabler when it was down using nsradmin. No difference.
Well, one difference - When it came back up after an hour, it said the server
was disabled and needed an enabler update. However, everything appeared to be
running and all the enablers showed current (eval but future) expiration dates.
Who knows; this is really weird. I'm recovering /nsr again from my tar tape to
test some more.
I've been told by Sun that the "approved" method is to mmrecov and go from
there, which indeed is a good method. However, last time I did that (during a
server upgrade) it took a couple of hours at least to recover the GBs of
indexes after running mmrecov, despite Sun's assertion that it only takes 10 or
15 minutes. We're looking at a finite number of contiguous hours for a test in
which this procedure will be used, so several hours of index recovery is not a
viable option. Hence my interest in making this previously good procedure work.
Thanks for the info.
P.S. - I'm out all next week, so if I don't reply to anyone's post, please
understand. :-)
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
|
