ARB Event ID 11

Last Updated : Jan 05, 2021 |
Alarm level

WRN

Alarm text

Cannot create receive socket.

Cannot create transmit socket.

Cannot bind receive socket.

Cannot (re)bind send socket.

Cause

Since the Arbiter continuously attempts to create or bind the socket, the problem might resolve itself. Once resolved, the Arbiter can send and receive every Interarbiter link with no subsequent error messages in the trace log.

Proposed Solution

Procedure

  1. To examine the alarm log to distinguish between a bind or create problem or a send or receive problem:
    1. From the Web interface:

      1. Select Current Alarms and the appropriate alarm.

      2. Select the View System Logs diagnostic.

      3. Select the Logmanager Debug trace.

      4. Specify the Event Range for the appropriate time frame.

      5. Match the cannot create pattern

    2. From the Linux command line, enter almdisplay -v.
  2. Check for completeness and consistency of the hosts and servers.conf files (containing IP addresses of the configured components of the system) located on the servers:
    1. From the web interface select Configure Server.
    2. From the Linux command line, enter:

    more /etc/hostsmore /etc/opt/ecs/servers.conf

    The Arbiter uses port number 1332 for sockets. Enter netstat -a | grep 1332 to check if the alarm is still active. This command displays an output similar to the following:

    upd 0 0<server-name>-cnb:1332 *.*

    upd 0 0<server-name>-cna:1332 *.*

    upd 0 0<server-name>-dup:1332 *.*

  3. If the IP addresses match and there are no alarms for port 1332, manually clear the alarm:
    1. From the Web interface, select Current Alarms and the appropriate alarm, and click Clear.
    2. From the Linux command line, enter almclear -n #id.
  4. If this problem affects call processing or if the problem persists, continue with Step 6. If this problem does not affect call processing or if the problem has resolved, continue only at the convenience of the customer.
  5. Escalate this problem for explicit guidance with Steps 5a through 6.
    1. Enter server to verify that the suspected server is the standby.
    2. If the suspected server is not the standby, enter server -if to force a server interchange. Busyout the standby server from the Linux command line by entering server -b.
    3. Reboot the server (as the standby):

      • From the Web interface, select Shutdown This Server.

      • From the Linux command line, enter

      /sbin/shutdown -r now

  6. If rebooting the standby server does not help or if the problem persists, go to the Avaya Support website at http://support.avaya.com to open a service request.