cancel
Showing results for 
Search instead for 
Did you mean: 

Error bptm system call failed - Connection reset by peer (at ../child.c.1280)

DoubleP
Level 5

Hello, for the last few weeks we are seeing an upswing of Netbackup jobs failing with statuses of 42 and 13:  - Error bptm system call failed - Connection reset by peer (at ../child.c.1280)
- Error bptm unable to perform read from client socket, connection may have been broken
- Info bptm EXITING with status 42 <----------
- Error bpbrm (pid=18639) could not send server status message

Our Netbackup masters are linux (8.0). The failed jobs are on Windows boxes. Sometimes the reruns will be successful. They do not share the same media or storage servers. There are certain jobs that almost consistently experience these errors, but even these handful of jobs will eventually be successful.

We haven't seen any patterns based on when these jobs run, etc.

1 ACCEPTED SOLUTION

Accepted Solutions

Since the failures are inconsistent, I'm wondering if the problems could be due to our secondary IPs. All our NB clients, masters, media servers and appliances have two IPs. One is the core , the other (which we call the "tan" because when it was first devised, things were on tape) is on a secondary NIC. 

It was set up this way because we have backups running 24/7, not just during off hours. With the backups running on the secondary network, we don't get any bandwith issues on production.

A few weeks ago, we had to reboot one of our three master servers to resolve an issue with that master's admin console. The tan network didn't start up. After this was discovered, we had our System Admin group re-enable the tan.

We started expriencing the current issues a week or so after the re-enabling of the tan. I'm wondering if this is the root cause. Any ideas?

View solution in original post

3 REPLIES 3

Lowell_Palecek
Level 6
Employee

During backup, bpbkar32.exe sends the data over a socket to bptm.

Look at the bpbkar logs on the client. (Make sure the bpbkar folder exists and set the logging levels up in the client host properties. For Windows clients, it's important to set the logging under Windows Clients / Client Settings to 2 in addition to setting the main logging level.)

Look also in the Windows application event log in case bpbkar32 is crashing.

Since the failures are inconsistent, I'm wondering if the problems could be due to our secondary IPs. All our NB clients, masters, media servers and appliances have two IPs. One is the core , the other (which we call the "tan" because when it was first devised, things were on tape) is on a secondary NIC. 

It was set up this way because we have backups running 24/7, not just during off hours. With the backups running on the secondary network, we don't get any bandwith issues on production.

A few weeks ago, we had to reboot one of our three master servers to resolve an issue with that master's admin console. The tan network didn't start up. After this was discovered, we had our System Admin group re-enable the tan.

We started expriencing the current issues a week or so after the re-enabling of the tan. I'm wondering if this is the root cause. Any deas?

Since the failures are inconsistent, I'm wondering if the problems could be due to our secondary IPs. All our NB clients, masters, media servers and appliances have two IPs. One is the core , the other (which we call the "tan" because when it was first devised, things were on tape) is on a secondary NIC. 

It was set up this way because we have backups running 24/7, not just during off hours. With the backups running on the secondary network, we don't get any bandwith issues on production.

A few weeks ago, we had to reboot one of our three master servers to resolve an issue with that master's admin console. The tan network didn't start up. After this was discovered, we had our System Admin group re-enable the tan.

We started expriencing the current issues a week or so after the re-enabling of the tan. I'm wondering if this is the root cause. Any ideas?