Oninit
Talk to an expert →

Informix Error -54

-54 Connection reset by peer.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. If you are attempting to use Informix STAR or IBM Informix NET, contact your system administrator to report a network problem. If not, note all circumstances and contact IBM Informix Technical Support.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

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 — Connection reset by peer 54 ECONNRESET on BSD
The same condition on Linux 104 ECONNRESET
Errno 54 on Linux 54 EXFULL — Exchange full, STREAMS-era

Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux. A genuine connection reset on Linux carries errno 104.

python3 -c 'import os; print(54, os.strerror(54)); print(104, os.strerror(104))'

Everything below concerns the condition rather than the number.

What ECONNRESET Actually Tells You

The peer sent a TCP RST. The connection did not close, it was aborted, and any data still in flight is discarded.

A reset is not a timeout and not an orderly close. It is a specific statement from the other end, or from something in the path, that this connection is finished now.

Distinguishing the neighbouring conditions matters, because they point at different layers:

What happened Symbol Linux errno
The peer sent RST ECONNRESET 104
The local stack aborted it before it was established ECONNABORTED 103
A write found the peer already gone EPIPE 32
The network dropped it on reset ENETRESET 102

EPIPE and ECONNRESET are the pair most often confused. Both mean the other end is gone; ECONNRESET is the read or write that met the RST, and EPIPE is the write to a connection already known to be dead. In practice a client that disappears produces one then the other.

What This Means in Informix

A reset reaching the database server means a client connection, a replication link, or a proxied session was aborted by the far end or by something between.

Who sends the RST matters, and it is not always the client:

  • The client process exited or was killed while the connection was open. The most common cause, and usually benign — a user closing a tool, an application server recycling a pool, a batch job terminated.
  • A firewall or load balancer aborted an idle connection. Many appliances send RST rather than dropping silently, and many expire idle sessions well inside the intervals a database connection pool assumes. This produces resets clustered at a fixed idle interval, which is the signature to look for.
  • A NAT or stateful device lost its table entry, then reset the next packet it could not place.
  • HDR, RSS or ER partners aborting a link, often as a consequence of their own failure rather than a network fault.
  • Connection Manager or a proxy tearing down a session it has decided to move or fail over.
  • The peer host rebooted, so the connection no longer exists there and any packet for it earns a reset.
  • A client library timeout that closes hard rather than gracefully.

A single reset from a client is normal operational noise. The diagnostic question is the pattern: whether it is one session, one client host, one network path, or everything at once.

Common Causes
  1. A client exited, crashed or was killed mid-session.
  2. An idle-timeout device — firewall, load balancer or NAT — resetting connections on a fixed interval.
  3. A connection pool holding sessions longer than the network path will.
  4. A peer host rebooting or failing over.
  5. An application-side timeout closing hard.
  6. Replication partners dropping a link.
  7. Route or path changes invalidating stateful device entries.
Diagnostic Checks

Establish the scope first. One client, one host, one subnet, or everything — this decides whether you are looking at an application, a host, or a network path:

tail -500 "$INFORMIXDIR/tmp/online.log"
onstat -g ses
onstat -g ntu
onstat -g ntt

Look for a time signature. Resets clustered at a regular interval point at a device with an idle timeout rather than at clients behaving randomly:

grep -iE 'reset|closed|disconnect' "$INFORMIXDIR/tmp/online.log" | awk '{print $2}' | sort | uniq -c

An even distribution suggests clients; a spike at a fixed offset suggests an appliance.

Check the network path's own counters:

ss -s
netstat -s | grep -iE 'reset|abort|fail'
nstat -az 2>/dev/null | grep -iE 'TcpExtTCPAbort|TcpOutRsts|TcpAttemptFails'

TcpOutRsts rising means this host is sending resets; a rise with no local cause points outward.

Check keepalive settings, which determine whether a connection idle behind an appliance is kept warm or silently dropped:

sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

A default keepalive of two hours against a firewall idle timeout of thirty minutes guarantees this error for any pooled connection.

Capture it, if the source is disputed. A capture settles who sent the RST, which is otherwise a matter of opinion between teams:

tcpdump -nni any "tcp port <port> and tcp[tcpflags] & tcp-rst != 0" -c 50

The source address on the RST is the answer.

Check the client side where you can reach it:

# on the client host
dmesg -T | grep -iE 'oom|killed'
journalctl --since '1 hour ago' | grep -iE 'segfault|killed|restart'
Solutions / Resolution
  1. Decide whether this is noise. Isolated resets from clients are normal. Effort spent on a handful of them is effort taken from whatever else is wrong.
  2. Establish the pattern before the cause. One client host, one subnet, or a fixed interval each point somewhere different, and the checks above separate them in minutes.
  3. If it is an idle timeout, align the intervals. The durable fix is keepalive on the database host set below the shortest idle timeout in the path, plus a pool that recycles connections inside the same window. Raising the appliance timeout alone leaves the mismatch in place for the next device.
  4. Do not raise pool sizes to compensate. More connections idling behind a device that resets idle connections produces more resets, not fewer.
  5. If clients are dying, fix that. A reset is the symptom; check the client host for OOM kills, crashes or a supervisor restarting the application.
  6. For replication links, treat it as the partner's problem until proven otherwise. An HDR or ER reset is more often the consequence of the partner's own failure than of the network between them.
  7. Capture the RST before escalating to the network team. "The database is seeing resets" invites a long conversation; a capture naming the source address ends it.
Examples
Resets on a fixed interval
$ grep -ci 'reset' "$INFORMIXDIR/tmp/online.log"
288

288 in 24 hours is one every five minutes — far too regular for users closing applications. That regularity is a device expiring idle sessions.

$ sysctl net.ipv4.tcp_keepalive_time
net.ipv4.tcp_keepalive_time = 7200

Keepalive at two hours against an idle timeout somewhere in the path that is very much shorter. Every pooled connection that goes quiet is reset before the first keepalive probe is ever sent. Lowering keepalive below the path's timeout keeps the connections warm.

One client host, everything else fine
$ onstat -g ses | awk 'NR>3 {print $NF}' | sort | uniq -c | sort -rn | head -3
     41 appsrv03
     38 appsrv01
     37 appsrv02

Sessions distributed evenly, but the resets all name one host. That is not a network fault — it is something on appsrv03, and the investigation belongs there.

Platform Note
Platform This condition Errno 54 there means
Linux errno 104 EXFULL — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 54 this condition

Quoting "error 54" into a cross-team ticket on a Linux estate will send the network team looking for something that does not exist. Quote the symbol.

Task Linux Solaris AIX
TCP counters nstat, netstat -s netstat -s -P tcp netstat -s -p tcp
Keepalive settings sysctl net.ipv4.tcp_keepalive_* ipadm show-prop -p _tcp_keepalive_interval tcp no -a | grep keepalive
Capture tcpdump snoop, tcpdump iptrace, tcpdump
Related Errors / Related Topics
  • -53 — Software caused connection abort (ECONNABORTED, 103 on Linux). The local stack aborting a connection, usually before it was fully established — a different half of the same story.
  • -32 — Broken pipe. The write that finds the peer already gone. The closest sibling, and frequently the error that follows this one in the same session.
  • -52 — Network dropped connection on reset (ENETRESET, 102 on Linux), where the path rather than the peer is responsible.

Where resets are frequent, the pattern is the diagnosis. Count them, look for a regular interval, and identify whether they follow a client, a host or a path before treating the network as the cause.