Forum Discussion
A perfect oppotunity to repost this ...
I describe the 23/24/25 status codes as follows:
RC=23: Server A sent a IP packet to valid server B, and is waiting for a response packet. It fails to get the response packet within the TIMEOUT window and raises the rc=23.
RC=25: Server A tried to sent IP packet to invalid server B. No connection made so Server A sets rc=25.
RC=24: Server A sends packet to server B and get a response within the TIMEOUT window. But something happens that drops connection between them.
I make an analogy of this communication environment using phone calls:
Person on Phone A calls to phone number B, which connects and they leave a voice mail to call them back. They wait for a call back that does not come and after a specified time, they quit. RC=23.
Person A calls phone number for what he thinks is a valid Phone B. The call does not go through and they hear the message "The number you have dialed is not a working number". RC=25.
Person A calls Person B, they call is picked up but the line connection somehow gets dropped unexpectedly.while communications is in progress. RC=24.
All of these are communication errors of some kind.
For RC=25, the source server may have the wrong target server name in its environment or an invalid/wrong IP address for the target server.
For RC=23, A can talk to B but B cannot talk to A. Could be a source server it does not recognize or it is using the wrong IP address to respond to. Possible bad host name to IP resolution.
RC 24: The toughest of the bunch. A and B know each other correctly. They just can't keep the call going.
I would give credit to my collegue for the excellent analogy, if only I could remember who it was ...
mph999 wrote:
I would give credit to my collegue for the excellent analogy, if only I could remember who it was ...
I bookmarked it:
Jaime Vazques : https://vox.veritas.com/t5/NetBackup/Error-23/m-p/738836#M201891
Sadly one of the casualties during the Symantec/Veritas split ....
- Tousif6 years agoLevel 6
Yes.. :(
- liuyl6 years agoLevel 6
For so long time, I almost forget to post the good answer that I eventually found from the OS layer!
1) /usr/include/asm-generic/errno-base.h:
#define EINTR 4 /* Interrupted system call */
#define EMFILE 24 /* Too many open files */
2) /usr/include/scsi/sg.h:
/* Use negative values to flag difference from original sg_header structure. */
#define SG_DXFER_NONE -1 /* e.g. a SCSI Test Unit Ready command */
#define SG_DXFER_TO_DEV -2 /* e.g. a SCSI WRITE command */
#define SG_DXFER_FROM_DEV -3 /* e.g. a SCSI READ command */- mph9996 years agoLevel 6
Well done finding that information.
20:07:59.674 [17491] <3> send_command: TLD(1) [17491] unable to read ack from tldcd, Interrupted system call (4), stat = -2
From the error, and your findings it suggets that the interuppted system call hapens when we try and send somrthing to the robot, as opposed to reading some response ... eg. scsi mode sense, if scsi move_medium
So, it is interesting, but not groundbreaking in terms of what is wrong.
Is the issue intermittant, or happeneing 100% of the time.
Related Content
- 6 years ago
- 2 years ago