Informix Error -68

-68 Too many users.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. This error probably reflects a limit configured in your operating system. Look for other operating-system error messages that might give more information.

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 users	68	`EUSERS` on BSD
The same symbol on Linux	87	`EUSERS` — Too many users
Errno 68 on Linux	68	`EADV` — Advertise error, STREAMS-era

python3 -c 'import os; print(68, os.strerror(68)); print(87, os.strerror(87))'

What EUSERS Actually Tells You

Historically, that the filesystem quota table is full — too many users hold quota entries for another to be added. It is a BSD-era condition tied to how disk quotas were once implemented.

Linux defines the symbol at errno 87, but essentially nothing returns it. It is one of the least-used values in the table on any current platform.

This is not a limit on how many users can connect to anything. The wording invites that reading, and it is wrong. A connection or session limit is not what this error reports — see -67 for process limits and -24 for descriptors, which are the constraints that actually bite on a busy instance.

What This Means in Informix

There is no ordinary route to this error from the engine. Informix does not manipulate quota tables, and nothing in its normal operation produces EUSERS on any supported platform.

Where a -68 appears, the realistic explanations are:

A quota system on a filesystem the instance writes to, on a platform where the quota table can fill. Rare, and a filesystem-administration matter rather than a database one.
A stale errno, as described on -33 — a value left in the global and read by something that had not checked a failure of its own. Given how little produces EUSERS, this is the more likely of the two.
A value propagated from a wrapper or another platform.

Do not read it as a user or connection limit. If the symptom is that users cannot connect, the cause is almost certainly elsewhere: -61 if connections are refused, -48 or -49 if the listener never bound, -67 or -24 if a resource limit has been reached.

About the Official Text

The catalogue says this "probably reflects a limit configured in your operating system", which is reasonable as far as it goes — quota configuration is exactly that.

It is worth reading narrowly, though. The limit in question is on quota table entries, not on users of the database, and the error does not indicate that the instance has run out of capacity for sessions.

Diagnostic Checks

Confirm the symbol, since errno 68 on Linux is EADV and unrelated:

python3 -c 'import os; print(68, os.strerror(68)); print(87, os.strerror(87))'

Establish whether quotas are in use at all. If they are not, the value did not come from this condition:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -iE 'quota|usrquota|grpquota'
quotaon -p -a 2>/dev/null
repquota -a 2>/dev/null | head

Then look at what the engine was actually doing, which is the evidence when the number is not:

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

If the reported symptom is users being unable to connect, check the things that genuinely cause that:

onstat -                       # is the instance up
ss -lntp | grep -w <port>      # is anything listening — see -61, -48, -49
onstat -g ses | wc -l
cat /proc/<oninit-pid>/limits  # see -67, -24

Solutions / Resolution

Do not treat this as a connection limit. The wording is misleading and the error is about quota table entries.
Check whether quotas are configured on the filesystems the instance uses. If they are not, the number is residue — see -33.
If quotas are in use and the table is full, that is a filesystem administration task: prune unused quota entries or raise the table size on platforms where it is fixed.
If users genuinely cannot connect, investigate that separately. -61, -48, -49, -67 and -24 are the codes that describe the real causes.
Check for a related quota error. -69 (EDQUOT, disk quota exceeded) is the quota condition an instance realistically meets, and it is a different and more useful error.

Platform Note

Platform	This condition	Errno 68 there means
Linux	`EUSERS` exists at 87 but is effectively unused	`EADV` — STREAMS-era, unrelated
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 68	this condition

The quota implementations differ enough that a fixed quota table is largely a historical arrangement. On current systems quota entries are not generally constrained in a way that produces this error, which is why it is rare everywhere rather than on one platform.

Task	Linux	Solaris	AIX
Quota state	`quotaon -p -a`, `repquota`	`quota -v`, `quotacheck`	`quotacheck`, `repquota`
Mount options	`findmnt -o OPTIONS`	`mount -v`	`lsfs -q`

Related Errors / Related Topics

-69 — Disc quota exceeded (EDQUOT). The quota error an instance realistically meets, when a write exceeds an allowance. Far more useful than this one.
-67 — Too many processes. A real limit that a busy instance does reach, and one this error is easily confused with on the strength of its wording.
-33 — the page covering stale errno values, which is the more likely explanation for a -68 on a host without quotas.

Where -68 appears, check whether quotas are configured before anything else. If they are not, the number is not describing the failure and the message log beside it is.