Oninit
Talk to an expert →

Informix Error -32

-32 Broken pipe.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. A pipe is a data path between two processes; a pipe is broken if one of the processes has unexpectedly quit while the other is waiting for data. Look for other operating-system error messages that might give more information, especially which processes were 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

Errno 32 is one of the better-behaved values in this range: it is EPIPE — Broken pipe — on Linux, Solaris, AIX, HP-UX and the BSD-derived systems, and the message Informix carries agrees with all of them.

That is a reason to proceed with more confidence than on a neighbouring code such as -35, not a reason to skip the check. Verify on the host that logged the error, and record the result:

python3 -c 'import os; print(os.strerror(32))'
perl -e '$! = 32; print "$!\n"'
grep -w 32 /usr/include/asm-generic/errno-base.h     # Linux
grep -w 32 /usr/include/sys/errno.h                  # Solaris, AIX, HP-UX

Everything below assumes the check returned EPIPE.

What EPIPE Actually Tells You

A process wrote to a pipe or socket whose reader is gone. The kernel delivered EPIPE to the writer — and, by default, SIGPIPE as well.

The essential point for troubleshooting: EPIPE is reported to the survivor, not the casualty. The process that logged the error is the one still running. Whatever closed the other end failed first, and its failure is the one worth finding. Diagnosing the -32 itself usually produces nothing, because the -32 is a consequence.

So the question is never "why did the write fail?" It is "what happened to the process or connection at the other end, and why did it go away?"

What Informix Was Doing

Establish which operation received the EPIPE:

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

Common contexts:

  • A client connection dropped while the server was returning a result set
  • A shell pipeline in a backup — ontape piped into gzip, compress, ssh, or a storage-manager command, where the downstream command exited
  • An external table using a named PIPE, where the reading program stopped
  • onbar and the storage manager — the XBSA process or its child exiting
  • HDR/RSS/ER — a replication partner's connection closing
  • Connection Manager — a proxied connection torn down mid-stream
  • A report or unload piped to another program
  • ALARMPROGRAM or another helper whose output is read by a process that exited early
Common Causes
  1. The client application exited, crashed, or was killed while a query was running — by far the most common cause.
  2. The user cancelled — a closed terminal, a stopped report, a browser navigating away from a long-running request.
  3. A network device closed an idle connection — firewall, load balancer, or NAT idle timeout. These are invisible at both ends until the next write.
  4. A downstream command in a pipeline failed — gzip hitting a full filesystem, ssh losing its connection, a storage-manager binary exiting non-zero. The real error is that command's, and it often appears in a different log.
  5. The peer server went down — an HDR or ER partner stopping, failing over, or being restarted.
  6. A timeout at the application or driver layer, closing the socket while the server is still writing results.
  7. oninit or a client process killed by the OOM killer or by an administrator.
  8. A container or pod terminated mid-operation, taking its end of the connection with it.
Diagnostic Checks

Start with what went away, and when:

# What died, and was it killed?
dmesg -T | grep -i -E 'killed process|oom|segfault'
journalctl -k --since '1 hour ago' | grep -i -E 'oom|killed'
grep -i -E 'oom|killed' /var/log/messages 2>/dev/null | tail

For backup pipelines, the downstream command's own log is the one that matters:

tail -100 "$BAR_ACT_LOG"
tail -100 "$BAR_DEBUG_LOG"
ls -l /backups                 # did the target fill?
df -h /backups

For client connections:

onstat -g ses
onstat -g ntt
onstat -g ntu
ss -tn state established | head -30

For idle-timeout suspicions, the timing is the evidence — a failure that recurs at a consistent interval after the last activity points at a device in the path rather than at either endpoint:

sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

For replication:

onstat -g dri          # HDR status
onstat -g rss
cdr list server        # ER
Solutions / Resolution
  1. Stop investigating the -32 and find what closed the other end. The -32 is the symptom; on its own it is not actionable.
  2. If a pipeline failed, read the downstream command's log and exit status. A full filesystem behind gzip produces -32 at the Informix end and ENOSPC at the real point of failure — see -28.
  3. If a client exited, decide whether it matters. An occasional -32 when users close reports is normal and needs no action; a pattern is a fault.
  4. If the timing is regular, suspect an idle timeout in a firewall or load balancer. Either shorten TCP keepalive so the connection is kept alive below that threshold, or lengthen the device's timeout.
  5. If a replication partner dropped, work the partner's failure; the -32 on the survivor tells you nothing further.
  6. If a process was OOM-killed, address the memory pressure — the -32 is two steps downstream of the real problem.
  7. For long-running queries against impatient clients, consider whether the work belongs in a background job rather than a foreground connection.
Examples
The real error is in the other log
-- online.log
02:14:41  Archive failed: write error
02:14:41  system error = 32

-- the backup wrapper's own log
02:14:40  gzip: /backups/archive_L0.gz: No space left on device

ontape was piped into gzip. The filesystem filled, gzip exited, and the next write from ontape got EPIPE. The actionable error is the ENOSPC, and nothing about the -32 leads to it — only reading the other log does.

Client went away mid-result
$ onstat -g ses
session    id user     tty      hostname       #RSAM threads
  47182       appuser  -        appsrv02       0

A session with no threads, on an application server, at the same time as the -32. The application timed out at 30 seconds and closed the socket while the server was still returning rows. The fix is in the application's timeout or the query's runtime, not in Informix.

Regular as clockwork
09:12:03  system error = 32
10:12:07  system error = 32
11:12:02  system error = 32

Hourly, a few seconds past the hour, on connections that had been idle. This is a device in the network path expiring idle sessions, not an Informix fault. Confirm by testing whether a connection kept busy survives the boundary while an idle one does not.

Replication partner restarted
14:02:11  DR: Receive error
14:02:11  system error = 32
14:02:11  DR: Turned off on primary server

The secondary's connection closed. The -32 records the primary noticing. Why the secondary went away — a restart, a failover, a network partition — is what has to be established, and it will be in the secondary's log, not the primary's.

Related Errors / Related Topics
  • -35 — Also in this range and also errno-derived, but genuinely platform-dependent: its meaning differs between Linux, BSD and System V systems. Worth reading before assuming anything about this range from -32's relatively well-behaved case.
  • -25 — Another errno commonly seen around interrupted I/O and device operations.
  • -28 — No space left on device. A frequent upstream cause when the -32 came from a pipeline.
  • -908 — Attempt to connect to database server failed. Where -32 is a connection that broke mid-use, -908 is one that never established.

Recurring -32 across a replicated or load-balanced estate is a connectivity and stability question rather than a single-error lookup, and the useful evidence is usually the pattern in timing rather than any individual occurrence.