What does this message indicate? ERR – could not write progress status message to the NAME socket

Article:TECH182435  |  Created: 2012-02-27  |  Updated: 2013-10-24  |  Article URL http://www.symantec.com/docs/TECH182435
Article Type
Technical Solution


Environment

Issue



This entry has become much more prevalent within the NetBackup debug logs since NetBackup 7.1.  Should it be of concern to the reader?


Error



This bpdbsbora debug log shows several remote writes to place the ‘INF - …’ entries into a progress file.  The ‘ERR – ‘ entries are logged because this process does not have a NAME socket connection to bpbrm at the time.

 

19:16:29.587 [3768] <4> dbc_Write_To_Progress_Log: entering

19:16:29.588 [3768] <4> dbc_RemoteWriteFile: myhost root 76 /usr/openv/netbackup/logs/user_ops/dbext/oracle/progress.1330218989.3768.log a 49 INF - Begin progress logging for process: (3768)

19:16:29.699 [3768] <2> logconnections: BPRD CONNECT FROM 1.1.1.1.2997 TO 1.1.1.1.13724 fd = 5

... error following first [successful] update of progress file ...

19:16:30.021 [3768] <16> writeToServer: ERR - send() to server on socket failed: Bad file number (9)

19:16:30.021 [3768] <16> dbc_RemoteWriteFile: ERR - could not write progress status message to the NAME socket

19:16:30.021 [3768] <4> dbc_RemoteWriteFile: INF - RemoteWriteFile status = 0

... snip ...

19:16:30.051 [3768] <4> dbc_Write_To_Progress_Log: entering

19:16:30.051 [3768] <4> dbc_RemoteWriteFile: myhost root 76 /usr/openv/netbackup/logs/user_ops/dbext/oracle/progress.1330218989.3768.log a 40 INF - Starting Oracle Recovery Manager.

19:16:30.061 [3768] <2> logconnections: BPRD CONNECT FROM 1.1.1.1.2958 TO 1.1.1.1.1556 fd = 5

... error following second [successful] update of progress file ...

19:16:30.608 [3768] <16> writeToServer: ERR - send() to server on socket failed: Bad file number (9)

19:16:30.608 [3768] <16> dbc_RemoteWriteFile: ERR - could not write progress status message to the NAME socket

19:16:30.608 [3768] <4> dbc_RemoteWriteFile: INF - RemoteWriteFile status = 0

 

Notice that the progress file (progress.1330218989.3768.log) shows that all of the updates were successful and the backup continued onward to eventual success.

 

INF - Begin progress logging for process: (3768)

INF - Starting Oracle Recovery Manager.

INF - Using: /db/oracle/oracle102/bin/rman

INF - Connection info: target / nocatalog

INF - Start of Recovery Manager input.

...snip...

 

Similar behavior can be seen in the dbclient debug log during SQL-Server backup and restore.

 

10:00:11.731 [8080.4204] <4> dbc_RemoteWriteFile: DAPBKP01 root 37 logs/mssql_backup_failures/072211.rpt a 1

10:00:11.754 [8080.4204] <2> logconnections: BPRD CONNECT FROM 1.1.1.3.57956 TO 1.1.1.1.1556 fd = 636

10:00:11.971 [8080.4204] <16> writeToServer: ERR - send() to server on socket failed:

10:00:11.971 [8080.4204] <16> dbc_RemoteWriteFile: ERR - could not write progress status message to the NAME socket

10:00:11.971 [8080.4204] <4> dbc_RemoteWriteFile: INF - RemoteWriteFile status = 0

 


Environment



NetBackup 7.1 – 7.5


Cause



Whether this log entry is of concern depends on the context in which it occurs.

 

1)     As part of getting additional entries into the Job Details in NetBackup 7.1, a logging function was updated to send duplicate copies of the entries that are being sent to bprd to the bpbrm process via the NAME socket.  Unfortunately, the function is called from several code sections that do not have a NAME socket connection at the time. 

As a result, this may cause the NetBackup debug logs for various database extensions, including NetBackup for Oracle and NetBackup for SQL-Server, to contain some entries that are non-fatal to the operation in progress but distracting to anyone who reads the log files.

Notice that the RemoteWriteFile function completes with status 0 indicating that the error was not fatal.

 

2)     The same entries may be logged if the bpbrm process on the media server exits before the client process tries to utilize the socket.  But then the RemoteWriteFile status will be non-zero.

3)     The same entries may be logged if the TCP connection between the client process and bptm process suffers a fault in the networking layers below the application layer.  Again, the RemoteWriteFile status will be non-zero.

 


Solution



These messages in the debug logs can be ignored if the cause is #1, as described above, and the RemoteWriteFile completes with status 0.

 

For cause #2, the entry can also be ignored. 

 

For cause #3, investigated more closely to see if it relates to any problems that are occurring with respect to the backup or restore operation that is in progress.

 

The misleading entries created by cause #1 will be removed in a future version of NetBackup.

 

Symantec Corporation has acknowledged that the above-mentioned issue (E-Track 2701671) is present in the current version(s) of the product(s) mentioned in this article.  Symantec Corporation is committed to product quality and satisfied customers.  This issue was scheduled to be addressed in a future maintenance release or update of the product.

 

Please note that Symantec Corporation reserves the right to remove any fix from a targeted release if it does not pass quality assurance tests or introduces new risks to overall code stability.  Symantec Corporation's plans are subject to change and any action taken by you based on the above information or your reliance upon the above information is made at your own risk.

 


Supplemental Materials

SourceETrack
Value2701671
Description

7.1, dbc_RemoteWriteFile utilizes NAME socket that does not always exist



Article URL http://www.symantec.com/docs/TECH182435


Terms of use for this information are found in Legal Notices