Informix Error -11

Operating-System Meaning

errno 11 is EAGAIN — and on Linux, EWOULDBLOCK is the same value, not a different one.

The official text, "No more processes", is the historic V7/BSD wording from when this errno was raised almost exclusively by a failing fork(). That meaning still exists, but it is now only one of several. Every current system renders errno 11 as "Resource temporarily unavailable", which is deliberately vague because the condition is general.

The word that matters in the modern name is temporarily. EAGAIN says the operation could not be completed right now and may succeed if retried. It is not a permanent failure, and it is not necessarily about processes at all.

Two quite different situations produce it, and they need different investigations:

	Process/thread exhaustion	Non-blocking operation
What happened	fork() or thread creation was refused	A non-blocking call had nothing to do yet
Matches the official wording?	Yes — "no more processes"	No
Where it bites	Spawning VPs, utilities, scripts	Sockets, pipes, network I/O
Typical fix	Raise a limit	Usually none; retry is correct
Urgency	High — the server may be unable to work	Low unless persistent

So the official wording is a reliable guide to only half the cases. Establish which one you have before acting, because raising process limits will do nothing for a socket that would have blocked.

What This Means in Informix

Process and thread exhaustion

This is the case the official wording describes, and on a database server it is serious — the engine may be unable to start virtual processors, spawn utilities, or run its own helper programs.

• oninit cannot create a virtual processor, at startup or when adding VPs
• ALARMPROGRAM, backup wrappers or SYSTEM calls cannot spawn a child
• onbar cannot launch its storage-manager processes
• Client connections fail where the listener cannot create a thread for them

A detail that catches people out on Linux: RLIMIT_NPROC counts threads, not processes, and it 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, and every process owned by the installation owner contributes to the same total.

Non-blocking operations

The other case is ordinary and usually benign: a non-blocking socket or pipe had no data ready, or could not accept more. Informix retries internally and nothing surfaces. It becomes visible when it persists — a saturated listener, a stalled peer, or a connection storm.

Note the relationship with -35: on Linux errno 35 is EDEADLK, and EWOULDBLOCK is errno 11 — this page. On BSD-derived systems the numbering is the other way round. If you are working from a runbook written for another platform, that is a very easy pair to transpose.

Common Causes

1. nproc (RLIMIT_NPROC) reached for the installation owner — remembering that this counts threads on Linux.
2. systemd TasksMax on the unit that starts Informix. DefaultTasksMax is commonly a percentage of pid_max and is easily hit by a threaded database; this is a modern cause with no equivalent in the older literature.
3. Container pids.max — a cgroup limit, often much lower than anything on the host.
4. System-wide limits — kernel.pid_max or kernel.threads-max.
5. A fork bomb or runaway loop in a script owned by the same account, consuming the per-user budget.
6. A connection storm exhausting listener capacity.
7. A stalled or slow peer on a non-blocking socket, where the would-block condition persists rather than clearing.

Diagnostic Checks

First decide which of the two cases you are in. If the failure was fork() or thread creation, it is exhaustion; if it was a read, write, accept or connect, it is a non-blocking condition:

strace -f -p "$pid" 2>&1 | grep EAGAIN | tail -20
# clone(...)  = -1 EAGAIN   -> exhaustion
# read(9,...) = -1 EAGAIN   -> non-blocking, usually benign

If it is exhaustion

Count what the installation owner is actually using, in threads:

ps -eLf | wc -l                                   # threads, system-wide
ps -L -u "$(id -un)" -o pid= | wc -l              # threads for this user
ps -o nlwp= -C oninit | awk '{s+=$1} END {print s}'  # threads in oninit

Then the limits, in the order they bite:

ulimit -u                     # soft nproc for this shell
ulimit -Hu                    # hard
grep -rn nproc /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null

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

Check systemd, which overrides limits.conf for anything it starts:

systemctl show <informix-unit> -p TasksMax -p TasksCurrent -p LimitNPROC
systemctl show -p DefaultTasksMax
cat /sys/fs/cgroup/system.slice/<unit>/pids.max     # cgroup v2

A TasksCurrent sitting just under TasksMax is the answer, and it will not appear in ulimit output at all — which is why this cause is so often missed.

In a container:

cat /sys/fs/cgroup/pids.max              # cgroup v2
cat /sys/fs/cgroup/pids/pids.max         # cgroup v1
cat /sys/fs/cgroup/pids.current

Check whether something is simply running away:

ps -u "$(id -un)" -o pid,ppid,nlwp,etime,cmd --sort=-nlwp | head -20
ps -u "$(id -un)" --no-headers | wc -l

If it is a non-blocking condition

onstat -g ntu          # network user threads
onstat -g ntt          # network transfer statistics
onstat -g ses
ss -s
ss -ltn
netstat -s | grep -iE 'overflow|dropped|listen'

Persistent listen-queue overflows point at connection rate rather than at any limit, and the remedy is in listener configuration and client connection behaviour, not in nproc.

Solutions / Resolution

1. Identify the case first. Raising nproc for a socket that would have blocked wastes time and changes nothing.

For exhaustion:

2. Raise nproc for the installation owner in /etc/security/limits.d/, remembering it counts threads on Linux:

   ifxprod  soft  nproc  16384
   ifxprod  hard  nproc  32768
   

3. Set TasksMax on the systemd unit if Informix is started that way. This is the step most often skipped, because limits.conf appears correct and has simply been overridden:

   [Service]
   TasksMax=infinity
   LimitNPROC=32768
   

   followed by systemctl daemon-reload and a restart of the unit.
4. Raise the container's pids.max where a cgroup is the constraint — in the pod or container spec, not inside the running container.
5. Raise kernel.pid_max / kernel.threads-max only if the system-wide values are genuinely the binding constraint, which is less common than the per-user and cgroup limits.
6. Find the runaway if counts are unexpectedly high. A limit reached because something is looping is not fixed by raising the limit.

For the non-blocking case:

7. Usually do nothing. A transient EAGAIN on a socket is normal and is retried internally.
8. If it persists, treat it as capacity: look at connection rate, listener threads and poll threads in NETTYPE, and at the responsiveness of the peer — not at process limits.

Examples

limits.conf is correct and systemd overrides it

$ ulimit -u
32768
$ grep nproc /etc/security/limits.d/informix.conf
ifxprod soft nproc 32768
ifxprod hard nproc 65536

$ systemctl show informix -p TasksMax -p TasksCurrent
TasksMax=4915
TasksCurrent=4912

Everything the administrator checked looks right. The unit is twelve tasks from its ceiling, and TasksMax is what the kernel is actually enforcing. This is the most common presentation of -11 on a modern Linux host and it is invisible to ulimit.

The limit counts threads, not processes

$ ps -u ifxprod --no-headers | wc -l
38
$ ps -L -u ifxprod -o pid= | wc -l
9974
$ ulimit -u
10240

Thirty-eight processes, nearly ten thousand threads, against a limit of 10,240. Counting processes suggests enormous headroom; the limit is about to be hit. On Linux RLIMIT_NPROC is a thread limit in all but name.

A benign non-blocking read

$ strace -f -p 4471 2>&1 | grep EAGAIN | head -3
[pid 4471] read(12, 0x7f3c40, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 4471] read(12, 0x7f3c40, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 4471] read(12, 0x7f3c40, 4096) = -1 EAGAIN (Resource temporarily unavailable)

Repeated reads on a socket with nothing to deliver. This is a poll loop working correctly, not a fault, and no limit anywhere is involved. If a -11 was reported to a user at the same moment, the two are probably unrelated.

Platform Note

errno 11 is EAGAIN on Linux, AIX, Solaris, HP-UX and the BSD-derived systems, so the number is stable. Whether EWOULDBLOCK shares that value is not. On Linux and most modern systems they are identical; historically on some BSD-derived platforms they were distinct values, and code written to distinguish them behaves differently after a port.

The wording has drifted furthest here of any error in this range. "No more processes" describes only the fork() case, and a reader who takes it literally will investigate process limits for what is often a socket condition.

Where the limits live also varies:

Task	Linux	Solaris	AIX
Per-user process/thread limit	limits.conf nproc, systemd TasksMax	project.max-lwps (projmod)	/etc/security/limits, maxuproc
System-wide	kernel.pid_max, threads-max	zone.max-lwps	maxuproc (chdev -l sys0)
Container/zone	cgroup pids.max	zone max-lwps	WPAR limits

On AIX, maxuproc is the value to check first and is set with chdev -l sys0 -a maxuproc=…. On Solaris, the project framework rather than limits.conf governs this, and a process may be in an unexpected project.

Related Errors / Related Topics

• -35 — Operation would block, per this catalogue's wording. On Linux errno 35 is actually EDEADLK while EWOULDBLOCK is errno 11. The two pages are easy to transpose and it is worth reading both before concluding anything from the number.
• -12 — Not enough memory. The other resource-exhaustion error, and one that often accompanies -11 when a host is under real pressure.
• -24 / -23 — File-descriptor exhaustion for the process and for the system. If threads are near their limit, descriptors usually are too.

Persistent -11 on a production instance is a capacity signal rather than a single incident. Thread counts against TasksMax and nproc, and listener queue depth, are the two things worth watching continuously — both give warning well before the engine is unable to start work.