Status 25: "Cannot connect on socket"

Article:TECH29790  |  Created: 2005-01-11  |  Updated: 2013-10-30  |  Article URL http://www.symantec.com/docs/TECH29790
Article Type
Technical Solution


Environment

Issue



Status 25: "Cannot connect on socket"


Error



25 cannot connect on socket


Solution



Overview:
When performing backups or restores, socket errors are being produced.

Troubleshooting:
Please follow all steps within the VERITAS NetBackup (tm) Troubleshooting Guide or the NetBackup Troubleshooter within the Activity Monitor for this status code before continuing.

Please confirm hardware and software compatibility before continuing. A list of compatible hardware and software may be obtained within the VERITAS NetBackup Release Notes or on the VERITAS Support Web site.

If the above does not resolve the issue, please continue.


1.  Status code 25 caused by no open sockets on the Master/Media Server

Please look for the following log messages:

Master Log Files:

Media Server Log Files:
bpbrm:
02:44:21.877 [1092.2944] <2> nb_bind_on_port_addr: port 4998 unavailable
02:44:21.877 [1092.2944] <2> nb_getsockconnected: cannot connect() to MasterServer, Only one usage of each socket address (protocol/network address/port) is normally permitted.
02:44:21.877 [1092.2944] <2> db_begin: nb_getsockconnected() failed: Only one usage of each socket address (protocol/network address/port) is normally permitted.  (10048)
02:44:21.877 [1092.2944] <2> db_FLISTsend: db_begin() failed: cannot connect on socket
02:44:21.877 [1092.2944] <16> bpbrm handle_backup: db_FLISTsend failed: cannot connect on socket (25)
02:44:21.877 [1092.2944] <2> nb_bind_on_port_addr: port 4999 unavailable

Client Log Files:

Resolution:
A socket in a TIME_WAIT state may be made available sooner by reducing the tcp_time_wait_interval parameter. The default for this parameter on Solaris is 240000 milliseconds or 4 minutes. The default for Hewlett-Packard (HP) is a value of 60000 milliseconds or 1 minute. The default on AIX is set in increments of 15 seconds. The default value is 1 or 15 seconds. On AIX, this is the lowest it may be set to. VERITAS has found that the tcp_time_wait_interval can often be set between 30 to 60 second with no adverse effects. However, customers should adjust the TCP_TIME_WAIT_INTERVAL in increments; lowering the value until backups no longer fail with the status 25 but no lower than 10 seconds.  Be extremely cautious going lower than 30 seconds because many applications may not have enough time to clean up data packets after application request to close the TCP port.

The value of this parameter may be obtained and changed by running the following command:

For Solaris 2.6 or earlier:

#ndd -get /dev/tcp tcp_close_wait_interval
#240000
 
If this value is higher than 60000 or lower than 30000, use the following command:

#ndd -set /dev/tcp tcp_close_wait_interval 60000 (60 seconds)


For Solaris 7 or later:

#ndd -get /dev/tcp tcp_time_wait_interval
#240000
 
If this value is higher than 60000 or lower than 30000, use the following command:

#ndd -set /dev/tcp tcp_time_wait_interval 60000 (60 seconds)


The ndd command makes the change immediately, without a need for a reboot. This setting will go back to default after a reboot. To make the change permanent, the command can be added to the appropriate TCP/IP startup script. On Solaris, this is /etc/rc2.d/S69inet.

For HP-UX 11, use the following command:

#ndd -get /dev/tcp tcp_time_wait_interval
#60000
 
If this value is higher than 60000 or lower than 30000, use the following command:
#ndd -set /dev/tcp tcp_time_wait_interval 60000 (60 seconds)

Note: The equivalent command on HP-UX 10.x is nettune instead of ndd.

The ndd command makes the change immediately, without a need for a reboot. This setting will go back to default after a reboot. To make the change permanent, the command can be added to the appropriate TCP/IP startup script. On HP-UX 11, see /etc/rc.config.d/nddconf for examples on how to set it.

It is not necessary to change the tcp_timewait default parameter on AIX, but for reference:

To display the value, enter:
#no -a
or
#no -o tcp_timewait

To change the value, enter:
#no -o tcp_timewait=4 (4 x 15 seconds = 60 seconds)

Where <value> is a positive integer, with each increment representing 15 seconds. The default <value> is 1 for 15 seconds which is too short for most applications. The change takes effect immediately. The change is effective until the next boot. A permanent change is made by adding the command to /etc/rc.net.

Windows System:
Ports in TIME_WAIT will be seen by running netstat -a from a command prompt on the master or media server. This can be an indication that ports are not being released quickly enough to allow another connection on that port. The registry setting TcpTimedWaitDelay can be added to reduce the time a port will stay in this state.

1. Go to Start | Run, type regedit, and click OK
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Highlight the Parameters key, right-click and select New | DWORD Value
4. Type the name TcpTimedWaitDelay
5. Double-click TcpTimedWaitDelay and enter a decimal value of 60
By default, this value is 240 seconds (4 minutes). It is recommended that this be changed to a value between 30-60 (seconds) in decimal, to decrease the wait time before a port becomes available.

Description:
This parameter determines the length of time that a connection will stay in the TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state, as by RFC the value should be twice the maximum segment lifetime on the network. See RFC793 for further details.
 
The TIME_WAIT state takes place after the final TCP handshake (from the 4-way TCP handshake during a TCP connection shutdown), in this state, the process that initiated the close is doing a time wait for a set amount of seconds (or milliseconds) before completely closing the port and allowing the operating system to re-claim it for future use.  Setting this too high will have the process initiating the TCP shutdown to wait longer and therefore holding the TCP port and other resources to maintain the TCP port longer before the system can reclaim.  This could cause the system to potentially run low on resources when there are too many TCP connections.  Setting this too low could pre-maturely shutdown the TCP port before all the TCP data packets could arrive. 
 

Supplemental Materials

Value25
Description

cannot connect on socket



Legacy ID



264886


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


Terms of use for this information are found in Legal Notices