Informix Error -59

-59 Too many references: can't splice.

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 — Too many references: can't splice	59	`ETOOMANYREFS` on BSD
The same condition on Linux	109	`ETOOMANYREFS` — Too many references: cannot splice
Errno 59 on Linux	59	`EBFONT` — Bad font file format, STREAMS-era

python3 -c 'import os; print(59, os.strerror(59)); print(109, os.strerror(109))'

What ETOOMANYREFS Actually Tells You

Too many references are held on a socket for the operation to proceed. In current practice that means one thing: passing file descriptors between processes over a Unix domain socket.

sendmsg() with an SCM_RIGHTS control message attaches open descriptors to a message, and the receiving process gets copies. The kernel caps how many may be in flight, and ETOOMANYREFS is what it returns when the cap is reached — either because one message carried too many descriptors, or because too many remain unreceived across the socket.

The historical BSD meaning concerned routing and multicast reference counts, and does not arise on a database server.

What This Means in Informix

No part of the engine's normal operation passes file descriptors between processes, so there is no ordinary route to this error. It is among the least likely codes in the range to be genuine.

The only realistic sources are outside the engine:

Custom code — a wrapper, an agent, or a C UDR — passing descriptors over a Unix domain socket. Rare, and if it exists you will know it does.
A supervisor or activation system that hands sockets to the processes it starts, where the database is one of several services being managed.
A container or service-manager mechanism doing socket activation.

Where none of those are in the picture, treat the number as -33 describes: nothing in the failing path could have produced it, so it is more likely residue than evidence. Establish what the engine was doing from the message log and work from the operation instead.

Diagnostic Checks

Confirm the symbol, since errno 59 on Linux is unrelated:

python3 -c 'import os; print(59, os.strerror(59)); print(109, os.strerror(109))'

Establish whether descriptor passing happens at all. If nothing in the trace uses SCM_RIGHTS, this error did not originate here:

strace -f -e trace=sendmsg,recvmsg -p <pid> 2>&1 | grep -i 'SCM_RIGHTS'

Check descriptor usage generally, since the cap interacts with the process limit:

ls -l /proc/<pid>/fd | wc -l
cat /proc/<pid>/limits | grep -i 'open files'
ss -x | head

Then look at what the engine was actually doing:

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

Solutions / Resolution

Establish whether anything is passing descriptors. If nothing is, stop treating the number as a diagnosis and work from the operation recorded beside it.
If custom code is passing descriptors, send fewer per message. The cap applies per message and to what remains unreceived; batching smaller and ensuring the receiver keeps up both help.
Make sure the receiving side is actually receiving. Descriptors that are sent and never collected accumulate against the limit, and the sender is where the error appears.
Check the process descriptor limit alongside it — see -24. The two constraints interact, and a process near its own limit reaches this sooner.
Do not raise limits speculatively. Without a confirmed SCM_RIGHTS path there is nothing for a higher limit to fix.

Platform Note

Platform	This condition	Errno 59 there means
Linux	errno 109	`EBFONT` — STREAMS-era, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 59	this condition

The BSD lineage of this error is about routing and multicast reference counts; the Linux use is descriptor passing. Both are outside anything a database workload reaches, which is why this code is rare on every platform rather than on one.

Related Errors / Related Topics

-24 — Too many open files. The descriptor limit for one process, which this interacts with and which is far more likely to be the real constraint.
-33 — the page covering stale errno values. Directly applicable: a value no call in the failing path could have produced is residue rather than evidence.
-58 — the neighbouring socket-state error, and another whose number rarely means what it appears to on a Linux host.

Where -59 appears with no descriptor passing anywhere in the path, the number is not the evidence it looks like. The message log around it is.