Informix Error -57

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 not connected	57	ENOTCONN on BSD
The same condition on Linux	107	ENOTCONN — Transport endpoint is not connected
Errno 57 on Linux	57	EBADSLT — Invalid slot, STREAMS-era

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

python3 -c 'import os; print(57, os.strerror(57)); print(107, os.strerror(107))'

What ENOTCONN Actually Tells You

An operation that requires a connection was performed on a socket that does not have one. send(), recv(), getpeername() and shutdown() all report it.

In most cases this is a consequence rather than a cause, and that is the single most useful thing to know about it. The connection did not fail here — it failed earlier, and this is the next operation discovering the socket is no longer usable.

The sequence in a log usually runs:

1.  ECONNRESET   the peer aborted        <- the real event   (-54)
2.  ENOTCONN     the next read or write  <- this error       (-57)
3.  ENOTCONN     everything after that

So a -57 is often the second error, and the first one is the one worth finding. Code that reports every failure identically produces a log full of -57 with the causal ECONNRESET or ETIMEDOUT buried at the top.

The exception is the genuinely unconnected case: an operation performed on a socket that was created but never successfully connected. That is a defect in the calling code, and it pairs with -56 — where the same code, having failed to check whether its connect succeeded, gets told the socket is connected.

What This Means in Informix

Where a -57 reaches the database server, it is nearly always downstream of a connection that has already gone:

• A session whose client disappeared. The reset or timeout is the event; subsequent operations on that socket report this.
• A connection pool handing out a socket that was already torn down, because the pool tracks its own state rather than the socket's.
• A replication link after the partner was lost — the same pattern, with HDR, RSS or ER in place of a client.
• Client code sending without confirming the connect completed, which is the mirror of the -56 defect and produced by the same missing check.
• A retry loop reusing a socket that should have been closed and reopened.

The practical consequence: count the distinct errors before counting the occurrences. Two hundred -57s and one -54 is a single event, not two hundred.

Common Causes

1. A connection already lost — reset, timeout or orderly close — with this reported by the next operation.
2. A connection pool reusing a socket whose peer has gone.
3. Code that sends without checking whether its connect succeeded — see -56.
4. A retry loop reusing a socket rather than reopening one.
5. shutdown() or getpeername() on a socket that was never connected.

Diagnostic Checks

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

python3 -c 'import os; print(57, os.strerror(57)); print(107, os.strerror(107))'

Look earlier in the log, not at this error. This is the step that matters, and it is the one most often skipped:

tail -500 "$INFORMIXDIR/tmp/online.log"
grep -n -iE 'reset|timed out|refused|closed|disconnect|errno' "$INFORMIXDIR/tmp/online.log" | tail -40

Count distinct errors rather than total occurrences:

grep -oiE 'system error = [0-9]+' "$INFORMIXDIR/tmp/online.log" | sort | uniq -c | sort -rn

A large count against this code and a small one against -54 or -60 tells you which is the event and which is the echo.

Check the session and connection state:

onstat -g ses
onstat -g ntu
ss -antp | grep -w <port> | awk '{print $1}' | sort | uniq -c

Trace, where the unconnected-socket case is suspected:

strace -f -e trace=connect,send,sendto,recv,recvfrom,getpeername,shutdown -p <pid> 2>&1 | grep -iE 'ENOTCONN|EISCONN|EINPROGRESS'

A send() returning ENOTCONN with no preceding successful connect() is the defect rather than a lost connection.

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

For replication, establish whether the partner went first:

onstat -g dri
onstat -g rss 2>/dev/null

Solutions / Resolution

1. Find the first error, not this one. A -57 is usually the echo. The reset, timeout or refusal that preceded it is the event to investigate, and everything on -54, -60 or -32 may apply instead.
2. Do not tune anything on the strength of a -57 count. The count measures how many operations were attempted after the connection went, which is a property of the retry logic rather than of the network.
3. Fix pools that track their own state. A pool that hands out a socket without checking it is still connected turns one lost connection into a stream of failures. Validating on checkout, or closing on any error, removes the pattern.
4. Close and reopen rather than retrying on the same socket. Once a connection is gone the socket cannot be recovered; a retry loop that reuses it will produce this indefinitely.
5. Where it is the unconnected case, fix the connect check — see -56. The same missing SO_ERROR check produces both errors depending on timing.
6. For replication, check the partner before the network. An HDR or ER link reporting this after the partner failed is describing the consequence.

Example

Two hundred errors, one event

$ grep -oiE 'system error = [0-9]+' "$INFORMIXDIR/tmp/online.log" | sort | uniq -c | sort -rn
    213 system error = 107
      1 system error = 104

One ECONNRESET and 213 subsequent operations on the dead socket. The single event is at the top of the log; everything after it is the application continuing to use a connection that no longer exists.

Investigating the 213 leads nowhere. The one is -54, and the retry loop that produced the rest is a second, separate defect worth fixing on its own.

Platform Note

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

Linux words it Transport endpoint is not connected, so searching for the catalogue's phrasing on a Linux host will not match.

Task	Linux	Solaris	AIX
Socket states	ss -antp	netstat -an, pfiles	netstat -Aan
Trace	strace -f	truss -f	truss -f

Related Errors / Related Topics

• -56 — Socket is already connected. The mirror image, and the other half of the same missing-check defect in connect handling.
• -54 — Connection reset by peer. The most common cause of the connection having gone in the first place, and usually the error to investigate instead of this one.
• -32 — Broken pipe. The other error a write to a dead connection produces; which of the two you get depends on the operation and the platform.

Where -57 appears in volume, look above it in the log. The useful error is the first one, and this code is generally the sound of an application that has not noticed yet.