Informix Error -123: ISAM error: no shared memory.

Reasons / Common Causes

-123 sits above the application layer — the official text itself says so, pointing straight at the system administrator or installer rather than at application code. This ISAM implementation depends on a shared-memory segment that's supposed to already exist, and it doesn't.

1. The shared-memory segment was never initialized. The engine's own startup/initialization step (creating its shared-memory partition) hasn't run on this machine, or hasn't completed.
2. A partial or interrupted installation skipped the step that creates the shared-memory segment — the product is present, but its setup never finished.
3. The segment was manually removed (an administrator or cleanup script running ipcrm, intentionally or by mistake) without the owning service being restarted afterward to recreate it.
4. OS-level shared-memory limits configured too low — SHMMAX/SHMALL (or their modern sysctl equivalents) set below what the engine needs, causing segment creation to fail silently at the engine's own startup, well before a client process ever hits -123 downstream.
5. The engine process was never started, or crashed, so no shared memory exists for this instance at all.
6. A container or namespace-isolation boundary hiding the host's shared memory from the process attempting to use it — common when a client runs in a container that doesn't share the host's IPC namespace with the engine.
7. A segment-key collision or mismatch between multiple engine instances/versions on the same host, causing a client to attach to the wrong, or a nonexistent, segment.

Solutions / Resolution

1. Confirm the engine service is actually running and fully initialized — this is the first, most direct check, since -123 is very often simply "the engine hasn't started (successfully) yet."
2. Check that shared-memory initialization completed as part of installation or startup — re-run the engine's initialization step if it appears to have been skipped or interrupted.
3. Check and raise OS-level shared-memory limits if they're configured below what the engine needs — this is a system administration task, not something to work around from the application side.
4. If the segment was manually removed, restart the engine service to have it recreate the segment properly — don't attempt to recreate shared memory by hand outside the engine's own startup process.
5. Confirm the client is targeting the correct host/instance where the engine's shared memory actually exists — particularly relevant in containerized environments where namespace isolation can hide a host's shared memory from a container that doesn't share its IPC namespace.
6. For multi-instance setups, check for segment-key collisions between different engine instances or versions running on the same host.
7. Escalate to the system administrator or installer if the above doesn't resolve it — this genuinely sits above what application-level troubleshooting can fix, per the official guidance.

Examples

The engine that hasn't finished starting

$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

# No segments listed — the engine hasn't created its shared memory yet

If the expected segment simply isn't there, check the engine's own startup status and logs before assuming anything about the client application is wrong.

Shared-memory limits set too low

$ cat /proc/sys/kernel/shmmax
33554432
# 32 MB — likely far too small for a database engine's shared-memory needs

The engine's own startup log, not -123 itself, is where this failure actually gets reported — check it directly rather than inferring the cause from the client-side error alone.

Container isolation hiding the host's segment

A client process running inside a container without the host's IPC namespace shared into it can't see shared memory the engine created on the host, even though the engine itself is running correctly — the fix is container configuration (sharing the IPC namespace, or running the client where it can see it), not anything about the engine or the client code.

Diagnostic Checks

1. List current shared-memory segments:

   ipcs -m
   

2. Check whether the engine service is actually running:

   onstat -
   

   (or the equivalent service-status check for the product in use.)
3. Check OS-level shared-memory limits:

   sysctl kernel.shmmax kernel.shmall
   

4. Check the engine's own startup logs for shared-memory initialization errors — this is often where the actual root cause is reported, separate from the client-side -123.
5. For containerized deployments, confirm IPC namespace/visibility configuration between the container running the client and the host (or container) running the engine.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -116 — "ISAM error: cannot allocate memory." The other memory-resource error in this range — -116 is about ordinary process memory allocation; -123 is specifically about a missing shared-memory segment the whole ISAM implementation depends on.

Treat -123 as an infrastructure/installation issue from the start — check the engine's own status and startup logs before looking anywhere in application code.