Informix Error -78: Deadlock situation detected/avoided.

Cause and resolution

Deadlock situation detected/avoided.

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.

Under AIX, this code means connection timed out.

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. -78 is a documented case where the platform variance isn't just cosmetic: the official text itself calls out that AIX assigns this same numeric value a different meaning entirely.

Determine the Native Error Meaning

	Value	Symbol
Catalogue text — Deadlock situation detected/avoided	78	`EDEADLK` on the catalogue's source platform
The same condition on Linux	35	`EDEADLK` — Resource deadlock avoided
Errno 78 on Linux	78	`EREMCHG` — Remote address changed, unrelated
Under AIX specifically	78	Connection timed out — per the official guidance, a documented AIX-specific override, not `EDEADLK`

python3 -c 'import os; print(78, os.strerror(78)); print(35, os.strerror(35))'

What EDEADLK Actually Tells You

EDEADLK is returned by the kernel's own advisory record-locking deadlock detector — most commonly from fcntl() with F_SETLKW, or the equivalent lockf() call. When a process blocks waiting for a lock that another process holds, the kernel can detect that granting the wait would create a circular wait (process A waiting on a lock B holds, while B is waiting on a lock A holds) and refuses the blocking wait outright rather than letting both processes hang forever. This is the kernel doing you a favor: without this check, the two processes would deadlock silently instead of one of them getting a clean, actionable error back.

What This Means in Informix — and the AIX Exception

Per the official text, on most platforms this is the kernel-level record-lock deadlock detector described above, surfacing unexpectedly to the database server. On AIX, however, the official guidance states this same numeric code instead means "connection timed out" — a completely different condition (a network/connection-level timeout, not a locking deadlock). This is exactly the kind of platform divergence this whole errno range is prone to: the number is shared, the meaning isn't. Do not assume a deadlock-detection scenario on an AIX host without confirming the platform's own errno.h first.

On non-AIX platforms: most plausibly a record-lock deadlock detected during an fcntl()/lockf() wait — worth investigating alongside Informix's own internal locking if it surfaces during normal database operation, since the OS-level detector operates independently of Informix's own lock manager.
On AIX: treat this as a connection-timeout condition instead, per the official text's explicit override — investigate network/connectivity health rather than record-locking.

Common Causes

A genuine kernel-level record-lock deadlock, on platforms where errno 78 maps to EDEADLK — two processes' lock waits forming a circular dependency.
A connection timing out, specifically on AIX, per the official guidance's documented platform-specific override for this same numeric code.
Diagnosing this from the wrong assumption — treating an AIX occurrence as a locking deadlock (or a non-AIX occurrence as a connection timeout) because the platform wasn't confirmed first is itself a common source of wasted troubleshooting time here.

Solutions / Resolution

Confirm the platform first, per the official guidance's explicit AIX callout — the correct next step depends entirely on which condition actually applies.
On AIX: investigate as a connection timeout — check network reachability, timeout configuration, and the state of the remote endpoint involved in the connection.
On other platforms: investigate as a record-lock deadlock — identify the two (or more) processes and locks involved via the diagnostic checks below.
Note all circumstances and contact IBM Informix Technical Support, per the official guidance, if the cause isn't clear from the platform-appropriate investigation.

Examples

N/A

No specific triggering statement is documented; which investigation applies depends on confirming the platform first, per the official guidance's AIX-specific note.

Diagnostic Checks

Confirm the platform before doing anything else — this determines whether the applicable condition is a locking deadlock or a connection timeout.
Confirm the symbol on non-AIX platforms, since errno 78 means something unrelated on Linux:
```
python3 -c 'import os; print(78, os.strerror(78)); print(35, os.strerror(35))'
```
On AIX, check network connectivity and timeout configuration for the connection in question rather than looking for a locking deadlock.
On non-AIX platforms, identify the processes and locks involved in the deadlock, if the OS provides tooling to inspect held/pending record locks.

Related Errors / Related Topics

-77 — "Identifier removed." A neighboring OS-resource condition in this cluster (System V IPC identifier removal), unrelated in mechanism.
-79 — "No record locks available." A related but distinct locking condition — -79 is the kernel's lock table running out of capacity, while -78 (off AIX) is the kernel refusing a specific lock wait because it would deadlock.

Confirm the platform before diagnosing -78 — per the official guidance, AIX assigns this same number a completely different meaning (connection timed out) than every other platform (a record-locking deadlock).