Oninit
Talk to an expert →

Informix Error -52

-52 Network dropped connection on reset.

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 — Network dropped connection on reset 52 ENETRESET on BSD
The same condition on Linux 102 ENETRESET
Errno 52 on Linux 52 EBADE — Invalid exchange, STREAMS-era

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

python3 -c 'import os; print(52, os.strerror(52)); print(102, os.strerror(102))'
What ENETRESET Actually Tells You

An established connection was dropped because the network or the remote host reset its state — most commonly because the peer host rebooted, or a keepalive probe found the connection no longer existed at the far end.

It is the least common of the three connection-loss errors, and it is worth knowing where it sits between them:

Error Symbol Linux What ended it
-53 ECONNABORTED 103 This host aborted it
-54 ECONNRESET 104 The peer sent a RST
-52 ENETRESET 102 The connection's state was lost at the network or remote end

In practice ECONNRESET is what you will usually see; ENETRESET is reported in narrower circumstances, typically when a keepalive detects that the far end no longer has the connection.

What This Means in Informix

An established session, replication link, or proxied connection was lost because the other end's state disappeared rather than because it closed:

  • The peer host rebooted or crashed while sessions were open. The classic case: connections exist here and not there, and the first keepalive to discover it reports this.
  • A stateful firewall or NAT restarted, losing its connection table.
  • A failover moved the peer, so the new node has no record of connections the old one held.
  • A long-idle connection that outlived something's state table, discovered when traffic resumed.

For replication in particular, this is what a partner's unplanned restart looks like from the surviving side.

Common Causes
  1. The peer host rebooted or crashed with connections open.
  2. A stateful network device restarted and lost its table.
  3. A cluster failover moving a peer to a node without the connection state.
  4. A keepalive probe discovering a connection the far end no longer has.
  5. A long idle period followed by traffic, where state expired in between.
Diagnostic Checks

Establish whether the peer restarted. That answers most of these outright:

# on the peer, where reachable
uptime
who -b
last reboot | head -3
journalctl --list-boots 2>/dev/null | tail -3

An uptime shorter than the age of the error is the whole diagnosis.

Check the local view of the connections:

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

Check keepalive settings, since keepalive is usually what surfaced the condition and its timing explains the delay between the peer's restart and the error appearing:

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

A two-hour default means a peer that rebooted can go unnoticed for two hours on an idle connection.

For replication, check the link state directly:

onstat -g dri
onstat -g rss 2>/dev/null
tail -300 "$INFORMIXDIR/tmp/online.log"

Rule out a network device restart where the peer was up throughout:

nstat -az | grep -iE 'TcpExtTCPAbort|TcpOutRsts'
dmesg -T | grep -iE 'link is (up|down)'
Solutions / Resolution
  1. Check the peer's uptime first. A restarted peer explains it completely, and nothing further is needed beyond confirming what recovered.
  2. Treat it as connection loss rather than as a distinct fault. The remedies are the same as for -54: re-establish, verify what recovered, and look at why the peer went away.
  3. Lower keepalive if detection was slow. This error frequently appears long after the event that caused it, because an idle connection is not probed until keepalive fires. Aligning keepalive with the recovery expectations is the durable improvement.
  4. For replication, verify the pair rather than waiting for silence. Check the partner's state explicitly after the link returns; the absence of further errors is not confirmation.
  5. If the peer did not restart, look at the stateful devices in the path. A firewall or NAT that lost its table produces this without anything at either end having changed.
  6. Do not tune the database for it. Nothing in the engine caused this, and nothing in the engine prevents it.
Example
The partner rebooted two hours ago
$ ssh hdr-partner uptime
 09:41:02 up 2:07,  1 user,  load average: 0.31, 0.28, 0.24

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

The partner restarted just over two hours ago and keepalive fires at two hours. The connection here survived, idle and believed good, until the first probe discovered the far end had no record of it. The error is two hours late and describes something that happened at the moment of the reboot.

Shortening keepalive does not prevent the event; it shortens the window in which this host believes a dead connection is alive.

Platform Note
Platform This condition Errno 52 there means
Linux errno 102 EBADE — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 52 this condition
Task Linux Solaris AIX
Keepalive settings sysctl net.ipv4.tcp_keepalive_* ipadm show-prop tcp no -a | grep keepalive
Connection state ss -antp netstat -an, pfiles netstat -Aan
Peer uptime uptime, who -b uptime, who -b uptime, who -b
Related Errors / Related Topics
  • -54 — Connection reset by peer. The far more common connection-loss error, and the one most of this material applies to equally.
  • -50 — Network is down, where the local interface rather than the remote state is the problem.
  • -53 — Software caused connection abort, where this host ended the connection.

Where -52 appears, check the peer's uptime before anything else. Most instances of this error are a restart elsewhere, reported here as late as the keepalive interval allows.