Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Netbackup request demon services not staying up

Created: 04 Oct 2012 | 6 comments

We are in the middle of upgrading to 7.5. when we bring up netbackup services on the new master server for some reason netbackup request demon services will start but will not stay up. This causes other service to also stop

we have looked at this technote: http://www.symantec.com/business/support/index?page=content&id=TECH23081 but nothing.

Error in bprd:

15:07:50.658 [1860.2280] <16> running_as_a_master_server: Running on an inactive node of a cluster.

15:07:50.658 [1860.2280] <2> bprd: emeanbumaster is not the primary server emeanbumaster...exiting

15:08:28.097 [6796.6812] <2> bprd: Created terminate event:"Global\NetBackup Terminate Event, pid: 6796"

15:08:28.097 [6796.6812] <2> bprd: Created suspend event:"Global\NetBackup Suspend Event, pid: 6796"

15:08:28.112 [6796.6812] <2> bprd: INITIATING bprd (VERBOSE = 5): NetBackup 7.0 2010070800 on emeanbumaster

15:08:28.112 [6796.6812] <2> bprd: Now initializing logging for libcorbaobj

15:08:28.112 [6796.6812] <2> bprd: the request timeout value is 300 seconds

15:08:28.112 [6796.6812] <2> bprd: commandline: "C:\Program Files\Veritas\NetBackup\bin\bprd.exe"

15:08:28.128 [6796.6812] <2> bprd: initiate dbm daemon...

15:08:33.191 [6796.6812] <2> ConnectionCache::connectAndCache: Acquiring new connection for host emeanbumaster, query type 98

15:08:33.191 [6796.6812] <2> ParseConfigExA: Unknown configuration option on line 198: OpsCenterREG = -1

15:08:33.191 [6796.6812] <2> parseNetspec: ../../libvlibs/nbconf.c.1567: vnet_inet_pton fails, assuming hostname: 0 0 0x00000000

15:08:33.191 [6796.6812] <2> vnet_pcache_init_table: ../../libvlibs/vnet_private.c.240: 0: starting cache size: 200 0x000000c8

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1259: 0: found in file cache name: emeanbumaster

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1260: 0: found in file cache service: NULL

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1259: 0: found in file cache name: emeanbumaster

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1260: 0: found in file cache service: veritas_pbx

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1259: 0: found in file cache name: 10.244.198.70

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1260: 0: found in file cache service: NULL

15:08:33.191 [6796.6812] <2> get_pref_netconnection: ../../libvlibs/vnet_addrinfo.c.3951: 0: Local [strong] check, using interface : ANY

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1259: 0: found in file cache name: emeanbumaster

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1260: 0: found in file cache service: vnetd

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1121: 0: found in cache name: 10.244.198.70

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1122: 0: found in cache service: NULL

15:08:33.191 [6796.6812] <2> get_pref_netconnection: ../../libvlibs/vnet_addrinfo.c.3951: 0: Local [strong] check, using interface : ANY

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1259: 0: found in file cache name: emeanbumaster

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1260: 0: found in file cache service: bpdbm

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1121: 0: found in cache name: 10.244.198.70

15:08:33.191 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1122: 0: found in cache service: NULL

15:08:33.191 [6796.6812] <2> get_pref_netconnection: ../../libvlibs/vnet_addrinfo.c.3951: 0: Local [strong] check, using interface : ANY

15:08:33.191 [6796.6812] <2> vnet_async_connect: ../../libvlibs/vnet_connect.c.1140: 0: connect in progress: 1 0x00000001

15:08:33.206 [6796.6812] <2> vnet_pbxConnect: pbxConnectEx Succeeded

15:08:33.206 [6796.6812] <2> do_pbx_service: ../../libvlibs/vnet_connect.c.1724: 0: via PBX: bpdbm CONNECT FROM 10.244.198.67.53228 TO 10.244.198.70.1556 fd = 768

15:08:33.206 [6796.6812] <2> vnet_async_connect: ../../libvlibs/vnet_connect.c.1307: 0: connect: async CONNECT FROM 10.244.198.67.53228 TO 10.244.198.70.1556 fd = 768

15:08:33.206 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1121: 0: found in cache name: emeanbumaster

15:08:33.206 [6796.6812] <2> vnet_cached_getaddrinfo: ../../libvlibs/vnet_addrinfo.c.1122: 0: found in cache service: NULL

15:08:33.206 [6796.6812] <2> logconnections: BPDBM CONNECT FROM 10.244.198.67.53228 TO 10.244.198.70.1556 fd = 768

15:08:33.206 [6796.6812] <2> vnet_check_vxss_client_magic_with_info: ../../libvlibs/vnet_vxss_helper.c.878: 0: Ignoring VxSS authentication: 2 0x00000002

15:08:33.206 [6796.6812] <2> db_end: Need to collect reply

15:08:33.456 [6796.6812] <2> bprd: dbm daemon is alive...

15:08:33.472 [6796.6812] <2> bprd: lock file fd = 788

15:08:33.472 [6796.6812] <16> running_as_a_master_server: Running on an inactive node of a cluster.

15:08:33.472 [6796.6812] <2> bprd: emeanbumaster is not the primary server emeanbumaster...exiting

Comments 6 CommentsJump to latest comment

Marianne's picture

This seems to be inactive node of the cluster?

running_as_a_master_server: Running on an inactive node of a cluster.

NBU master server daemons (including bprd) will only run on the active node. 

Have you followed steps in NetBackup Clustered Master Server Administrator's Guide for the upgrade? 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Wale's picture

We were going to have three server in the cluster but now we are only having two. the third TUNNBUMA is still part of the cluster but switched off and has never been the primary node. Netbackup was never installed on the second and third server

Primary node CHENBUMA

Secondary node LONNBUMA

revaroo's picture

In terms of this issue. Identify the node that is the active node, start NetBackup on that node (if it's not already started). You do not want to be starting NetBackup on an inactive node when it's running on an active node.

Wale's picture

Netbackup is only running on the active primary node, it’s not installed or configured on any other server in the cluster.

Marianne's picture

So, you effectively have a one node cluster?

Why would NBU and the Cluster software believe this node is inactive? In what state was the NBU cluster/service group when you started the upgrade? In what state is it now?

Have you gone through the upgrade steps in the Master server cluster manual?

Please locate the installation log and post as attachment?

Please also help us to understand the reference to " the new master server" in your opening post if this is an upgrade?

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

revaroo's picture

eh? Setup your cluster then install NetBackup as a clustered set-up ON BOTH NODES.