Actually the bpbrm IS apparently invoked on the client at the beginning
of the backup based on my read of the details in the Activity Monitor
and my later solution.
As noted in my original posting I was seeing this specifically on RHEL5
clients that used the Master for Media Server. Having dozens of other
clients using the Master I am quite sure it wasn't an issue on the
Master's bpbrm.
Please see the email I sent yesterday marked "RESOLVED". I believe the
issue was caused because the compatibility libraries weren't installed
before the NBU client software. Even though the client install gave no
errors itself that is only one of two differences I noticed between
RHEL5 servers that gave the error and subsequent ones that didn't.
There was another difference that I note in that email but as suggested
there I don't think it was the problem. In fact I can confirm firewall
wasn't the issue because my co-worker had installed a RHEL5 that was
giving the same error but he had NOT done the firewall setup for that
client which I had done for the one initially described in my first
email. On reinstalling there after verifying the compatibility library
(comapt-libstdc++-296 package) was in place it too no longer gave the
error.
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
mojomagix
Sent: Thursday, March 06, 2008 11:14 PM
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Could not read logging configuration file
Hi Jeff.
Is this a single master/media server or do you have multiple media
servers? If the latter, is this error isolated to clients that are
backed up by a particular media server? The reason I ask is that bpbrm
is a process that runs on a media server, not a client. So, if the
media server is the common point of failure (common point of the error
message) it would make sense that your colleague got the same message.
Also, bpbrm is a "legacy" process. There are a lot of things going on
under the covers, but the nblog.conf file is a configuration file for
"unified" (NBU 6.0 and above) processes. If nblog.conf is truly the
problem, it's interesting that a legacy process is trying to read a
unified configuration file.
It's very surprising that either /opt/openv/logs or usr/openv/logs
doesn't exist. What version of Netbackup is involved?
+----------------------------------------------------------------------
|This was sent by mojomagix AT yahoo DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
