Oninit
Talk to an expert →

Informix Error -67

-67 Too many processes.

Your application was unable to start a database server process or was unable to create a process that was needed for some subordinate function such as a REPORT TO pipe or a network-access program. 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 processes 67 EPROCLIM on BSD
The same condition on Linux 11 EAGAIN — Resource temporarily unavailable
Errno 67 on Linux 67 ENOLINK — Link has been severed

Linux has no EPROCLIM at all. It does not merely number it differently: there is no dedicated errno for "too many processes" anywhere in the Linux table.

python3 -c 'import os; print(11, os.strerror(11)); print(67, os.strerror(67))'

On Linux, a fork() that fails for want of process slots returns EAGAIN — errno 11 — so the engine reports it as -11. The full treatment is there:

Error -11 — including the detail that catches people out: RLIMIT_NPROC counts threads, not processes, and counts them per real user ID across the whole system. Informix is heavily threaded, so the limit is reached far sooner than a count of ps entries suggests.

That distinction is the reason -11 is worth reading even when the symptom looks like a simple process-count problem.

The Condition, in Short

A new process could not be created. Two limits produce it:

  • A per-user limit — RLIMIT_NPROC, set through limits.conf, a systemd unit, or a container. Reached far sooner than expected on a threaded workload.
  • A system-wide limit — the kernel's process or thread ceiling, kernel.pid_max and kernel.threads-max on Linux.

The first is much the more common, and the one that produces a failure while the host as a whole looks idle.

About the Official Text

This is one of the more useful explanations in the range, and it is accurate. It names the right sources — starting a database server process, a REPORT TO pipe, a network-access program — and it says plainly that the cause is probably a limit configured in the operating system rather than a fault.

Two things to add:

Where the limit is set matters more than its value. A limits.conf entry is ignored by a service started under systemd, which applies TasksMax and its own limits instead. A limit that looks correct in one place and is overridden in another is the usual reason a raised limit does not take effect — this is covered on -11.

Threads count. The official text speaks of processes, and on a modern Linux host the limit that bites is on threads. An instance with many virtual processors and sessions consumes the allowance in a way a process count does not reveal.

Diagnostic Checks

Confirm the symbol, which decides which page applies:

python3 -c 'import os; print(67, os.strerror(67))'
Result Meaning Read
Too many processes EPROCLIM — BSD this condition, detail on -11
Link has been severed ENOLINK — Linux errno 67 a network-filesystem condition, unrelated
Resource temporarily unavailable at 11 EAGAIN — how Linux reports it -11

Read the limit that actually applies to the running process — not the one in the configuration file:

cat /proc/<oninit-pid>/limits | grep -i processes
ls /proc/<oninit-pid>/task | wc -l          # threads, which is what counts

Count what the instance owner is using across the whole host:

ps -L -u <instance-owner> --no-headers | wc -l
ps -u <instance-owner> --no-headers | wc -l

The first number is the one measured against the limit; the second is what people usually look at.

Check the system-wide ceilings:

sysctl kernel.pid_max kernel.threads-max
cat /proc/sys/kernel/threads-max

And where systemd or a container is involved:

systemctl show <informix-unit> -p TasksMax -p LimitNPROC 2>/dev/null
cat /sys/fs/cgroup/pids.max 2>/dev/null
Solutions / Resolution
  1. Confirm the symbol. On Linux this condition arrives as -11, and errno 67 there is something else entirely.
  2. Count threads, not processes. A host with a few dozen oninit entries in ps can be holding thousands of threads against a per-user limit.
  3. Read the limit from /proc/<pid>/limits, which is the value in force. What limits.conf says may not be what the running process got.
  4. Check the systemd unit or container limits where either is in use — they override limits.conf, and this is the usual reason a raised limit changes nothing.
  5. Go to -11 for the full sequence, including the thread-counting detail and the interaction between the various places a limit can be set.
  6. Do not raise the limit without understanding the growth. A limit reached once is a capacity question; a limit reached repeatedly while the count climbs is a leak somewhere, and a higher ceiling only delays it.
Platform Note
Platform This condition Errno 67 there means
Linux EAGAIN, errno 11 — reported as -11 ENOLINK, Link has been severed
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 67, EPROCLIM this condition

EPROCLIM is a BSD-only symbol. The System V platforms and Linux both report the condition through EAGAIN instead, which is why the catalogue's own numbering is the only place this code appears at all.

Task Linux Solaris AIX
Effective limit /proc/<pid>/limits plimit <pid> ulimit -a, lsattr -El sys0
Thread count ls /proc/<pid>/task | wc -l prstat -L ps -mo THREAD
System ceiling sysctl kernel.threads-max /etc/system, prctl lsattr -El sys0 | grep maxuproc

On AIX the per-user ceiling is maxuproc, set on sys0 and changed with chdev — a system attribute rather than a per-session limit, and it does not behave like ulimit.

Related Errors / Related Topics
  • -11 — EAGAIN. Where this condition is reported on Linux and System V, and where the thread-counting detail lives.
  • -24 — Too many open files. The other per-process resource limit, frequently reached by the same workload and worth checking at the same time.
  • -12 — Cannot allocate memory. The other way a fork() fails, and one that looks identical from a script.

Where -67 appears, confirm the symbol and then read -11. On Linux this condition does not carry this number, and the limit that bites is on threads rather than processes.