Informix Error -61

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 refused	61	ECONNREFUSED on BSD
The same condition on Linux	111	ECONNREFUSED
Errno 61 on Linux	61	ENODATA — No data available

-61 is the last member of the BSD socket block; from -62 the numbering stops tracking Linux's socket range.

python3 -c 'import os; print(61, os.strerror(61)); print(111, os.strerror(111))'

What ECONNREFUSED Actually Tells You

A TCP RST came back in answer to the connection attempt. Something received the packet and declined it.

The most useful thing this error tells you is what is working, and it is easy to overlook:

• The route to the host exists.
• The packet arrived.
• Something on the other side generated a reply.

So a refusal proves reachability. That is the whole distinction from -60, where nothing answers at all, and it means the network layer is generally not where the fault is.

Error	Linux	What it proves
-61 ECONNREFUSED	111	The host is reachable; nothing accepted on that port
-60 ETIMEDOUT	110	Nothing answered — reachability unknown
-65 EHOSTUNREACH	113	A router said it could not deliver

Two things produce a refusal:

• Nothing is listening on that address and port, so the host's own stack answers with a RST.
• A firewall rule configured to reject rather than drop, which forges the same answer on the host's behalf.

The failure is immediate, which distinguishes it from a timeout at a glance and is often the first thing a user notices — it fails at once rather than hanging.

What This Means in Informix

The case worth knowing: the instance is running and connections are refused

This is the pattern that wastes the most time, because everything on the server looks healthy.

An instance can be online with no listener. The engine binds a listening socket for each network entry in sqlhosts, and if a bind fails the instance can still come up — that failure is -48 (the address was in use) or -49 (the address was not available on this host). Neither stops the engine running.

The result is an instance that onstat - reports as On-Line, serving nobody, while every client gets an immediate refusal.

So on a -61, check the listener separately from the instance. onstat - answers a different question and will not reveal this.

The other origins

• The instance is genuinely down, or stopping, or in a mode not accepting connections.
• The wrong port. A sqlhosts service entry, or /etc/services, disagreeing between client and server. The client connects to a port where nothing listens on a host that is perfectly reachable.
• The listener bound to one address. Bound to a specific interface or to loopback, connections to any other address on the host are refused — and testing from the server itself will succeed, which makes it look like a client problem.
• A firewall rule using REJECT. Nothing is wrong on the server at all; the refusal is manufactured in the path.
• Connection Manager or a proxy refusing a connection it has decided not to route.
• A replication partner not yet started, where the surviving side retries against a listener that does not exist.

Common Causes

1. The listener never bound, while the instance is running — see -48 and -49.
2. The instance is down or not accepting connections.
3. A port mismatch between the client's sqlhosts or services entry and the server's.
4. A listener bound to one address, refusing connections to the others.
5. A firewall rule that rejects rather than drops.
6. A replication partner not started yet.
7. A proxy or Connection Manager declining to route.

Diagnostic Checks

Confirm the symbol, since errno 61 on Linux is ENODATA and unrelated:

python3 -c 'import os; print(61, os.strerror(61)); print(111, os.strerror(111))'

On the server, check the listener — not the instance. This is the step that finds the expensive case:

onstat -                                  # is the instance up
ss -lntp | grep -w <port>                 # is anything LISTENING

An instance On-Line with no matching LISTEN line is the bound-but-unreachable case. Go to -48 and -49 for why the bind failed, and check the message log around startup.

Check what address the listener is bound to, which explains "works locally, refused remotely":

ss -lntp | grep -w <port>

LISTEN 0 128 0.0.0.0:9088   0.0.0.0:*     <- all addresses
LISTEN 0 128 127.0.0.1:9088 0.0.0.0:*     <- loopback only; remote clients refused
LISTEN 0 128 10.4.1.20:9088 0.0.0.0:*     <- one address only

Test from three places, because where it succeeds localises the fault immediately:

# on the server, via loopback
nc -vz 127.0.0.1 <port>
# on the server, via its own external address
nc -vz <server-address> <port>
# from the client host
nc -vz <server-address> <port>

Loopback	Own address	Remote	Conclusion
OK	OK	refused	Filtering in the path, or a REJECT rule
OK	refused	refused	Listener bound to loopback only
refused	refused	refused	Nothing is listening at all

Confirm the port both sides are using, since a mismatch produces this with everything else healthy:

cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
getent services <servicename>
grep -w <servicename> /etc/services

Run the same two commands on the client host. A service name resolving to different numbers on the two machines is a complete explanation.

Check for a rejecting rule where the server is listening and remote clients are refused:

iptables -S 2>/dev/null | grep -iE 'reject|<port>'
nft list ruleset 2>/dev/null | grep -iE 'reject|<port>'
firewall-cmd --list-all 2>/dev/null

A REJECT target is the manufactured refusal; the server never saw the connection.

And the engine's record, especially around startup:

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

Solutions / Resolution

1. Check the listener before the instance. An online instance with no listener is the most expensive form of this error precisely because everything looks correct.
2. Use the three-way test to localise it. Loopback, own address, remote — where it stops working names the layer, and it takes under a minute.
3. If the listener never bound, that is the real fault. Read -48 if the address was in use and -49 if it was not available on the host, and fix the bind rather than the connection.
4. Compare the service entry on both hosts. A port mismatch is common, quick to check, and invisible from either side alone.
5. If the listener is bound to loopback or a single address, decide deliberately what it should serve. Binding to one address is a reasonable choice; discovering it by accident is not.
6. Where a REJECT rule is responsible, fix the rule. Nothing on the database host will help, and the refusal is doing exactly what it was configured to do.
7. For replication, check the partner is actually up before investigating the network. A refusal from a partner that has not started is expected rather than a fault, and will clear when it starts.
8. Do not add retries to work around it. A refusal is immediate and deterministic; retrying produces the same answer faster than a timeout would and still fails.

Examples

On-Line, and refusing every connection

$ onstat -
IBM Informix Dynamic Server Version ... -- On-Line -- Up 03:41:22

$ ss -lntp | grep -w 9088
$

The instance is up. Nothing is listening. Every client receives an immediate refusal while the server appears entirely healthy, and onstat - will never show the problem.

$ grep -iE 'listen|bind|network' "$INFORMIXDIR/tmp/online.log" | tail -5

The startup entries are where the bind failure was recorded. Whether it was -48 or -49 decides the fix; both leave the instance running.

Works on the server, refused from everywhere else

$ ss -lntp | grep -w 9088
LISTEN 0 128 127.0.0.1:9088 0.0.0.0:*

Bound to loopback. A test run on the server succeeds, which is exactly what makes this look like a client-side problem — and it is the first test most people run.

The same service, two different ports

# on the server
$ getent services sqlexec_prod
sqlexec_prod          9088/tcp

# on the client host
$ getent services sqlexec_prod
sqlexec_prod          1526/tcp

Both hosts are correct by their own configuration. The client connects to 1526, where nothing listens, and is refused by a server that is running normally on 9088.

Platform Note

Platform	This condition	Errno 61 there means
Linux	errno 111	ENODATA — no data available, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 61	this condition

Task	Linux	Solaris	AIX
Listening sockets	ss -lntp	netstat -an, pfiles	netstat -Aan
Firewall rules	iptables -S, nft list ruleset	ipf -Fa, ipfstat	lsfilt
Service lookup	getent services	getent services	getent services

Related Errors / Related Topics

• -60 — Connection timed out. The comparison that matters: a refusal proves the host is reachable, a timeout proves nothing. Which of the two you get identifies whether an obstruction rejects or drops.
• -48 — Address already in use, and -49 — Can't assign requested address. The two bind failures that leave an instance running with no listener, which is what this error then reports to every client.

Where connections are refused, look for the listener rather than the instance, and test from the server before involving anyone else. A refusal is precise information — something answered — and most of the work is deciding what.