Unable to bind tcp/ip socket: Address already in use

Assuming AIX….

What port number are you trying to use?  If the port number is too low, it may be a system process that is using it or you could be using a port number in the ephemeral range.  The following command will tell you the ephermal range:

$ no -a | grep tcp | grep eph

      tcp_ephemeral_high = 65535

       tcp_ephemeral_low = 32768

You should try to avoid port numbers in this range as they are basically reserved for other processes.

There are ways to determine if a system process has the port in use.  On AIX you can use ‘lsof’.

Let me know if you have any more questions.

Hope this helps.

Steve

Just looking for clarification…

I haven’t seen this message in a long time, “Unable to bind tcp/ip socket: Address already in use”… I’m assuming that the port is “stuck” since both the vendor and I have reset our interfaces (multiple times and multiple ways). Other than changing the port number, what else can I do from the engine side to resolve this conflict?

Thanks in advance for your input, Mary.

Steve,

Correct me if I’m wrong, but could she do the following

netstat | grep

to get an idea of what is “grabbing” the port?

Ryan

Ryan,

I just tried the netstat on our QA box, looking for a known port, and it didn’t return any information.

The ‘lsof’ will return the pid of the process using the port number and then it’s just a matter of ‘ps -ef | grep pid’ and killing that particular process.

The netstat may work, but it’s not something that I’ve used very often.

Steve

Steve,

Correct me if I’m wrong, but could she do the following

netstat | grep

to get an idea of what is “grabbing” the port?

Ryan

The ‘too many open files’ error is related to the max number of open file handles that the ‘hci’ user can have at any one time.  This is defined in the nofiles(descriptors) (run ‘ulimit -a’ from the cmd prompt).  Each time a thread attempts to establish a connection and fails, it uses a file handle.  Unfortunately, the file handles are not released again until the process is stopped and restarted.  Once you run out of file handles…..’too many open files’.

If you have ‘lsof’, try the following:

/usr/sbin/lsof | grep portNumber

If the port is still being used by another process, it will return something like this:

hciengine  749744      hci   24u  IPv4  0xf10000f30506db58                0t0    TCP hostName:44688->172.24.201.192:61296 (ESTABL

ISHED)

You can then grep on the pid (749744) to determine what is using your port number.  Most of the time it is another CL process.  Other times it may be the monitor daemon or lock manager.

Let me know what you find out.  I’d be interested in knowing.

Steve

Thanks Steve…

Sorry I forgot to add… we are on AIX 5.2/CL5.3.2. What is baffling me is that this port has been working for 5+ years, and this morning at 4:43 it had an error, that said “too many files”. I stopped and restarted the engine and now I get the current error message – Unable to bind tcp/ip socket: Address already in use…

I had this problem last week on my Dev system.  I’m running 3.7.1 on Sun Solaris.

If I tried to start the offending thread it would fail with ‘Address already in use’ AND the process would die, taking all my other connections in the process down with it.

netstat -a | grep

returned ESTABLISHED for the VPN Client IP that happened to be running the NetMonitor application.  If I brought the NetMonitor GUI down, verified the port wasn’t in use, I could bring up the thread using the command line.  

Neither Cloverleaf Tech Support or my corporate network Ops could explain what/why this happened.  

I changed the port to resolve.  BTW – the port that I was using was 44140.  I’d be interested if yours was the same or similar range.

The instructions to look at port ranges that Steve provided didn’t work for Solaris.

Traci Zee

770.844.9242

I don’t know if this applies to Solaris as well, but the default ephemeral port range on AIX is 32768 to 65535.  Any port number in this range is subject to use by OS processes (i.e., CL engine, monitord, etc.).  

If this is the case, the only 2 options that I know of are:

1.  Change the ephemeral range.  (not really advised)

2.  Change the client to a different port number outside the range.

This should only apply to inbound connections to your system.

Hope this helps.

Steve

I had this problem last week on my Dev system.