Informix Error -60

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 timed out	60	ETIMEDOUT on BSD
The same condition on Linux	110	ETIMEDOUT
Errno 60 on Linux	60	ENOSTR — Device not a stream, STREAMS-era

python3 -c 'import os; print(60, os.strerror(60)); print(110, os.strerror(110))'

The official text mentions Informix STAR and Informix NET, which dates it. The condition it names is current and common.

What ETIMEDOUT Actually Tells You

Nothing answered. Not a refusal, not an error — silence, for long enough that the stack gave up.

That is the entire diagnostic value of this error, and it comes from comparing it with its neighbours:

Error	Symbol	Linux	What came back
-61	ECONNREFUSED	111	A RST. Something answered and declined
-60	ETIMEDOUT	110	Nothing at all
-65	EHOSTUNREACH	113	An ICMP unreachable from a router
-51	ENETUNREACH	101	Nothing left the host — no route locally

This distinction identifies the cause more reliably than anything else available. A packet that reaches a listening host and finds nothing on the port earns a RST — refused, immediately. A packet that is silently discarded earns nothing — timed out, slowly.

So the error tells you how the obstruction behaves:

• A firewall rule with DROP discards silently → timeout.
• A firewall rule with REJECT sends a refusal → -61.
• A host that is down does not answer → timeout (or an ICMP unreachable from its router, → -65).
• A listener that is not there on a reachable host → -61.

The timing is a second clue. A connect timeout is slow and consistent — the stack retransmits on a fixed schedule before giving up — while a refusal is immediate. If the failure takes the same conspicuous number of seconds every time, that is the retransmission schedule expiring, not a variable network condition.

Two different timeouts

ETIMEDOUT covers two situations that are worth separating:

• A connect that never completed. SYN sent, nothing came back, retransmissions exhausted. Governed on Linux by tcp_syn_retries.
• An established connection that stopped responding. Data was sent, acknowledgements stopped, retransmissions exhausted. Governed by tcp_retries2, and by keepalive where the connection was idle.

The first fails at connection time and affects new work only. The second takes down sessions that were running, and the delay before it is noticed can be many minutes.

What This Means in Informix

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

• HDR, RSS or ER reaching a replication partner. The most consequential case, because a link that times out rather than being refused usually means the partner or the path is gone rather than merely unready.
• Connection Manager reaching an instance it proxies for.
• A distributed query opening a connection to another server in sqlhosts.
• onbar reaching a storage manager on another host.
• An ALARMPROGRAM or monitoring script sending outward.

On the client side, the same condition is what users describe as the application "hanging" before failing — the retransmission schedule is long enough that it looks like a hang rather than an error.

Client-side connection retry behaviour is configurable through the Informix client environment — INFORMIXCONTIME and INFORMIXCONRETRY govern how long and how often a connection is attempted. Check your version's documentation for their exact semantics before changing them; raising them makes an unreachable server take longer to report, which is rarely what anyone wants.

The pattern worth recognising: a timeout that is identical from one host and absent from another is a path problem, not a server problem. The server cannot distinguish between the two, and neither can the error.

Common Causes

1. A firewall dropping silently rather than rejecting — the commonest cause of a timeout as opposed to a refusal.
2. The remote host down, or its interface down, with nothing answering.
3. A routing problem somewhere along the path, where packets leave but nothing returns.
4. An asymmetric path — the request arrives, the reply takes a route that does not work.
5. A partner in a failed state, accepting nothing while remaining pingable.
6. A saturated link or device discarding under load, which makes the failure intermittent.
7. An established session losing its path, surfacing minutes later when retransmissions expire.

Diagnostic Checks

Confirm the symbol, since errno 60 on Linux is a STREAMS value:

python3 -c 'import os; print(60, os.strerror(60)); print(110, os.strerror(110))'

Distinguish timeout from refusal directly. This is the fastest way to learn what is on the other end:

timeout 30 bash -c 'cat < /dev/null > /dev/tcp/<host>/<port>' ; echo "exit=$?"
nc -vz -w 30 <host> <port>

An immediate Connection refused is -61 and a different investigation. A long wait ending in failure is this error.

Check the local routing decision first — it separates this from -51:

ip route get <destination-ip>
ip -br addr

Then establish whether anything is answering at any layer:

ping -c 4 <host>
traceroute -n -T -p <port> <host> 2>/dev/null || tracepath -n <host>
arping -c 3 -I <iface> <host> 2>/dev/null     # same subnet only

Ping succeeding while the port times out is the firewall-DROP signature.

Measure the timeout, because a consistent duration identifies the retransmission schedule rather than a variable fault:

time nc -vz -w 300 <host> <port>
sysctl net.ipv4.tcp_syn_retries
sysctl net.ipv4.tcp_retries2

Check the counters for evidence of abandoned attempts:

nstat -az | grep -iE 'TcpAttemptFails|TcpExtTCPTimeouts|TcpRetransSegs'
netstat -s | grep -iE 'timeout|retransmit|failed'
ss -antp | awk '$1=="SYN-SENT"' | head

Sockets stuck in SYN-SENT are connections in progress that will become this error.

For replication, establish the partner's state independently:

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

Capture, if the path is disputed:

tcpdump -nni any "host <host> and tcp port <port>" -c 40

Outbound SYN with no reply at all is conclusive, and it moves the question off the database host entirely.

Solutions / Resolution

1. Establish timeout versus refusal before anything else. They point in opposite directions — silence means something is discarding or absent, a refusal means something answered. One command distinguishes them.
2. If ping works and the port times out, look at filtering. That combination is close to diagnostic for a DROP rule somewhere in the path.
3. Take the evidence to the network team in a usable form. Destination, port, ip route get output, whether ICMP answers, and a capture showing unanswered SYNs. That is a complete report; "the database cannot connect" is not.
4. Do not raise client connection timeouts to make it go away. Longer timeouts make an unreachable server fail more slowly, which converts a clear error into an apparent hang.
5. For replication, check the partner directly rather than inferring from the timeout. A partner that is up but not accepting is a different fault from one that is gone.
6. Where it is intermittent, suspect load or an asymmetric path rather than configuration. A rule that blocks does so every time; a saturated device does not.
7. For established sessions timing out, expect a delay between the path failing and the error appearing. The event is minutes older than the log entry, which matters when correlating with anything else.
8. Ask whether REJECT would be better than DROP where the filtering is yours. A refusal fails fast and says so; a silent drop costs every client the full retransmission schedule.

Examples

Ping answers, the port does not

$ ping -c 3 hdr-partner
3 packets transmitted, 3 received, 0% packet loss

$ time nc -vz -w 300 hdr-partner 9088
nc: connect to hdr-partner port 9088 (tcp) timed out: Operation now in progress
real    2m7.019s

The host is up and answering ICMP; the port is silent. Two minutes and seven seconds is the retransmission schedule expiring, not a variable condition — the same duration will recur every time.

Nothing is wrong with the partner's reachability. Something between the two hosts is discarding the connection attempt without answering.

The same connection from two hosts

# from the database host
$ nc -vz -w 30 storage-mgr 1556
nc: connect to storage-mgr port 1556 (tcp) timed out

# from another host on a different subnet
$ nc -vz -w 30 storage-mgr 1556
Connection to storage-mgr 1556 port [tcp/*] succeeded!

The service is running and reachable. What differs is the path, which makes this a filtering or routing question about one subnet rather than anything to do with the storage manager or the instance.

Platform Note

Platform	This condition	Errno 60 there means
Linux	errno 110	ENOSTR — STREAMS-era, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 60	this condition

Task	Linux	Solaris	AIX
Retransmission tunables	sysctl net.ipv4.tcp_syn_retries	ipadm show-prop -p _tcp_ip_abort_cinterval tcp	no -o tcp_keepinit
TCP counters	nstat, netstat -s	netstat -s -P tcp, kstat	netstat -s -p tcp
Path test	tracepath, traceroute -T	traceroute, traceroute -P tcp	traceroute

The connect-timeout duration is tunable on every platform and defaults differently on each, so the same unreachable host fails after markedly different intervals depending on where you are testing from. Establish the local value before reading anything into how long it took.

Related Errors / Related Topics

• -61 — Connection refused. Something answered and declined. The single most useful comparison on this page: refusal means reachable, timeout means silent.
• -65 — Host is unreachable. A router replied that it could not deliver, which is a third outcome distinct from both silence and refusal.
• -54 — Connection reset by peer, for connections that were established and then aborted.

Where a connection times out, test the same destination from another host before investigating the database. The error cannot distinguish a blocked path from an absent service, and that comparison can.