Oninit
Talk to an expert →

Informix Error -47

-47 Address family not supported by protocol family.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. If the error recurs, 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 — Address family not supported 47 EAFNOSUPPORT on BSD
The same condition on Linux 97 EAFNOSUPPORT
Errno 47 on Linux 47 EL3RST — Level 3 reset, STREAMS-era

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

python3 -c 'import os; print(47, os.strerror(47)); print(97, os.strerror(97))'
What EAFNOSUPPORT Actually Tells You

A socket was requested for an address family the system will not provide, or an address of one family was used with a socket of another.

In practice, on a database server, this is an IPv4-versus-IPv6 problem nearly every time.

The two common shapes:

  • IPv6 has been disabled on the host, and something asked for an AF_INET6 socket.
  • An IPv6 address is being used with an IPv4 socket, or the reverse — the address and the socket disagree about which family they belong to.
What This Means in Informix

Address family enters an Informix configuration in more places than people expect, and they can disagree with each other:

  • sqlhosts entries naming a literal address, where the literal is IPv6 and the host has IPv6 disabled.
  • A hostname that resolves to both families. This is the common and genuinely awkward case: the name has an AAAA record, resolution returns the IPv6 address first, and the host cannot use it. Nothing in the configuration is wrong — DNS changed.
  • sqlhosts protocol entries — onsoctcp and the TLI variants have their own expectations, and a protocol chosen years ago may not match how the host is addressed now.
  • A kernel or boot parameter disabling IPv6 (ipv6.disable=1, or the disable_ipv6 sysctls) while the configuration still references it.
  • Containers, where IPv6 is frequently unavailable in the namespace even though the host supports it.
  • Client connections where the client resolves a name to a family the server is not listening on — which presents on the client, not in the message log.

The characteristic case is a configuration that worked for years and then stopped, because a DNS record was added rather than because anything on the database host changed.

Common Causes
  1. IPv6 disabled on the host while the configuration or DNS still offers an IPv6 address.
  2. A name gaining an AAAA record, so resolution now returns a family the host cannot use.
  3. A literal IPv6 address in sqlhosts on an IPv4-only host.
  4. A container namespace without IPv6, running an image configured on a host that had it.
  5. Address and socket family disagreeing in a client library or a custom connection routine.
  6. A protocol entry in sqlhosts that does not match how the host is addressed.
Diagnostic Checks

Establish whether the host has IPv6 at all:

ip -6 addr
sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.default.disable_ipv6
cat /proc/net/if_inet6 2>/dev/null || echo "no IPv6"
grep -o 'ipv6.disable=[01]' /proc/cmdline

ipv6.disable=1 on the kernel command line is the strongest form — the family is not merely unconfigured, it is absent, and no sysctl will bring it back without a reboot.

Then resolve the names sqlhosts uses, both ways. This is where the mismatch usually shows:

cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
getent ahosts   <hostname>        # both families, in resolution order
getent ahostsv4 <hostname>
getent ahostsv6 <hostname>

getent ahosts returning an IPv6 address first on a host with no IPv6 is the diagnosis, and it is invisible to ping if ping falls back to IPv4.

Check what the listener is actually bound to:

ss -lntp | grep -w <port>
ss -6 -lntp
ss -4 -lntp

An IPv4-only listener with clients resolving to IPv6 fails on the client side while the server looks entirely healthy.

Check whether dual-stack binding is available, since it changes what a wildcard listener covers:

sysctl net.ipv6.bindv6only

And the engine's record:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -g ntt
Solutions / Resolution
  1. Decide which family this instance is meant to serve, and make the configuration, DNS and host agree. Most of these faults are a disagreement between three things that were each set correctly at different times.
  2. If a name now returns IPv6 and the host cannot use it, the cheapest correct fix is usually at the name — a separate name for the database address, or an A-only record — rather than disabling IPv6 estate-wide.
  3. Do not disable IPv6 to make an error go away. It works, it is frequently done, and it removes an option the rest of the estate may be relying on. If it is the right answer, it should be a decision rather than a workaround.
  4. Use a literal address in sqlhosts where the family must be certain. It removes resolution from the path entirely, at the cost of a configuration change if the address moves.
  5. Check the client side too. This error often presents to clients while the server logs nothing, because the failure happens before a connection reaches the engine.
  6. In containers, confirm the namespace rather than the host. An image that works on a dual-stack host can fail in a namespace that has no IPv6, and neither the image nor the host configuration is wrong.
  7. Re-test by connecting, not by pinging. ping may quietly choose the family that works and tell you nothing about the one the engine will use.
Examples
The name gained an AAAA record
$ getent ahosts db-prod
2001:db8:4::30  STREAM db-prod
10.4.1.30       STREAM

$ ip -6 addr | head -2
$
$ sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1

Resolution now offers IPv6 first and the host has no IPv6 at all. Nothing in sqlhosts changed; a DNS record was added elsewhere in the organisation. Either the name stops returning AAAA for this purpose, or the host gains IPv6, or sqlhosts names the literal IPv4 address.

Listening on one family, resolving to the other
$ ss -lntp | grep -w 9088
LISTEN 0 128 0.0.0.0:9088 0.0.0.0:*

$ getent ahosts db-prod | head -1
2001:db8:4::30  STREAM db-prod

The listener is IPv4-only; clients resolve to IPv6 first and fail before reaching the engine. The message log will show nothing, because no connection ever arrived.

Platform Note
Platform This condition Errno 47 there means
Linux errno 97 EL3RST — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 47 this condition
Task Linux Solaris AIX
IPv6 addresses ip -6 addr ipadm show-addr netstat -in, ifconfig -a
Disable state sysctl net.ipv6.conf.* ipadm show-if no -a, rmdev on inet6
Resolution order getent ahosts getent ahosts host, getent

The mechanism for disabling IPv6 differs sharply: a kernel parameter on Linux, interface state on Solaris, and device configuration on AIX. Check the platform's own view rather than assuming an address family is available because the software supports it.

Related Errors / Related Topics
  • -46 — Protocol family not supported. The closely related refusal, where the protocol family rather than the address family is unavailable. The two are frequently reported interchangeably.
  • -49 — Can't assign requested address. Where the family is fine and the specific address is not present on this host.
  • -43 — Protocol not supported, for a protocol the address family will not carry.

Where a configuration that worked for years stops without changing, check resolution before checking the configuration. An added AAAA record changes what the engine is handed without touching anything on the database host.