Informix Error -156: ISAM error: Cannot attach to shared memory.

Reasons / Common Causes

-156 is the sibling of -123, but a different specific failure: -123 means the shared-memory segment doesn't exist at all; -156 means a segment exists, but this particular process failed to attach to it. The official guidance's own framing — check OS messages, verify no system limit or local problem exists, then escalate — reflects that the cause is almost always something specific to the local process or user context, not the segment itself.

1. A permission mismatch — the connecting process or user doesn't have the correct permissions on the shared-memory segment (ownership, group, or mode bits not matching what's expected for this connection).
2. A per-process or per-user shared-memory attachment limit reached — a system-level limit on how many segments a single process or user can attach to, hit even though the specific segment and system-wide totals are otherwise fine.
3. Address space conflicts, on certain platforms — the requested or preferred attach address already in use by something else within this specific process's address space, causing the attach itself to fail even though the segment exists and is otherwise accessible.
4. OS-level resource limits (ulimit, or equivalent) constraining shared-memory attachment for this specific user or process context.
5. A process running in a different namespace or container without visibility to, or permission for, the host's shared-memory segment — the same general theme as one of -123's causes, but manifesting here as a failed attach rather than "no shared memory" outright.
6. Stale or leftover shared-memory segments from crashed prior instances interfering with, or consuming resources needed by, a new attach attempt.

Solutions / Resolution

1. Check accompanying OS-level error messages first, per the official guidance — this is the most direct path to the specific cause, since the underlying syscall failure usually names it (a permission denial, a resource limit, an address conflict).
2. Verify no system limit is actually being hit before assuming something more exotic — per-process/per-user attach limits, SHMALL, or similar, checked directly rather than assumed.
3. Check and correct shared-memory segment permissions and ownership if a mismatch is found.
4. For containerized or namespace-isolated processes, confirm IPC namespace sharing/visibility is configured correctly if that's a plausible factor.
5. Check for and clean up stale shared-memory segments from crashed processes if they're contributing to resource exhaustion — confirm genuine orphan status first, with the same care as any shared-resource cleanup, before removing anything.
6. If OS-level messages and limit verification don't reveal the cause, escalate to IBM Informix Technical Support with full diagnostic detail — per the official guidance, this is explicitly the next step once local causes are ruled out, not a first resort.

Examples

Checking permissions on the segment

ipcs -m
-- review the ownership and permission bits on the relevant segment
-- against the user/process attempting to attach

Checking for a per-process limit

ulimit -a
-- check for any relevant shared-memory or resource limits configured
-- for this specific user/process context

Container IPC isolation

A process running inside a container without the host's IPC namespace shared into it can fail to attach to a shared-memory segment that exists correctly on the host — the segment isn't the problem; the container's isolation boundary is.

Diagnostic Checks

1. Check OS-level error messages and logs around the failure — the specific syscall failure usually names the cause directly.
2. Review existing shared-memory segments and their permissions:

   ipcs -m
   

3. Check relevant OS limits for the user/process context attempting to attach:

   ulimit -a
   

4. For containerized deployments, confirm IPC namespace configuration between the container and the host (or the container running the engine).

Related Errors / Related Topics

• -123 — "ISAM error: no shared memory." The direct sibling — -123 means the segment doesn't exist; -156 means it exists but this specific process couldn't attach to it. Rule out which one actually applies before investigating further, since the fixes differ.
• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family, unrelated in cause.

Check OS-level messages and rule out local resource limits before escalating — per the official guidance, this is squarely a local-process/OS-level investigation before it becomes a support case.