Informix Error -41

-41 Protocol wrong type for socket.

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

Platform family	errno 41	Meaning
Linux (glibc)	none	There is no errno 41 on Linux
Solaris, AIX, HP-UX (System V)	`ELNRNG`	Link number out of range
BSD, macOS/Darwin	`EPROTOTYPE`	Protocol wrong type for socket

The official text — Protocol wrong type for socket — is EPROTOTYPE, the BSD value.

On Linux, 41 Is Not an Error Number

The Linux table has a gap at 41. Errno 40 is ELOOP and errno 42 is ENOMSG; nothing occupies the value between them:

$ python3 -c 'import os; [print(n, os.strerror(n)) for n in (40,41,42)]'
40 Too many levels of symbolic links
41 Unknown error 41
42 No message of desired type

grep -nE ' (40|41|42)$' /usr/include/asm-generic/errno.h

Unknown error 41 is glibc saying it has no name for the value, not a description of a condition.

Why the code exists at all

The entry is a historical artifact. Informix's message catalogue carries the BSD errno numbering — the same lineage visible at -35 (Operation would block), -36 (Operation now in progress) and -39 (Destination address required), none of which match Linux or System V either. On BSD, errno 41 is EPROTOTYPE, so the catalogue has an entry for it.

Linux never adopted that value. The code is in the catalogue because of where the catalogue came from, not because a Linux system can produce it.

If one is actually reported on a Linux host

No Linux call returns errno 41, so the value reached the log by another route:

A stale errno — a value left in the global by something earlier and read by code that had not checked a failure of its own. The mechanism described on -33.
A value propagated from elsewhere — a wrapper, a storage manager, a client on another platform, or a script that captured a number and passed it on.
A non-errno value reported through the errno path — an exit status, a library-specific code, or an internal value that landed in this range.

In each case the number describes nothing. Establish what the engine was doing from the message log and work from the operation.

On the System V Platforms

ELNRNG — Link number out of range — is one of the STREAMS-era device errors. It concerns character device link numbers in a subsystem that no database workload touches.

A -41 on Solaris, AIX or HP-UX is therefore either a genuine fault in something unusual at the device layer, or the same residual-value situation as above. Confirm the symbol, then treat the value with the same suspicion.

On the BSD-Derived Platforms

EPROTOTYPE means a socket was created with a protocol that does not match its type — SOCK_STREAM with a datagram protocol, or the reverse. It is a programming error in socket setup rather than a runtime condition.

Informix's supported platforms do not include the BSD-derived systems, so this meaning is here because it is the one the official text describes.

Diagnostic Checks

Confirm what the number means on the host, which on Linux means confirming that it means nothing:

python3 -c 'import os; print(os.strerror(41))'
perl -e '$! = 41; print "$!\n"'
grep -w 41 /usr/include/asm-generic/errno.h        # Linux — expect no match
grep -w 41 /usr/include/sys/errno.h                # Solaris, AIX, HP-UX

Then establish what the engine was actually doing. With no meaningful errno, the surrounding context is the only evidence:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -m
onstat -

Look for a more specific Informix error recorded alongside it. Where the number is meaningless, whatever the engine said in its own words is the whole of what you have:

grep -n -iE 'error|ISAM|assert|session' "$INFORMIXDIR/tmp/online.log" | tail -40
ls -lt "$(grep -E '^DUMPDIR' "$INFORMIXDIR/etc/$ONCONFIG" | awk '{print $2}')" 2>/dev/null | head

If a wrapper or an external program is in the path, check whether it is passing through a value of its own:

grep -rn -E 'errno|\$\?|exit' /path/to/wrapper.sh
tail -100 "$BAR_ACT_LOG" 2>/dev/null

Solutions / Resolution

On Linux there is no operating-system error with this number. The catalogue entry is a historical artifact of the BSD numbering the message catalogue was built from, so the code names no condition a Linux kernel can report. Work from the operation the engine was performing instead.
Find the specific Informix error beside it. On a current version the engine will usually have reported something more precise; that report is the evidence.
Check any wrapper in the path for a captured value being propagated as though it were an errno. A script that stores $? and reports it as a system error produces exactly this.
On the System V platforms, confirm the symbol first. ELNRNG is real there, but a device-layer condition that a database workload would not normally reach — so a residual value remains the more likely explanation.
Do not raise a support case on the number alone. Collect the message log around the event, the instance state, and any assert-failure files; the errno adds nothing.

Platform Note

Platform	errno 41	Realistic here
Linux	(unused)	No — the value has no meaning
Solaris	`ELNRNG`	Rarely — STREAMS-era device layer
AIX	`ELNRNG`	Rarely
HP-UX	`ELNRNG`	Rarely
BSD, Darwin	`EPROTOTYPE`	Not a platform Informix runs on

Gaps in the Linux errno table are not unusual — the numbering was assembled from several lineages and not every value was filled. The practical consequence is that a number falling in this range is not proof it came from the operating system, and this code is the clearest demonstration of it.

Related Errors / Related Topics

-33 — EDOM on every platform, and the page covering stale errno values in detail. The reasoning applies directly here: a value that no call in the failing path could have produced is residue rather than evidence.
-40 — ELOOP on Linux, the last defined value before the gap.
-35 — where the divergence between the numbering families begins, and why the symbol has to be confirmed before the number is used.

Where -41 appears on Linux, the useful record is the operation and the message log around it. The number itself can be set aside.