Informix Error -64

-64 Host is down.

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 — Host is down	64	`EHOSTDOWN` on BSD
The same condition on Linux	112	`EHOSTDOWN`
Errno 64 on Linux	64	`ENONET` — Machine is not on the network

python3 -c 'import os; print(64, os.strerror(64)); print(112, os.strerror(112))'

Where This Sits Among the "Cannot Reach It" Errors

Five distinct errors describe a connection that did not get where it was going, and each is decided at a different layer. Reading them correctly is most of the diagnostic value in this part of the range:

Error	Symbol	Linux	Decided by	What it means
-50	`ENETDOWN`	100	Local stack	This host's interface is down
-51	`ENETUNREACH`	101	Local routing table	No route exists here for that destination
-64	`EHOSTDOWN`	112	Link layer or ICMP	The host is known not to be up
-65	`EHOSTUNREACH`	113	A router, via ICMP	A router could not deliver to it
-60	`ETIMEDOUT`	110	Nothing	Nothing answered at all

The first two are decided without a packet leaving the host, and are about local configuration. The last is the absence of information. -64 and -65 sit in between: something actively reported a failure.

What EHOSTDOWN Actually Tells You

The host has been determined to be down rather than merely unresponsive.

On a local subnet that determination usually comes from the link layer: the address needs resolving to a hardware address, ARP requests go unanswered, and the stack concludes the host is not there. Off-subnet it comes from an ICMP host unreachable with a code indicating the host is down.

In practice this is the rarer of the pair. Linux reports EHOSTUNREACH (-65) far more often for what is colloquially "the host is down", and EHOSTDOWN appears in narrower circumstances. So a genuine -64 is a reasonably specific piece of information — something on the path asserted that the host is not running, rather than simply failing to hear from it.

It also means, usefully, that the network up to that point is working. A determination that the host is down had to be made somewhere, and that somewhere is reachable.

What This Means in Informix

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

A replication partner — HDR, RSS or ER — whose host has gone down rather than merely stopped accepting.
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.
A monitoring or alert script sending outward.

The instance is a bystander. The value in recognising this error is speed: it says the remote host is down, which is a different conversation from the instance being unreachable for a configuration reason. Distinguishing it from -61 matters most — a refusal means the host is up and something declined, this means the host is not there at all.

For a replication pair this is generally the clearest of the failure modes to act on, because it names the fault as belonging to the partner's host rather than to the link or to either instance.

Common Causes

The remote host is powered off, rebooting, or has crashed.
ARP resolution failing on a local subnet, because the host is not answering at the link layer.
A failover in progress, where the old node has gone and the new one is not yet up.
A virtual machine stopped or migrating.
A switch port disabled on the remote host's side, so it is off the network entirely.
A stale ARP entry pointing at a hardware address that is no longer present.

Diagnostic Checks

Confirm the symbol, since errno 64 on Linux is ENONET and describes something else:

python3 -c 'import os; print(64, os.strerror(64)); print(112, os.strerror(112))'

Establish whether the host answers at any layer:

ping -c 4 <host>
arping -c 3 -I <iface> <host-ip> 2>/dev/null     # same subnet only
ip neigh show <host-ip>

ip neigh reporting FAILED or INCOMPLETE for an address on the local subnet is the link-layer determination behind this error, stated directly.

Check for a stale neighbour entry, which produces the same symptom without the host being down:

ip neigh show
ip neigh flush dev <iface>          # forces re-resolution
ping -c 2 <host>

A host that becomes reachable immediately after a flush was never down — the cached hardware address was wrong.

Check the local side is not the problem, which separates this from -50 and -51:

ip -br link
ip route get <host-ip>

Then confirm from elsewhere. This is the step that decides whose problem it is:

# from another host on the same subnet
ping -c 3 <host>

For replication, check the partner's own state once it returns:

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

Solutions / Resolution

Treat it as a statement about the remote host, not the network. Something determined the host is down; the path to that point is working.
Confirm from a second host before escalating. If both cannot reach it, the host is the problem. If only the database host cannot, the fault is between the two and belongs elsewhere.
Flush the neighbour cache on a local subnet before concluding a host is down. A stale ARP entry produces this without anything being wrong at the far end, and the flush takes seconds.
Do not restart the instance. Nothing about the engine is at fault, and a restart during a partner outage adds a recovery nobody needed.
For replication, verify the pair explicitly once the host returns. Connections do not always re-establish silently, and the absence of further errors is not confirmation.
Expect this during a failover and judge it accordingly — the old node going away is the intended behaviour, and the error is the surviving side noticing.

Example

The link layer has already answered

$ ip neigh show 10.4.1.31
10.4.1.31 dev eth0 FAILED

$ ping -c 2 10.4.1.31
2 packets transmitted, 0 received, 100% packet loss

ARP resolution has failed, so the stack knows there is nothing at that address on this segment. This is a stronger statement than a timeout: the host is not answering at the lowest layer at which it could.

# from another host on the same subnet
$ ping -c 2 10.4.1.31
2 packets transmitted, 0 received, 100% packet loss

Confirmed from a second host, which makes it the remote machine rather than anything between. Nothing on the database host needs investigating.

Platform Note

Platform	This condition	Errno 64 there means
Linux	errno 112	`ENONET` — Machine is not on the network
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 64	this condition

ENONET at 64 on Linux is itself a "cannot reach the network" error, which makes the two easy to conflate — but it concerns this host's own attachment rather than the remote host's state.

Task	Linux	Solaris	AIX
Neighbour cache	`ip neigh show`	`arp -a`	`arp -a`
Flush cache	`ip neigh flush dev <if>`	`arp -d <host>`	`arp -d <host>`
Link-layer probe	`arping`	`ping -s`, `snoop`	`arp`, `iptrace`

Related Errors / Related Topics

-65 — Host is unreachable. The more commonly reported of the pair, and what Linux usually returns for a host that is not there. Read both together.
-60 — Connection timed out. Nothing answered at all, which is a weaker statement than this one — no determination was made either way.
-51 — Network is unreachable, decided locally before a packet leaves the host.

Where -64 appears, confirm from a second host and check the neighbour cache. Those two steps establish whether the remote machine is genuinely down or the local view of it is stale.