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

The system function gethostbyname() failed to find the client's host name.

Created: 31 Jan 2013 | 17 comments

Group of backups failing.  All point at the same cluster.  Policies use virtual names.  NSLookup to virtual names fail but the FQDN succeed.  Pings to both from Master work.  NSLookup and ping from client work as well.  Can connect to all clients in Host Properties.  Verfied that correct entries are in the hosts files.  Status is 48.  Followed the recommendations in the troubleshooter in Activity Monitor and it didn't make a difference.

Windows 2008

NBU 7.1

Comments 17 CommentsJump to latest comment

revaroo's picture

What type of policies, is it multiple clients? Are you specifying ALL_LOCAL_DRIVES in the file selection?

On the master and media server run:

bpclntcmd -hn <client_name>

bpclntcmd -ip <ip_of client>   

on the client

bpclntcmd -pn

bpclntcmd -self

bpclntcmd -ip <ip_of_client>

post the results

HankHill's picture

Master/media

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn uat-sql-10
host uat-sql-10: uat-sql-10 at 172.22.23.204
aliases:     uat-sql-10     172.22.23.204

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn uat-sql-10.uat.shlroot.local
host uat-sql-10.uat.shlroot.local: uat-sql-10.uat.shlroot.local at 172.22.23.204
aliases:     uat-sql-10.uat.shlroot.local     172.22.23.204

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 172.22.23.204
host 172.22.23.204: uat-sql-10.uat.shlroot.local at 172.22.23.204
aliases:     uat-sql-10.uat.shlroot.local     172.22.23.204

Client

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn us-bak-01
host us-bak-01: us-bak-01 at 172.26.1.80
aliases:     us-bak-01     172.26.1.80

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn us-bak-01.shl.prod
host us-bak-01.shl.prod: us-bak-01.shl.prod at 172.26.1.80
aliases:     us-bak-01.shl.prod     172.26.1.80

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 172.26.1.80
host 172.26.1.80: us-bak-01.shl.prod at 172.26.1.80
aliases:     us-bak-01.shl.prod     172.26.1.80

RamNagalla's picture

you are missing below output from client, that also required,

bpclntcmd -pn

bpclntcmd -self

bpclntcmd -ip <ip_of_client>

and also provide the bpcd log of client.

HankHill's picture

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -pn
expecting response from server us-bak-01.shl.prod
UAT-SQL-01A *NULL* 172.22.23.61 54295

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -self
gethostname() returned: uat-sql-01a.uat.shlroot.local
host uat-sql-01a.uat.shlroot.local: uat-sql-01a.uat.shlroot.local at 169.254.1.231
host uat-sql-01a.uat.shlroot.local: uat-sql-01a.uat.shlroot.local at 172.22.23.61
aliases:     uat-sql-01a.uat.shlroot.local     172.22.23.61     169.254.1.231

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 172.22.23.204
host 172.22.23.204: UAT-SQL-10 at 172.22.23.204
aliases:     UAT-SQL-10     172.22.23.204

revaroo's picture

Completely different IP addresses, I assume you have another NIC configured with the IP the master/media resolves?

What about that bpcd log from the client?

HankHill's picture

There is no bpcd log on the client, that I can find.  Here are all the IP addresses on the client.  Hosts file on the master/media for name resolution. 

C:\Program Files\Veritas\NetBackup\bin>ipconfig

Windows IP Configuration

Ethernet adapter CNA TEAM:

   Connection-specific DNS Suffix  . : uat.shlroot.local
   IPv4 Address. . . . . . . . . . . : 172.22.23.61
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.48
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.49
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.52
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.60
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.64
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.65
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.66
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.67
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.68
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.69
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.200
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.201
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.202
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.203
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 172.22.23.204
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 172.22.23.254

Ethernet adapter Local Area Connection* 9:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::2d19:c54c:df80:7b66%19
   IPv4 Address. . . . . . . . . . . : 169.254.1.231
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Tunnel adapter isatap.{63355E4E-25D9-444F-ADC2-CAD42C308F0D}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.uat.shlroot.local:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : uat.shlroot.local

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

C:\Program Files\Veritas\NetBackup\bin>

RamNagalla's picture

if my understading is correct.

UAT-SQL-01A is a node

UAT-SQL-01 is a cluster.

please have this below entry in your etc/hosts file of node UAT-SQL-01A. 

172.22.23.204  UAT-SQL-10   

they try again.

RamNagalla's picture
18:05:32.613 [25936.23980] <2> logconnections: BPCD ACCEPT FROM 10.13.32.154.61570 TO 172.22.23.204.1556 fd = 808
18:05:32.629 [25936.23980] <2> bpcd peer_hostname: Connection from host alp-bak-02.shl.shlroot.local (10.13.32.154) port 61570
18:05:32.629 [25936.23980] <2> bpcd valid_server: comparing us-bak-01.shl.prod and alp-bak-02.shl.shlroot.local
18:05:32.629 [25936.23980] <4> bpcd valid_server: alp-bak-02.shl.shlroot.local is not a master server
18:05:32.629 [25936.23980] <16> bpcd valid_server: alp-bak-02.shl.shlroot.local is not a media server either

1)so first add the server alp-bak-02.shl.shlroot.local in clients registory.

2) add the below entry in master hosts file also.

172.22.23.204  UAT-SQL-10   

Tomer Gurantz's picture

When Nagalla writes "add the server alp-bak-02.shl.shlroot.local in clients registory" I think he means is that the master server name isn't setup correclty for the client (aka the client's host properties > Servers shows this)... the registry is where it is stored on Windows (bp.conf on UNIX), if you cannot set it manually in the host properties.

Senior Principal Technical Education Consultant with Symantec Corporation

HankHill's picture

I'm not sure why the ALP server is even in there.  Nothing writes to that server, it's used only for duplication of specific backups.  Why is the alp-bak-02 server even involved in this backup? 

Major concern about this is due to some major network problems we've had recently between two sites.  If the UAT backups are the culprit, then I need to know why it's looking for a server that it shouldn't be talking to.

Marianne's picture

Check Storage Unit specified in backup policy. 

Master will send backup instruction to the media server associated with STU.
Also check for possible STU override in the backup schedules.

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

HankHill's picture

Storage unit in policy points to us-bak-01.

Nothing in the overrides in any of the policies throwing this error.

Marianne's picture

Somewhere someone has kicked off a job/connection request using host alp-bak-02.shl.shlroot.local (10.13.32.154) as media server.

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

HankHill's picture

No policies use that server.  No SLPs use that server.  The only thing I have ever used that server to do is read old backup tapes.