Informix Error -53

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 — Software caused connection abort	53	ECONNABORTED on BSD
The same condition on Linux	103	ECONNABORTED
Errno 53 on Linux	53	EBADR — Invalid request descriptor, STREAMS-era

Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux.

python3 -c 'import os; print(53, os.strerror(53)); print(103, os.strerror(103))'

What ECONNABORTED Actually Tells You

The local system aborted the connection. Not the peer — this end.

That is the distinction from its neighbour, and it points the investigation in the opposite direction:

Error	Symbol	Who ended it
-54	ECONNRESET	The peer sent a RST
-53	ECONNABORTED	This host aborted it

The most common context is accept(). A connection completes the handshake, joins the accept queue, and is then discarded before the server takes it — because the client went away in the interval, or because the queue overflowed. accept() returns ECONNABORTED for a connection that no longer exists.

So the usual reading is: the server was not accepting fast enough, or the client did not wait.

What This Means in Informix

The engine accepts connections through its listeners, and an abort at that point means a session never came into existence. The realistic sources:

• Accept queue overflow. Connections arriving faster than the listener takes them, in bursts — an application server pool starting up, a scheduled job fleet connecting at the same minute, or a failover redirecting a crowd at once.
• Clients giving up during a connection storm. The connection completes at the TCP layer, the client's own timeout expires while it sits in the queue, and the client abandons it before the engine accepts.
• A listener that is busy or stalled, so the queue drains slowly even at modest arrival rates.
• A load balancer health check opening and immediately closing connections, which produces a steady low background of these.
• Connection Manager aborting a connection it has decided to redirect.
• A local firewall rule or security agent terminating a connection after it was established locally.

The characteristic pattern is bursts, not a steady rate — and a burst that correlates with something external starting up rather than with any change on the database host.

Common Causes

1. Accept queue overflow during a connection burst.
2. Clients timing out while queued, and abandoning the connection.
3. A slow or stalled listener draining the queue too slowly.
4. Health checks that connect and close immediately.
5. A local policy agent or firewall terminating established connections.
6. A connection storm after a failover, where every client reconnects at once.

Diagnostic Checks

Check whether the accept queue is overflowing. This is the direct question:

ss -lnt | grep -w <port>          # Recv-Q = current backlog, Send-Q = max
nstat -az | grep -iE 'ListenOverflows|ListenDrops'
netstat -s | grep -iE 'listen|overflow|SYNs to LISTEN'

ListenOverflows climbing is conclusive. Recv-Q approaching Send-Q on the listening socket means the queue is filling faster than it drains.

Sample it under load rather than afterwards:

for i in $(seq 30); do ss -lnt | grep -w <port>; sleep 2; done

Check the system's queue limits:

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_abort_on_overflow

tcp_abort_on_overflow set to 1 changes an overflow from a silent drop into an active reset, which changes what clients see — check it before concluding anything about client behaviour.

Establish the arrival pattern:

onstat -g ses | wc -l
onstat -g ntu
onstat -g ntt
tail -300 "$INFORMIXDIR/tmp/online.log"

Check whether the listener is healthy rather than merely present, since a stalled listener produces this at arrival rates that should be trivial:

onstat -
onstat -g ath | head -30
uptime

Identify health-check traffic, which accounts for a steady low background and is easily mistaken for a fault:

ss -ant | awk '$1=="SYN-RECV" || $1=="TIME-WAIT" {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

A single source address responsible for a regular trickle is usually a monitor or a load balancer.

Solutions / Resolution

1. Establish whether it is bursts or a steady trickle. A trickle from one address is health checks and is normal. Bursts correlating with an external event are the real case, and the two need nothing in common.
2. Check ListenOverflows before changing anything. If it is not climbing, the accept queue is not the problem and raising the backlog will achieve nothing.
3. Raise the backlog only if the queue is genuinely overflowing, and raise it at both ends — net.core.somaxconn caps what a listener can request, so raising one without the other has no effect.
4. Address the burst rather than the queue where you can. Staggered application-server startup, staggered scheduled jobs, or connection pooling remove the arrival spike; a deeper queue only absorbs it.
5. Look at client timeouts. A client that gives up in two seconds during a reconnect storm will abandon queued connections that would have succeeded shortly. This is frequently the actual fault, and it is on the client side.
6. Expect this after a failover and judge it accordingly. Every client reconnecting at once is a burst by definition; the question is whether the engine recovered, not whether aborts occurred during it.
7. If the listener is stalled rather than busy, the queue is a symptom. Look at what the instance is doing before treating the network stack as the cause.

Examples

A connection storm at a fixed minute

$ nstat -az | grep -i listenoverflow
TcpExtListenOverflows           4127               0.0

$ ss -lnt | grep -w 9088
LISTEN 128 128  0.0.0.0:9088  0.0.0.0:*

Recv-Q at 128 against a maximum of 128 — the queue is full, and overflows are accumulating. Something is arriving in a burst the listener cannot absorb.

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

The limit is the distribution default. Raising it gives headroom, but the durable fix is whatever is connecting fifty clients in the same second — usually an application tier that restarts all its instances together.

A steady trickle from one address

$ ss -ant | awk '$1=="TIME-WAIT" {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -3
   1440 10.4.1.9
      8 10.4.1.51
      6 10.4.1.52

One address, 1440 short-lived connections — one a minute for a day. That is a health check opening and closing a connection, not a fault. It belongs on the list of things to recognise and leave alone.

Platform Note

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

Task	Linux	Solaris	AIX
Listen queue state	ss -lnt, nstat	netstat -an, kstat tcp	netstat -an, netstat -s -p tcp
Backlog limit	sysctl net.core.somaxconn	ipadm show-prop -p _conn_req_max_q tcp	no -o somaxconn
Overflow counters	nstat ListenOverflows	kstat -p tcp:0:tcp:listenDrop	netstat -s -p tcp

Solaris reports listenDrop and listenDropQ0 through kstat, which are the direct equivalents of ListenOverflows and worth watching by the same method.

Related Errors / Related Topics

• -54 — Connection reset by peer. The other end aborted rather than this one. The pair is worth reading together, because which end acted decides where the investigation goes.
• -32 — Broken pipe. A write to a connection that is already gone, and the error that commonly follows either of these in the same session.
• -55 — No buffer space available. The other resource limit a connection burst can reach, and one that can produce this error indirectly.

Where aborts are frequent, count them and find their arrival pattern before tuning anything. A deeper accept queue absorbs a burst; it does not stop one being created.