Can’t bind to the network

If the instance aborts it is possible for the network connections to remain open. Common causes of network connections staying open are the PC application crashing, the PC application not being closed down correctly, and PC not being closed down correctly.

command: netstat -a

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address    Foreign Address    state
 tcp     0      0    Y7026P.sqlconv   FINWAIT
 tcp     0      0    Y7026P.sqlconv   FINWAIT2
 tcp     0      0    Y7026P.telnet          ERIC.3943   ESTABLISHED
 tcp     0      0    Y7026P.telnet          PAUL.1159   ESTABLISHED
 tcp     0      0    Y7026P.telnet          PAUL.1158   ESTABLISHED 
 tcp     0      0         *.writesrv           *.*      LISTEN
 tcp     0      0         *.922                *.*      LISTEN
 tcp     0      0         *.919                *.*      LISTEN

Within the ‘Local Address’ the services that are in use are displayed. These services correspond to those in the sqlhosts file. FINWAIT(2) indicates a network connection that is in the process of closing down. [Note these connections can be used within the same machine].

The connections can also move to this state as a result of an onmode -ky, but an onmonitor close down doesn't cause the problem. A change in functionality means that most versions onmode -kuy can be used, this behaves in the same manner as onmonitor.

These connections can be linked to UNIX processes using the utility ‘lsof’. This is not a part on standard UNIX.

Another Reason

The other reason you would get this message is when using stream pipes (which any Baan system in host mode does) and the server crashes. Sometimes the files in /INFORMIXTMP are left behind. These need to be cleared before attempting to start the engine.

Why does this happen

It's normal for connections to end up in FIN_WAIT_2 when the server is killed. (A good server catches termination signals and cleans up its connections, and a good sysadmin doesn't kill such a server with SIGKILL, so this problem shouldn't exist. But we can't count on such being the case.)

According to the TCP/IP spec a connection in FIN_WAIT_2 that was owned by an application that's gone away will never transition to another state. However, many implementations terminate FIN_WAIT_2 connections that were fully closed locally after 10 minutes and 75 seconds, which is what you're seeing.

A sockets-based TCP server should always set SO_REUSEADDR on the master socket before calling bind, so that it can bind again if there are residual connections in FIN_WAIT_2 or CLOSE_WAIT or whatever.

This is two the most common TCP sockets programming errors. The other is setting SO_LINGER off, which you should never do.

Personal Tools