Failure Code 42 and 14 - Job Failure

[archyis]

Server is on Linux and the client is on windows. The client can ping the server and communication ports are set correctly (default). The job fails at about 8% everytime.

I enabled more detailed logging and the most notable parts included below...
"dtcp_read: TCP - failure: recv socket (372) (TCP 10058: Can't send after socket shutdown)
10:03:38.816 AM: [1000.1564] <16> dtcp_read: TCP - failure: recv socket (372) (TCP 10058: Can't send after socket shutdown)
10:03:39.831 AM: [1000.1564] <16> dtcp_read: TCP - failure: recv socket (372) (TCP 10058: Can't send after socket shutdown)
10:03:40.847 AM: [1000.1564] <16> dtcp_read: TCP - failure: recv socket (372) (TCP 10058: Can't send after socket shutdown)"

Has anyone ran into this before? I am not able to find anything helpful on the symantec site regarding this.

[heada]

Looks like one side has shutdown the TCP connection without notifying the other side.. You could sniff the network and look for the FIN packet to find out which side.

Is this backup taking a long time? If so, is there a timeout value you can increase?

-Aaron

[archyis]

This backup fails quite quickly (usually after about 5 minutes) and ends up getting to about 5-8% completed before failing. All other servers are backing up correctly except for this one.

Unfortunatly I work for a very large company and I am involved on the Windows Team, Server belongs to the Unix Team and then the network team would have to be the ones to run the sniffer. Talk about red tape!

Anyway, I found this article here which is pretty informative and is the same thing as I am getting - [FONT='Calibri','sans-serif']https://forums.symantec.com/syment/board/message?board.id=21&thread.id=5862 [/FONT]

[FONT='Calibri','sans-serif']So I think what I am going to try is uninstalling the Netbackup agent completely and then reinstalling it and updating it to MP3 to see if that fixes it.[/FONT]

[sgabriel62]

Verify your NDD variables at the OS level, If you are failing after 5 minutes, you've run into a contention issue of I would expect validation of files to expire.
Run a check against your Comm and Idle timeout variables, and number of retries as well.
Give me the exact error and I'll go to the support site and dig into the knowledge base.
If the meantime, check your media server, and the media being requested. Perhaps you have run into a bad sector on the tape itself or dust on the tape drive head. Run some queries on the mount requests and see if there is a common fault.
Good luck - let me know

[archyis]

This is the error messages -
02/06/2008 15:48:35 - Error bpdm (pid=24384) system call failed - Connection reset by peer (at child.c.1174)
02/06/2008 15:48:35 - Critical bpbrm (pid=24149) from client %servername%: FTL - tar file write error (10054)
02/06/2008 15:48:35 - Error bpdm (pid=24384) unable to perform read from client socket, connection may have been broken
02/06/2008 15:48:36 - Error bpdm (pid=24347) media manager terminated by parent process
02/06/2008 15:48:38 - Error bpbrm (pid=24149) could not send server status message
02/06/2008 15:48:40 - Warning bpbrm (pid=24149) Could not set linger value on socket. Errno = 22: Invalid argument
02/06/2008 15:48:44 - end writing; write time: 0:01:25

Verify your NDD variables at the OS level, If you are failing after 5 minutes, you've run into a contention issue of I would expect validation of files to expire.
Run a check against your Comm and Idle timeout variables, and number of retries as well.
Give me the exact error and I'll go to the support site and dig into the knowledge base.
If the meantime, check your media server, and the media being requested. Perhaps you have run into a bad sector on the tape itself or dust on the tape drive head. Run some queries on the mount requests and see if there is a common fault.
Good luck - let me know

[archyis]

This is a good troubleshooting guide for this specific problem, although I have done everything short of changing the NIC on the server.
http://ftp.support.veritas.com/pub/s...ver/278568.pdf

I will be changing the NIC on the server tomorrow evening and will post the results.

[archyis]

Ok, so I ended up getting this backup to work without changing the NIC.

The server in question was a Biscom Faxcom Server...before I had thought it was a regular 2003 Windows Server with a fax software installed on it. My company was alread having problems with our disk staging running out of space with other servers which were reporting a 129 disk full error, while this particular one was reporting the error that this thread is about.

So for kicks, I changed the job to backup straight to tape and ran it manually for the one that always failed and WTF it worked.

So I am concluding that this servers is running into the disk full error, while reporting it different since it is a non-standard machine.

[noobie2tsm]

Was the resolution of this confirmed to be disk space?