Informix Error -46
-46 Protocol family not supported.
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
errnovalues whose meanings vary between Unix platforms and versions. Confirm the nativeerrnodefinition 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 — Protocol family not supported | 46 | EPFNOSUPPORT on BSD |
| The same condition on Linux | 96 | EPFNOSUPPORT |
| Errno 46 on Linux | 46 | EL3HLT — Level 3 halted, STREAMS-era |
Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux.
python3 -c 'import os; print(46, os.strerror(46)); print(96, os.strerror(96))'
What EPFNOSUPPORT Actually Tells You
The protocol family requested at socket creation is not supported — PF_INET, PF_INET6, PF_UNIX and their relatives.
In practice this is very hard to separate from -47 (EAFNOSUPPORT, address family not supported). The protocol family and address family constants are numerically identical on every platform in common use, stacks return one or the other according to their own conventions, and the two are frequently interchangeable in documentation as well as in code.
Treat -46 and -47 as the same investigation. The substance — almost always an IPv4 versus IPv6 mismatch — is set out on -47, which is the more commonly reported of the two.
What This Means in Informix
The same contexts as -47:
- IPv6 disabled on the host while
sqlhostsor DNS still offers an IPv6 address. - A hostname that has gained an
AAAArecord, so resolution returns a family the host cannot use — the case that breaks a configuration which changed nothing. - A literal IPv6 address in
sqlhostson an IPv4-only host. - A container namespace without IPv6, running an image built on a dual-stack host.
- A
sqlhostsprotocol entry that does not match how the host is addressed, which is closer to -43.
Common Causes
- IPv6 unavailable where the configuration or DNS expects it.
- A name resolving to a family the host cannot use.
- A kernel parameter disabling IPv6 while the configuration still references it.
- A container namespace without the family the image assumes.
- A protocol family requested by client code that the platform does not provide.
Diagnostic Checks
The checks are those on -47, and are repeated here in short form:
python3 -c 'import os; print(46, os.strerror(46)); print(96, os.strerror(96))'
ip -6 addr
sysctl net.ipv6.conf.all.disable_ipv6
grep -o 'ipv6.disable=[01]' /proc/cmdline
cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
getent ahosts <hostname>
getent ahostsv4 <hostname>
getent ahostsv6 <hostname>
ss -lntp | grep -w <port>
ss -4 -lntp; ss -6 -lntp
Trace the failing call to see exactly which family was requested, since that is the one detail neither the configuration nor the log will give you:
strace -f -e trace=socket -p <pid> 2>&1 | grep -iE 'EPFNOSUPPORT|EAFNOSUPPORT'
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
The traced line names the family directly, and shows why the two errors are so hard to tell apart — the stack may report either symbol for the same request.
Solutions / Resolution
- Read -47 and work from there. The two errors describe one problem and the material is not worth duplicating; -47 carries the detail.
- Establish which family the host actually provides before changing any configuration.
- Fix it at the name where resolution is the cause. An added
AAAArecord is the usual trigger, and the cheapest correct fix is usually a name that returns only what this host can use. - Do not disable IPv6 to clear the error unless that is a decision you would defend on its own terms.
- Check the client side as well as the server, since this frequently fails before a connection reaches the engine and leaves nothing in the message log.
Platform Note
| Platform | This condition | Errno 46 there means |
|---|---|---|
| Linux | errno 96 | EL3HLT — STREAMS-era, unrelated |
| Solaris, AIX, HP-UX | confirm on the host | confirm on the host |
| BSD, Darwin | errno 46 | this condition |
Whether a given stack returns EPFNOSUPPORT or EAFNOSUPPORT for an unavailable family is a property of that stack rather than of the request. Do not read anything into which of the two you were given.
Related Errors / Related Topics
- -47 — Address family not supported by protocol family. The same problem, more commonly reported, and where the full material lives.
- -43 — Protocol not supported, where the protocol rather than the family is refused. Note that on Linux errno 43 is
EIDRM, a serious and unrelated condition. - -44 — Socket type not supported, the remaining member of the same family of refusals.
A -46 and a -47 are one investigation. Start at -47.