Oninit
Talk to an expert →

Informix Error -77: Identifier removed.

Cause and resolution

Identifier removed.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. 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 — Identifier removed 77 EIDRM on the catalogue's source platform
The same condition on Linux 43 EIDRM — Identifier removed
Errno 77 on Linux 77 EBADFD — File descriptor in bad state, unrelated 
python3 -c 'import os; print(77, os.strerror(77)); print(43, os.strerror(43))'
What EIDRM Actually Tells You

EIDRM is a classic System V IPC condition: a process was referencing an IPC object — a semaphore set, a message queue, or a shared-memory segment — by its identifier, and that identifier was removed by another process (via semctl(IPC_RMID, ...), msgctl(IPC_RMID, ...), or shmctl(IPC_RMID, ...)) while the first process still held or was waiting on it. The operation that returns EIDRM typically wasn't doing anything wrong — the resource it was using simply stopped existing out from under it, usually because it was blocked on a semaphore operation or a message-queue receive when the identifier was removed.

This is a race between two independent processes over shared IPC state, not a corruption or a permissions problem.

What This Means in Informix

Per the official text, this is an OS-level error surfacing unexpectedly to the database server. System V IPC (semaphores and shared memory in particular) is directly relevant to Informix, since the engine's shared-memory architecture for inter-process coordination among its virtual processors historically relies on exactly these primitives on Unix platforms:

  • A semaphore set backing Informix's shared-memory coordination was removed while a server process was blocked waiting on it — most plausibly during an abrupt oninit -ky/kill, an OS-level IPC cleanup utility (ipcrm, or a boot-time IPC-clearing script) running while the engine was still up, or a second, conflicting instance tearing down IPC resources it didn't actually own.
  • A stale IPC identifier reused or removed by unrelated system administration activity — a script or monitoring tool that indiscriminately clears System V IPC resources (a common "clean slate" habit on some platforms) removing identifiers that belong to a running Informix instance.
  • Two Informix instances or a crashed instance's leftover IPC segments colliding, where cleanup of one instance's identifiers races against another process still referencing them.
Common Causes
  1. IPC cleanup activity (manual ipcrm, a cleanup script, or a competing instance) removing a semaphore, message queue, or shared-memory identifier while Informix still references it — the direct mechanism.
  2. An abrupt engine shutdown or crash leaving IPC resources in a state where a subsequent cleanup step races against processes still holding them.
  3. Platform or site conventions that reset System V IPC state indiscriminately (at boot, or via a generic maintenance script) without accounting for a running database server's ownership of specific identifiers.
Solutions / Resolution
  1. Note all circumstances and contact IBM Informix Technical Support, per the official guidance, if the error recurs — this is the documented response for an unexpected OS-level error.
  2. Check for IPC cleanup activity around the time of the error — review shell history, cron jobs, and any system-maintenance scripts that call ipcrm or otherwise clear System V IPC state, on the host in question.
  3. Confirm no second Informix instance (or leftover instance from a prior crash) is contending for the same shared-memory/semaphore identifiers.
Examples
Checking current IPC state
ipcs -s   # semaphore sets
ipcs -m   # shared-memory segments
ipcs -q   # message queues

Compare what's currently present against what the running Informix instance expects, and look for any external process with permission to remove entries it doesn't own.

Diagnostic Checks
  1. Confirm the symbol, since errno 77 means something unrelated on Linux:
    python3 -c 'import os; print(77, os.strerror(77)); print(43, os.strerror(43))'
  2. Review the host for IPC cleanup activity (ipcrm, boot scripts, competing instances) around the time the error occurred.
  3. Capture full circumstances for escalation to IBM Informix Technical Support if the error recurs.
Related Errors / Related Topics
  • -79 — "No record locks available." Another OS-resource-exhaustion/contention error in this same numeric cluster, though it concerns the kernel's record-lock table rather than System V IPC identifiers.
  • -70 — Stale NFS file handle. A different OS-errno neighbor; unrelated in mechanism, just numerically adjacent.

An IPC identifier Informix was referencing was removed out from under it — check for ipcrm activity, cleanup scripts, or a competing instance, and escalate to IBM Informix Technical Support with full circumstances if it recurs.