Oninit
Talk to an expert →

Informix Error -35

-35 Operation would block.

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.

Why This Error Needs Care

The message text carried by Informix for -35 is "Operation would block" — that is EWOULDBLOCK, which is errno 35 on BSD-derived systems. Informix's message catalogue dates from an era when that mapping was the common one, and the text has travelled forward unchanged.

On a modern Linux server, errno 35 is not EWOULDBLOCK. It is EDEADLK — Resource deadlock avoided — an entirely different condition with entirely different causes. (EWOULDBLOCK on Linux is errno 11, and is an alias for EAGAIN.)

So the official message text and the real meaning on your server may disagree. Establish the native meaning first.

Commonly — but verify on your own host rather than relying on this:

Platform family errno 35 usually means
Linux (glibc) EDEADLK — Resource deadlock avoided
BSD, macOS/Darwin EAGAIN / EWOULDBLOCK — Resource temporarily unavailable
Solaris, AIX, HP-UX (System V heritage) ENOMSG — No message of desired type
Determine the Native Error Meaning

Do this on the machine that logged the error, not on a workstation.

Linux:

errno 35                                        # if moreutils/errno is installed
grep -w 35 /usr/include/asm-generic/errno.h
grep -w 35 /usr/include/asm-generic/errno-base.h

Any host with Python:

import os, errno
print(os.strerror(35))
print([n for n, v in errno.errorcode.items() if n == 35])

Any host with Perl:

perl -e '$! = 35; print "$!\n"'

Solaris:

grep -w 35 /usr/include/sys/errno.h

AIX:

grep -w 35 /usr/include/sys/errno.h

HP-UX:

grep -w 35 /usr/include/sys/errno.h

Record the result alongside the OS and OS version before going further. What follows splits according to what you found.

What Informix Was Doing

Independently of the errno, establish which Informix operation received it. The message log is the place to start, because the -35 rarely arrives alone:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -m
grep -n -i -E 'errno|ISAM|system error' "$INFORMIXDIR/tmp/online.log" | tail -50

Typical candidates:

  • A socket read or write against a client, an HDR/RSS partner, or an ER peer
  • A non-blocking I/O operation on a chunk or a backup device
  • A lock or file-lock request (fcntl) — relevant if the native meaning is EDEADLK
  • A System V message-queue operation — relevant if the native meaning is ENOMSG
  • A shared-memory connection (ipcshm) handshake
  • A read from a tape or pipe device during ontape / onbar
Common Causes
If the native meaning is EDEADLK (typically Linux)

The kernel detected that granting a lock request would create a deadlock cycle, and refused it rather than hanging.

  • Two processes taking fcntl locks on the same file in opposite order — commonly two instances of a script, backup wrapper, or external-table loader contending on the same lock file.
  • A second oninit instance, or a stray utility, attempting to lock a chunk or configuration file already locked by the running server.
  • Application-level file locking around an unload/load or spool directory shared between processes.

Note that this is file locking at the OS level — it is not an Informix row or table lock. Informix's own deadlock detection reports -143 (ISAM error: deadlock detected), not -35.

If the native meaning is EAGAIN / EWOULDBLOCK (typically BSD, macOS)

A non-blocking operation could not be completed immediately. In isolation this is often benign and retried internally; it becomes visible when it persists.

  • A socket marked non-blocking with no data available, typically under network congestion or a stalled peer
  • Client connection storms exhausting listener capacity
  • A slow or unresponsive HDR/RSS/ER partner
  • Resource limits reached — process, thread, or file-descriptor ceilings
If the native meaning is ENOMSG (typically Solaris, AIX, HP-UX)

A message-queue receive found no message of the requested type.

  • A System V IPC message queue used by a client/server or utility handshake
  • A helper process that exited without posting its expected message
  • IPC resources removed or recycled beneath a running process
Diagnostic Checks

Run the checks that match the meaning you verified — not all of them.

Common to all cases, establish scope and timing:

onstat -g ses
onstat -g ath
onstat -g ntt          # network transfer statistics
tail -300 "$INFORMIXDIR/tmp/online.log"
dmesg | tail -100

For a locking (EDEADLK) interpretation:

cat /proc/locks
lslocks                      # util-linux
fuser -v /path/to/lockfile
ps -ef | grep -E 'oninit|ontape|onbar'

For a non-blocking/resource (EAGAIN) interpretation:

ulimit -a
cat /proc/sys/fs/file-max
ss -s
ss -lntp
netstat -an | grep -c ESTABLISHED
onstat -g ntu

For a message-queue (ENOMSG) interpretation:

ipcs -q
ipcs -qa
ipcs -qp
Solutions / Resolution
  1. Verify the native errno meaning on the host. Everything downstream depends on it, and the official message text may not match it.
  2. Find the lowest useful error in the chain. A -35 reported by a high-level operation (a restore, a replication apply, a connection attempt) is the symptom; the surrounding online.log entries usually name the operation and often a second errno.
  3. If EDEADLK: identify the two lock holders and serialise them. Most commonly this means preventing concurrent runs of the same script — a proper lock file with flock, or a scheduler-level guard — rather than changing anything in Informix.
  4. If EAGAIN/EWOULDBLOCK: treat it as a capacity or peer-responsiveness problem. Check descriptor and process limits for the installation owner, then look at the network path and the state of the partner server.
  5. If ENOMSG: find the process that should have posted the message and establish why it did not — it usually exited early, and its own error is the real one.
  6. Do not apply a Linux remedy to a non-Linux host (or the reverse) on the strength of the number alone. This is the single most common way time is lost on errors in this range.
Examples
The same number, two different servers
Server A — Linux 5.14, x86_64
  $ python3 -c 'import os; print(os.strerror(35))'
  Resource deadlock avoided

Server B — Solaris 11, SPARC
  $ grep -w 35 /usr/include/sys/errno.h
  #define ENOMSG  35  /* No message of desired type */

An identical Informix -35 on these two hosts describes two unrelated failures. A runbook that says "check /proc/locks" is correct on Server A and meaningless on Server B.

Concurrent backup scripts on Linux

An ontape wrapper is scheduled from cron and also run by hand during an incident. Both take a lock on the same file, in an order that differs between the two code paths:

$ lslocks | grep informix
oninit   4821  POSIX  WRITE 0     /informix/backups/.ontape.lock
$ ps -ef | grep ontape
informix  4821 ...  /informix/scripts/nightly_archive.sh
informix  9930 ...  /informix/scripts/nightly_archive.sh

The kernel refused the second request with EDEADLK rather than allowing the two to hang. The fix belongs in the script — a single flock -n guard at the top that exits cleanly if another run holds it — not in the engine.

Reading the chain rather than the headline
14:22:06  Assert Failed: Archive read failed
14:22:06  system error = 35
14:22:06  Unable to read from device /dev/rmt0

The useful diagnostic is the device-level failure and its errno, not the archive operation that reported it. Establish what errno 35 means on this host, then investigate the device.

Related Errors / Related Topics
  • -32 — Broken pipe. Also in this range, also errno-derived, and a frequent companion when a peer process or connection has gone away.
  • -11 — On Linux, EAGAIN / EWOULDBLOCK; worth checking if the native meaning of 35 on your host turned out to be a deadlock condition and you were expecting a blocking condition.
  • -143 — ISAM error: deadlock detected. This is Informix's own lock manager, and is what you are looking for if the contention is over rows or tables rather than files.

Persistent errors in this range on a replicated or highly available estate — HDR, RSS, or Enterprise Replication — are usually better approached as a connectivity and capacity investigation than as a single-error lookup.