Informix Error -56

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning

	Value	Symbol
Catalogue text — Socket is already connected	56	EISCONN on BSD
The same condition on Linux	106	EISCONN — Transport endpoint is already connected
Errno 56 on Linux	56	EBADRQC — Invalid request code, STREAMS-era

The BSD socket block runs from -42 to -61 and each member sits 50 higher on Linux.

python3 -c 'import os; print(56, os.strerror(56)); print(106, os.strerror(106))'

What EISCONN Actually Tells You

connect() was called on a socket that is already connected.

That is usually good news reported as a failure, and it is the reason this code is worth a page at all. In the most common route to EISCONN, the connection succeeded — the caller just asked a second time.

The non-blocking connect sequence

A non-blocking connect() does not complete immediately. It returns -1 with EINPROGRESS, and the caller is then expected to wait for the socket to become writable and read SO_ERROR to find out how it turned out:

fcntl(fd, F_SETFL, O_NONBLOCK);
rc = connect(fd, addr, len);               /* -1, EINPROGRESS */

poll(&pfd, 1, timeout);                    /* wait for writability */

int err; socklen_t l = sizeof err;
getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &l);
if (err == 0) { /* connected */ }

The frequent mistake is to call connect() again instead of checking SO_ERROR. Do that and the kernel answers according to where the attempt has got to:

Second connect() returns	Meaning
EALREADY	Still in progress — see -37, whose catalogue text is this symbol
EISCONN	It succeeded. You are connected.
A real error	The attempt failed for that reason

Code that treats any non-zero return from connect() as a failure will therefore tear down a connection that had just been established successfully, and report it as an error. The connection was fine; the completion logic was not.

The other route

sendto() with an explicit destination address on a socket that is already connected also returns EISCONN on some platforms. That is a straightforward programming error rather than a race, and much rarer.

What This Means in Informix

The engine's own connection handling does not produce this in normal operation. A -56 points at code around the instance rather than at the engine:

• A client driver or connection pool with hand-written non-blocking connect logic, retrying connect() rather than checking SO_ERROR. This is the realistic case.
• Retry logic that fires on a timeout which was not actually a failure — the attempt completed while the caller had already decided to try again.
• Custom code in a wrapper, agent or UDR opening its own socket.
• A monitoring or health-check probe with its own connection routine.

The signature is that it appears under load or latency and not at rest. The window between a connection completing and the caller noticing is where this lives, so it surfaces when the network is slow or the host is busy, and is very hard to reproduce deliberately. That intermittency is often misread as a network fault.

Where no custom connection code exists anywhere in the path, treat the value with the suspicion -33 describes — nothing in the engine's ordinary handling produces it.

Common Causes

1. Re-calling connect() to complete a non-blocking connect instead of checking SO_ERROR.
2. A retry firing on a timeout that the connection then beat.
3. Connection-pool code that reuses a socket structure without resetting its state.
4. sendto() with a destination on an already-connected socket.
5. A client library whose connect handling differs from the platform's semantics.

Diagnostic Checks

Confirm the symbol, since errno 56 on Linux is a STREAMS value and unrelated:

python3 -c 'import os; print(56, os.strerror(56)); print(106, os.strerror(106))'

Establish whether the connection actually succeeded. This decides everything, because if it did there is no connectivity problem to investigate:

ss -antp | grep -w <port> | head
onstat -g ses
onstat -g ntu

A session present in onstat -g ses for a connection that was reported as failed is the tell.

Trace the connect sequence. The pattern is unmistakable once visible — EINPROGRESS followed by a second connect() rather than a getsockopt:

strace -f -e trace=connect,poll,select,getsockopt -p <pid> 2>&1 | grep -iE 'EINPROGRESS|EALREADY|EISCONN|SO_ERROR'

connect(9, {...}, 16)  = -1 EINPROGRESS (Operation now in progress)
connect(9, {...}, 16)  = -1 EALREADY (Operation already in progress)
connect(9, {...}, 16)  = -1 EISCONN (Transport endpoint is already connected)

Three connect() calls and no getsockopt for SO_ERROR is the defect, stated plainly.

# Solaris / AIX
truss -f -t connect,getsockopt -p <pid>

Check whether latency is the trigger, since that explains an intermittent pattern:

ss -ti | grep -A1 <address> | head
ping -c 5 <client-or-partner>
tail -300 "$INFORMIXDIR/tmp/online.log"

Identify what is connecting, to find out whether custom code is involved at all:

onstat -g ses
onstat -g dll
ps -ef | grep -E 'agent|monitor|pool' | grep -v grep

Solutions / Resolution

1. Establish whether the connection succeeded before treating this as a failure. In the common case EISCONN means it did, and the fault is in the code reporting it.
2. Fix the completion logic, not the network. A non-blocking connect completes by waiting for writability and reading SO_ERROR — not by calling connect() again. This is the durable fix and it is in the client.
3. Handle EISCONN as success where the code cannot be restructured. Treating it as an error discards a working connection.
4. Handle EALREADY as "still waiting", not as a failure — see -37, whose catalogue text is that symbol.
5. Review retry timing. A retry that fires while the first attempt is still in flight creates this, and shortening timeouts to "fail faster" makes it more likely rather than less.
6. If no custom connection code exists in the path, question the value rather than the network. Nothing in the engine's ordinary handling produces it.

Example

A connection that worked, reported as a failure

$ strace -f -e trace=connect,getsockopt -p 8821 2>&1 | head -4
connect(11, {sa_family=AF_INET, sin_port=htons(9088), ...}, 16) = -1 EINPROGRESS (Operation now in progress)
connect(11, {sa_family=AF_INET, sin_port=htons(9088), ...}, 16) = -1 EALREADY (Operation already in progress)
connect(11, {sa_family=AF_INET, sin_port=htons(9088), ...}, 16) = -1 EISCONN (Transport endpoint is already connected)
close(11)

No getsockopt anywhere. The application starts a non-blocking connect, polls by re-calling connect(), gets told the connection has been established, treats that as an error, and closes it.

$ onstat -g ses | grep -c .

Sessions do appear and disappear on the server side, matching the pattern — the engine accepted connections that the client then discarded. Nothing is wrong with the network or the instance.

Platform Note

Platform	This condition	Errno 56 there means
Linux	errno 106	EBADRQC — STREAMS-era, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 56	this condition

Linux names it Transport endpoint is already connected rather than Socket is already connected. Same condition, different wording — and searching for the catalogue's phrasing on a Linux host will not find it.

Task	Linux	Solaris	AIX
Trace connect	strace -e connect,getsockopt	truss -t connect	truss -t connect
Connection state	ss -antp, ss -ti	netstat -an, pfiles	netstat -Aan

Related Errors / Related Topics

• -57 — Socket is not connected (ENOTCONN, 107 on Linux). The mirror image: an operation requiring a connection performed on a socket that has none.
• -60 — Connection timed out (ETIMEDOUT, 110 on Linux). What a connect attempt that genuinely did not complete produces, and the error a correct completion check would have surfaced instead of this one.
• -37 — whose catalogue text is Operation already in progress, EALREADY: the state immediately before this one in the same sequence.

Where -56 appears, check whether a session actually established before investigating connectivity. The usual answer is that the connection worked and the code asked the wrong question.