Oninit
Talk to an expert →

Informix Error -55

-55 No buffer space available.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. Look for other operating-system error messages that might give more information, especially which file or files are involved. 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 — No buffer space available 55 ENOBUFS on BSD
The same condition on Linux 105 ENOBUFS
Errno 55 on Linux 55 ENOANO — No anode, STREAMS-era

-55 is the last code in the BSD socket block, and the last operating-system error in the catalogue — the next entry is -201.

python3 -c 'import os; print(55, os.strerror(55)); print(105, os.strerror(105))'
What ENOBUFS Actually Tells You

The kernel could not obtain the memory it needed for a network operation. Not the process's memory — the kernel's own socket buffer memory, which is a separate and much smaller pool.

That distinction is what makes this error confusing in practice: a host with tens of gigabytes free can return ENOBUFS, because the constraint is a kernel allocation limit rather than available RAM.

Separate it from the two errors it is mistaken for:

Error Symbol What ran out
-55 ENOBUFS Kernel socket buffer memory, or a queue
-12 ENOMEM Process address space or system memory
-23 ENFILE File descriptors, system-wide

ENOBUFS is also, on Linux, what a full transmit queue returns — which has nothing to do with memory pressure and everything to do with an interface being unable to send fast enough.

What This Means in Informix

The engine holds one socket per connected session plus its listeners, and replication and Connection Manager add more. The realistic sources:

  • A very large number of sessions, each with send and receive buffers charged against the kernel's socket memory budget.
  • Socket buffer sizes raised deliberately — a tuning change that multiplies across every connection and reaches the global limit far sooner than expected.
  • A full transmit queue on a saturated interface, or one with a small txqueuelen under a bursty workload.
  • Replication traffic — HDR, RSS or ER shipping a backlog after a period of disconnection, which is exactly when the volume is highest.
  • Memory fragmentation, where the kernel cannot find contiguous allocations even though the total is available.
  • A container with a memory limit counting kernel memory against it.

The signature is that it appears under load and disappears afterwards. That makes it easy to dismiss and hard to reproduce, and it means the diagnosis has to be collected while it is happening.

Common Causes
  1. Socket memory limits reached with a high session count.
  2. Enlarged socket buffers multiplied across many connections.
  3. Transmit queue full on a saturated or slow interface.
  4. A replication backlog shipping at full rate after a reconnection.
  5. Kernel memory fragmentation under sustained pressure.
  6. A container memory limit including kernel memory.
  7. A network driver or firmware problem dropping and requeuing.
Diagnostic Checks

Look at socket memory against its limits, not at free RAM:

cat /proc/net/sockstat
cat /proc/net/sockstat6 2>/dev/null
sysctl net.ipv4.tcp_mem net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

/proc/net/sockstat reports pages allocated for TCP memory; compare it against the third value of tcp_mem, which is the pressure ceiling. That comparison is the direct answer and free memory is irrelevant to it.

Check for drops and queue overflows, which distinguish the transmit-queue case from the memory case:

ip -s link
netstat -i
nstat -az | grep -iE 'drop|nobuf|overrun|prune'
netstat -s | grep -iE 'prune|collapse|drop|overflow'

TcpExtTCPRcvQDrop, pruning counters, or rising interface drops point at queues rather than at the socket memory pool.

Check the transmit queue length on the interfaces carrying database traffic:

ip -d link show | grep -A1 qlen
tc -s qdisc show dev <iface>

Count what the engine is holding:

onstat -g ses | wc -l
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
onstat -g ntu
onstat -g ntt

Check kernel memory availability and fragmentation:

grep -E 'Slab|SUnreclaim|MemAvailable' /proc/meminfo
cat /proc/buddyinfo
dmesg -T | grep -iE 'page allocation failure|order:|out of memory'

A page-allocation failure in dmesg at the time of the error confirms fragmentation rather than exhaustion, which is a different remedy.

In a container, check the limit that applies there:

cat /sys/fs/cgroup/memory.max 2>/dev/null
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null
cat /sys/fs/cgroup/memory.stat 2>/dev/null | grep -i sock
Solutions / Resolution
  1. Collect the evidence while it is happening. This error is transient by nature, and /proc/net/sockstat after the load has gone tells you nothing. A short sampling loop during the busy period is worth more than a long investigation afterwards.
  2. Distinguish the socket-memory case from the queue case first. Rising interface drops with healthy socket memory is a queue problem; socket memory near tcp_mem's ceiling is the other. The remedies do not overlap.
  3. Raise socket memory limits deliberately, not reflexively. tcp_mem, rmem_max and wmem_max can be increased, but they are a budget for the whole host. Raising them to accommodate a session count that should not be that high moves the problem rather than solving it.
  4. Reconsider enlarged per-socket buffers. A size that is sensible for a handful of high-throughput connections is very different multiplied by several hundred sessions. This is the most common self-inflicted cause.
  5. Reduce the session count if it is the real constraint. Connection pooling at the application, or Connection Manager, addresses the cause where tuning only raises the ceiling.
  6. For a full transmit queue, look at the interface — its speed, its errors, its queue discipline, and whether the traffic is genuinely bursty. txqueuelen can be raised, but a saturated interface is a capacity question.
  7. If replication backlog is the trigger, expect it after every reconnection. The peak occurs precisely when a partner comes back, so the host has to be sized for that moment rather than for steady state.
  8. If dmesg shows page-allocation failures, treat it as fragmentation. Raising limits will not help; the kernel could not find contiguous memory, and that is a memory-pressure problem elsewhere on the host.
Examples
Plenty of free memory, and still no buffers
$ grep MemAvailable /proc/meminfo
MemAvailable:   41203488 kB

$ cat /proc/net/sockstat
sockets: used 3412
TCP: inuse 3180 orphan 12 tw 840 alloc 3244 mem 184320
...

$ sysctl net.ipv4.tcp_mem
net.ipv4.tcp_mem = 185940 247920 371880

Forty gigabytes available, and TCP memory at 184,320 pages against a pressure threshold of 185,940. The kernel is at its socket-memory budget while the host is nowhere near out of RAM. Free memory was never the constraint.

The interface, not the memory
$ ip -s link show eth0 | sed -n '4,6p'
    RX: bytes  packets  errors  dropped overrun mcast
    9182736451 84729183 0       0       0       0
    TX: bytes  packets  errors  dropped overrun carrier
    7261837261 71827361 0       284917  0       0

Transmit drops climbing with socket memory healthy. This is queueing, not allocation — and raising tcp_mem would change nothing.

Platform Note
Platform This condition Errno 55 there means
Linux errno 105 ENOANO — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 55 this condition
Task Linux Solaris AIX
Socket memory /proc/net/sockstat, ss -s netstat -s, kstat netstat -m, no -a
Buffer tunables sysctl net.ipv4.tcp_*mem ipadm show-prop tcp no -o tcp_sendspace, tcp_recvspace
Interface drops ip -s link netstat -i, dladm show-link -s entstat -d <adapter>

On AIX, netstat -m reports mbuf and cluster usage directly and is the first command to run; entstat -d gives the adapter's own view. Neither has a close Linux equivalent, and on AIX this error is more often diagnosed from those two than from anything else.

Related Errors / Related Topics
  • -12 — Cannot allocate memory. Process or system memory rather than the kernel's socket pool. The two are routinely conflated and the checks are entirely different.
  • -23 — Too many open files in system. The other host-wide resource a high session count exhausts, and worth checking at the same time.
  • -54 — Connection reset by peer. What clients often see while a host is in this state, since connections fail in ways that look like network faults.

Where -55 appears under load, sample /proc/net/sockstat and ip -s link during the busy period rather than investigating afterwards. The condition clears when the load does, and with it the only evidence that distinguishes a memory limit from a queue.