Oninit
Talk to an expert →

Informix Error -5

-5 I/O error.

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. 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.

Operating-System Meaning

errno 5 is EIO — I/O error. A read or write failed at a level below the filesystem: the device, its transport, or the controller could not complete the operation.

This is different in character from most errors in this range. -2, -13 and -1 are configuration and permission problems, resolved by correcting something. EIO usually means hardware, a storage path, or media is failing, and the immediate priority is not to make the error go away but to establish what has been affected.

The kernel knows far more about this than Informix does. Informix reports that a read or write failed; the kernel log will normally name the device, the sector, and often the SCSI sense data explaining why. The kernel log is the primary source on this error, not online.log.

What This Means in Informix

An EIO against a chunk is a serious event, and the engine's own response is part of the diagnosis:

  • A chunk I/O failure normally takes that chunk offline (status D in onstat -d). The dbspace continues if other chunks can serve the data; it does not if they cannot.
  • If the affected chunk is critical — the root dbspace, the physical log, or the logical logs — the server may shut down rather than continue.
  • Mirrored chunks change the picture: the mirror takes over and the server stays up, which is the intended behaviour but also means the failure can go unnoticed without monitoring.

Other contexts:

  • Backup and restore — a tape read/write failure during ontape or onbar, or a failing disk behind a backup directory
  • A failing path rather than a failing disk in a multipathed SAN configuration
  • A cooked chunk on a filesystem with bad blocks
  • NFS-backed storage where the server or the export has gone away
  • External tables and unload files on failing media
Common Causes
  1. A failing disk — reallocated or pending sectors, medium errors.
  2. A storage path problem rather than a device problem — HBA, cable, switch port, or a multipath path that has gone down. Common in SANs, and often transient and recurring.
  3. A controller or RAID problem — a degraded array, a failed battery forcing write-through, a controller reset.
  4. Media failure on tape during backup or restore.
  5. A LUN removed, resized, or remapped underneath a running server.
  6. NFS server or export unavailable, where operations that would block instead fail.
  7. Filesystem corruption on a cooked chunk's filesystem.
Diagnostic Checks

Establish scope inside Informix first — which chunk, which dbspace, and is the server still viable:

onstat -d                     # chunk status; look for 'D' (down) in the flags
onstat -d | grep -v '^ *PO'   # anything not primary/online
onstat -                      # is the server up at all
tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -m

In onstat -d, chunk flags read as position 1 P/M (primary or mirror) and position 2 O/D (online or down). PD- is a primary chunk that has been taken offline — that is the chunk to investigate.

Then go to the kernel log, which is where the real information is:

dmesg -T | tail -100
dmesg -T | grep -iE 'I/O error|medium error|critical|sense|reset|offline|failed'
journalctl -k --since '2 hours ago' | grep -iE 'error|sense|reset'
grep -iE 'I/O error|sense|scsi' /var/log/messages | tail -50

Identify the device behind the chunk, then examine it specifically:

onstat -d | awk '/^[0-9]/ {print $NF}'      # chunk paths
readlink -f /informix/chunks/datadbs1        # resolve symlink to the real device
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
smartctl -a /dev/sdX | grep -iE 'reallocated|pending|uncorrect|health'

If the storage is multipathed, check whether this is a path failure rather than a device failure — the distinction changes the remedy entirely:

multipath -ll
multipath -ll | grep -iE 'failed|faulty|offline'
ls -l /sys/class/fc_host/*/port_state 2>/dev/null
cat /sys/class/fc_host/host*/port_state 2>/dev/null

For RAID and vendor controllers, use the vendor tool rather than inferring from the OS:

storcli /c0 show all          # or megacli, ssacli, perccli as appropriate
cat /proc/mdstat              # software RAID

To confirm whether the device is currently readable — read-only, never write:

dd if=/dev/sdX of=/dev/null bs=1M count=100 status=progress
dd if=/informix/chunks/datadbs1 of=/dev/null bs=1M count=100

Once storage is stable, validate what Informix holds:

oncheck -cd  <dbspace>        # data pages
oncheck -cD  <dbspace>        # data and index pages
oncheck -ce                   # extents
oncheck -cr                   # reserved pages
Solutions / Resolution

The order matters more on this error than on any other in the range. The instinct is to bring the chunk back online and carry on; doing that before establishing what happened can turn a contained fault into data loss.

  1. Establish scope before acting. Which chunk, which dbspace, is it critical, is it mirrored, and is the server still running.
  2. Read the kernel log. Informix is a witness here, not the investigator. The sense data or path event explains what actually failed.
  3. Determine device versus path. A failed multipath path is a connectivity problem — restore the path and the device is intact. A medium error is not, and the data may be gone.
  4. Do not bring the chunk back online until the storage is sound. onspaces -s restoring a chunk on a still-failing device will fail again, and may extend the damage.
  5. Escalate to whoever owns the storage with the device, timestamps, and the kernel messages. This is usually not a database fix, and the database team rarely has the tooling to confirm it.
  6. Once the storage is verified, restore the chunk and let the engine recover it — for a mirrored chunk, via the mirror; otherwise from backup.
  7. Validate before declaring it resolved. Run oncheck against the affected dbspace. An I/O error that was silently retried by the storage layer can leave inconsistent pages that nothing else will report.
  8. Verify your backups are readable — a failing device may also have affected recent archives, and this is the worst possible moment to discover that.
  9. Do not run a write-mode repair tool on the device until you have a backup of the current state.
If the engine still will not come online

If the storage has been repaired or replaced and the server still will not start — or starts and will not bring the dbspace back — stop before attempting anything that writes to the affected chunks. Recovery from a damaged critical dbspace is one of the few Informix operations where a wrong step is not reversible, and the options narrow every time one is tried.

Oninit® are the Down System Specialists. Bringing unresponsive Informix instances back is what we do, and we would far rather hear from you before a recovery attempt than after one.

Examples
A chunk taken offline, with the real cause in the kernel log
-- online.log
03:14:22  I/O error, chunk 4, path '/informix/chunks/datadbs2'
03:14:22  system error = 5
03:14:22  Chunk 4 in DBspace datadbs is now offline

$ dmesg -T | grep -iE 'sdd|medium'
[Tue Sep  9 03:14:21 2026] sd 2:0:0:3: [sdd] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Tue Sep  9 03:14:21 2026] sd 2:0:0:3: [sdd] tag#18 Sense Key : Medium Error [current]
[Tue Sep  9 03:14:21 2026] sd 2:0:0:3: [sdd] tag#18 Add. Sense: Unrecovered read error
[Tue Sep  9 03:14:21 2026] blk_update_request: critical medium error, dev sdd, sector 1954210376

A medium error — an unrecoverable read on physical media. The chunk will not come back by being restored online, and the data in that region needs to come from a mirror or a backup. smartctl on the device will usually corroborate with reallocated or pending sector counts.

A path failure, not a disk failure
$ multipath -ll
mpathb (36000d31000ebb7000000000000000123) dm-3 COMPELNT,Compellent Vol
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| `- 2:0:1:3 sde 8:64 failed faulty running
`-+- policy='service-time 0' prio=1 status=active
  `- 3:0:1:3 sdf 8:80 active ready running

One path faulty, one active. The LUN is intact and reachable; a cable, port or HBA is not. This is a connectivity fix, and the data is fine — a very different afternoon from the previous example, which is exactly why the device-versus-path question comes before any remedy.

A tape media error during backup
-- bar_act.log / ontape output
Archive failed: write error on device /dev/rmt0
system error = 5

$ dmesg -T | grep -i st0
[Tue Sep  9 02:41:09 2026] st 1:0:0:0: [st0] Error 8000002 (driver bt 0x0, host bt 0x8)

The backup did not complete, so whatever it was protecting is not protected. Change the media, clean the drive, and re-run — and treat the previous archive as the most recent good one until a new archive verifies.

Platform Note

errno 5 is EIO on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number is reliable.

Where to look for the underlying cause is not portable at all:

Task Linux Solaris AIX
Kernel/device errors dmesg -T, journalctl -k /var/adm/messages, fmdump -eV errpt -a
Disk health smartctl -a iostat -En, fmadm faulty diag, errpt
Multipath multipath -ll mpathadm list lu lspath, pcmpath query device
Volume layer lsblk, lvs zpool status lsvg, lspv

On AIX in particular, errpt -a is the first command to run and frequently gives a more precise diagnosis than anything available on Linux. On Solaris with ZFS, zpool status may show the pool has already corrected the error, in which case Informix saw a failure that the storage layer subsequently healed. Establish that before planning a restore.

Related Errors / Related Topics
  • -28 — No space left on device. The other error that interrupts chunk and backup I/O, but a capacity problem rather than a hardware one.
  • -2 — No such file or directory. A chunk path that has vanished, which after a storage event can accompany or follow an -5.
  • -13 — Permission denied, worth ruling out if the device is intact and healthy.

An -5 against a chunk is an availability and data-integrity event, not just an error to clear. If the estate is not mirrored or the backups have not been verified recently, that is the finding worth acting on after the immediate incident — and continuous monitoring of chunk status is what turns a mirrored failure from something you discover weeks later into something you are told about.