Oninit
Talk to an expert →

Informix Error -72: Not a stream device.

Cause and resolution

Not a stream device.

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, particularly which device is 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 — Not a stream device 72 ENOSTR — STREAMS-era
The same symbol on modern Linux 60 ENOSTR — Device not a stream
Errno 72 on Linux 72 EMULTIHOP — Multihop attempted, unrelated 
python3 -c 'import errno, os; print(60, os.strerror(60)); print(72, os.strerror(72))'

The exact originating platform/era for Informix's own numbering of ENOSTR at 72 isn't independently confirmed here — only that it's a different number from modern Linux's 60 for the same symbol, the same general pattern already established for -70 and -71 in this range. Confirm the live value with the errno.h on the actual reporting host rather than assuming either number.

What ENOSTR Actually Tells You

ENOSTR is a STREAMS-era condition: an operation that requires a STREAMS device — a character device opened through the STREAMS I/O mechanism, historically used for terminal drivers, pseudo-terminals, and networking transports on STREAMS-based Unix systems — was attempted against a file descriptor that isn't one. The descriptor may be entirely valid and open; it simply isn't backed by a STREAMS-capable driver, so a STREAMS-specific call (putmsg(2), getmsg(2), an ioctl that only makes sense on a stream) fails outright.

This is a capability mismatch, not a permissions or existence problem: the target exists, is open, and may work fine for ordinary reads and writes — it just can't service the specific STREAMS operation being requested.

What This Means in Informix

Per the official text, this is an OS-level condition reaching the database server unexpectedly — Informix has no STREAMS-specific handling of its own, it just receives the refusal like any other process would. Historically this surfaced most often around:

  • Terminal or pseudo-terminal handling during interactive sessions (isql, DB-Access, a 4GL program run from a terminal) on STREAMS-based Unix platforms, if a descriptor Informix expected to be a STREAMS-backed tty turned out not to be.
  • STREAMS-based network transport modules, on platforms that implemented TCP/IP or other connectivity through STREAMS, if a socket-like descriptor was passed to a STREAMS-specific call by mistake.
  • A regular file or pipe descriptor reaching code that assumed a STREAMS device, typically through a misconfigured device path or a symlink pointing at the wrong kind of node.

On modern non-STREAMS platforms (Linux, current BSD/Darwin), this specific condition is unlikely to occur at all in the way the official text describes, since STREAMS itself isn't the networking/tty mechanism in use — if this error still appears on a current install, treat it as a strong signal to check exactly what descriptor and call triggered it before assuming it means what it meant on the original STREAMS-era platform.

Common Causes
  1. A STREAMS-specific call issued against a non-STREAMS descriptor — the direct, named cause; everything below is a way that mismatch arises.
  2. A misconfigured or unexpected device path, where the path Informix opened resolves to a plain file, pipe, or a different device type than the STREAMS driver expected.
  3. A symlink pointing at the wrong target, silently redirecting what should be a STREAMS device node to something else.
  4. Running on a platform or kernel configuration where the expected STREAMS driver isn't loaded or isn't the active implementation for that device class.
Solutions / Resolution
  1. Identify exactly which descriptor and operation triggered the error, since the official text names no further specifics — check the accompanying error(s) in the online log for the operation Informix was performing.
  2. Confirm the target device path actually resolves to the expected device type on the reporting host:
    ls -la /path/to/device
file /path/to/device 2>/dev/null
  3. If a symlink is involved, resolve it explicitly and confirm it points where it should:
    readlink -f /path/to/device
  4. If the error recurs and the cause isn't evident from the device path, note all circumstances (the operation, the descriptor, the platform) and contact IBM Informix Technical Support, per the official guidance.
Examples
N/A

No specific triggering statement is documented beyond an operating-system error code unexpectedly returned to the database server — the official text gives no further detail.

Diagnostic Checks
  1. Confirm the symbol and its native value on the reporting host, since this errno's number is not stable across platforms:
    python3 -c 'import errno, os; print(60, os.strerror(60)); print(72, os.strerror(72))'
  2. Check what descriptor/device path was involved, via the accompanying online log entries around the same timestamp.
  3. Verify the device path resolves to the expected device type, following any symlinks.
Related Errors / Related Topics
  • -70 — Stale NFS file handle. Another operating-system errno in this same cluster, with the same platform-dependent-numbering caveat.
  • -71 — Too many levels of remote in path. Same cluster, same caveat.
  • -74 — Out of stream resources. Easily confused by name with -72 — -72 is "not a stream device at all," -74 is "genuinely a stream, but resources for it are exhausted."

An operating-system-level STREAMS capability mismatch — confirm the exact descriptor and device path involved before assuming this means what it meant on the platform Informix's catalogue text was originally written against.