Informix Error -65

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 — Host is unreachable	65	EHOSTUNREACH on BSD
The same condition on Linux	113	EHOSTUNREACH — No route to host
Errno 65 on Linux	65	ENOPKG — Package not installed

python3 -c 'import os; print(65, os.strerror(65)); print(113, os.strerror(113))'

Linux words it No route to host, which is more accurate than the catalogue's phrasing and is worth carrying into any conversation about it — the error is about reachability, not about whether the host is running.

What EHOSTUNREACH Actually Tells You

Something decided the destination host could not be reached and said so. Two routes produce it:

• An ICMP destination unreachable with the host code, sent by a router along the path.
• A local determination, where the routing table has a route to the network but nothing can resolve or deliver to that specific host within it — commonly ARP going unanswered on a local subnet.

This is the common one. Where -64 (EHOSTDOWN) is a narrow assertion that the host is not running, this covers everything from a genuinely absent host to a router that will not forward to it. Linux returns it far more often than -64 for what people call "the host is down".

The full comparison of the five "cannot reach it" errors — and which layer decides each — is on -64. The distinction that matters most here is the granularity:

Error	Linux	Granularity
-51 ENETUNREACH	101	No route to the network — decided locally, before anything leaves
-65 EHOSTUNREACH	113	The network is routable; this host within it is not

It is not always a statement about the host

The point most often missed: EHOSTUNREACH can be manufactured deliberately.

A firewall configured to reject with an ICMP host-unreachable message produces exactly this error, from a host that is up and a service that is running:

-j REJECT --reject-with icmp-host-unreachable

That is a common default for REJECT rules in a forwarding chain, so "host unreachable" may be a policy decision rather than a fact. The same applies to routing entries of type unreachable or prohibit, which answer on the router's own behalf.

So the useful question is not "is the host down?" but "who sent the unreachable, and why?" — and that has a direct answer, below.

What This Means in Informix

Inbound connections fail on the client, so the engine's log records this against outbound work:

• A replication partner — HDR, RSS or ER — on a host or subnet that cannot be reached.
• Connection Manager reaching an instance it proxies for.
• A distributed query to another server named in sqlhosts.
• onbar reaching a storage manager on another host.
• Monitoring or alert scripts sending outward.

The instance is a bystander, and the work is establishing whether this is a fault or a policy. A replication link that fails this way after a firewall change is not a database problem and not a host failure, and it will not resolve itself.

The pattern worth recognising: a -65 that appears at a precise moment and never recovers is usually a change — a rule, a route, a failover — rather than a fault. A -65 that comes and goes is more likely a path or a load problem.

Common Causes

1. A firewall rejecting with an ICMP host-unreachable message. The host and service are fine.
2. A router with no route to the destination host, or a route deliberately marked unreachable.
3. The remote host genuinely absent — powered off, or removed from the network.
4. ARP resolution failing on a local subnet.
5. A failover in progress, where the address has moved and the path has not caught up.
6. An asymmetric or broken return path, where the request arrives and nothing comes back.
7. A routing change that withdrew a more specific route while leaving the network route in place.

Diagnostic Checks

Confirm the symbol, since errno 65 on Linux is ENOPKG:

python3 -c 'import os; print(65, os.strerror(65)); print(113, os.strerror(113))'

Ask the local routing table what it would do. This separates -65 from -51 immediately:

ip route get <host-ip>

A route returned means the local side is willing and something further out refused. Network is unreachable here means you have -51 instead, and the fault is local.

Find out who sent the unreachable. This is the decisive step and it has a direct answer — the source address on the ICMP names the device that refused:

tcpdump -nni any icmp and icmp[icmptype] == 3 -c 20

10.4.9.1 > 10.4.1.20: ICMP host 10.4.9.31 unreachable, length 68
        ^^^^^^^^ the router that refused

Run a connection attempt in another window while that capture is running. The address on the left is where to take the question, and it is frequently a firewall rather than a router.

On a local subnet, check the neighbour cache — ARP failure produces this without any ICMP at all:

ip neigh show <host-ip>
ip neigh flush dev <iface>     # then retry; a stale entry clears
arping -c 3 -I <iface> <host-ip> 2>/dev/null

Trace the path to see how far it gets:

traceroute -n <host>
traceroute -n -T -p <port> <host> 2>/dev/null
tracepath -n <host>

The last hop that answers is the device to ask about, and it is usually the one sending the unreachable.

Check whether this host's own rules are responsible, which is quick to eliminate and occasionally the answer:

iptables -S 2>/dev/null | grep -i unreachable
nft list ruleset 2>/dev/null | grep -i unreachable
ip route show | grep -iE 'unreachable|prohibit|blackhole'

Confirm from a second host, which decides whether the path or the destination is at fault:

# from another host, ideally on a different subnet
ping -c 3 <host>
nc -vz -w 10 <host> <port>

And the Informix side:

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

Solutions / Resolution

1. Capture the ICMP and read the source address. It names the device that refused, which converts "the database cannot reach the partner" into a specific question for a specific box. This is the single most useful thing to do on this error.
2. Check whether it is a rejection rather than a failure. A firewall rejecting with host-unreachable produces this from a perfectly healthy host, and no amount of investigation at either end will show anything wrong.
3. Distinguish it from -51 with ip route get. A local Network is unreachable is a different error and a local fix.
4. Flush the neighbour cache on a local subnet before concluding anything. A stale ARP entry produces this cheaply and clears in seconds.
5. Test from a second host. Failing from both means the destination; failing from one means the path, and the path is where the work is.
6. Do not restart the instance. Nothing about the engine is involved.
7. For replication, verify the pair once reachability returns rather than waiting for the errors to stop. Links do not always re-establish silently.
8. If it appeared at a precise moment, look for a change. Rules, routes and failovers produce a clean transition; faults are usually messier.

Examples

The router names itself

$ ip route get 10.4.9.31
10.4.9.31 via 10.4.1.1 dev eth0 src 10.4.1.20

$ tcpdump -nni any 'icmp and icmp[icmptype] == 3' -c 3
10.4.9.1 > 10.4.1.20: ICMP host 10.4.9.31 unreachable, length 68
10.4.9.1 > 10.4.1.20: ICMP host 10.4.9.31 unreachable, length 68

The local host has a route and is sending. A device at 10.4.9.1 — the far-side gateway — is answering that it cannot deliver. That is where the question belongs, and the database host has nothing further to contribute.

Whether 10.4.9.1 cannot reach the host or has been told not to is the next question, and only its owner can answer it.

Unreachable, and perfectly healthy

# on the database host
$ nc -vz -w 10 storage-mgr 1556
nc: connect to storage-mgr port 1556 (tcp) failed: No route to host

# on the storage manager itself
$ ss -lntp | grep -w 1556
LISTEN 0 128 0.0.0.0:1556 0.0.0.0:*

The service is listening and the host is up. Something between the two is rejecting with an ICMP host-unreachable, which reads identically to a host that is not there.

A capture on the database host names the device doing it. Without that, this looks like a storage-manager outage and will be escalated as one.

Platform Note

Platform	This condition	Errno 65 there means
Linux	errno 113, No route to host	ENOPKG — Package not installed
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 65	this condition

Task	Linux	Solaris	AIX
Route for a destination	ip route get <ip>	route get <ip>	route get <ip>
Neighbour cache	ip neigh show	arp -a	arp -a
Capture ICMP	tcpdump icmp	snoop icmp, tcpdump	iptrace, tcpdump
Path trace	traceroute -n, tracepath	traceroute	traceroute

route get on Solaris and AIX answers the same question as ip route get and is equally the right first command there.

Related Errors / Related Topics

• -64 — Host is down. The narrower assertion, and where the five-way comparison of all the "cannot reach it" errors lives. Read it alongside this one.
• -51 — Network is unreachable. No route at all, decided locally before anything leaves the host. ip route get separates the two in one command.
• -60 — Connection timed out. Nothing answered, as against something answering that it could not deliver. A timeout carries less information than this error does.

Where -65 appears, capture the ICMP. The source address on the unreachable message names the device that refused, and that single fact is worth more than any amount of testing from the database host.