Informix Error -6

Operating-System Meaning

errno 6 is ENXIO — No such device or address. The path resolved and the object exists, but there is nothing behind it: the device special file refers to a device that is not present, or a named pipe was opened for writing with no reader.

Four errors in this range all present as "Informix cannot open this thing" and mean quite different things:

errno	Symbol	The path	The device
2	ENOENT	does not exist	—
6	ENXIO	exists	is not there
13	EACCES	exists	is there, you may not open it
5	EIO	exists	is there, and is failing

So on -6, ls -l will happily show you the device node. It is a file in /dev describing a major and minor number; nothing guarantees a device is answering on those numbers. A node left behind after hardware was removed looks identical to a working one.

The second cause is unrelated and easy to forget: opening a FIFO for writing when nothing has it open for reading returns ENXIO if the open is non-blocking.

What This Means in Informix

• Raw chunk devices — the device node is present but the LUN has been unmapped, removed, or was never presented to this host. Common after SAN work, a failed-over host, or a cloned VM where /dev entries came along but the storage did not.
• Tape devices — /dev/rmt0 or /dev/st0 exists while the drive is absent, offline, or empty. A frequent ontape and onbar failure.
• Named pipes — an external table or a backup piped through a FIFO, where the reading process has not started, has already exited, or was never launched.
• Configuration pointing at the wrong device — the official text's "error when you configured the database software". A chunk path naming a device that exists on a different host in the estate is the usual form.
• Chunk offsets past the end of a device — asking for a region the device cannot address.
• Containers — a device node baked into an image with no matching device passed through at runtime.

Common Causes

1. A LUN has been unmapped or removed while its device node remains.
2. Stale device nodes left behind after hardware was removed, a host was rebuilt, or a VM was cloned.
3. A tape drive that is empty, offline, or powered down.
4. A FIFO with no reader — the consuming process failed to start, or died first.
5. A configuration carried from another host where that device genuinely exists.
6. A device not yet scanned after being presented — the storage is there, the OS has not been told.
7. A chunk offset or size exceeding the device's capacity.
8. A container missing a --device mapping that the image assumes.

Diagnostic Checks

Confirm what the node actually is before anything else — the major and minor numbers are the point:

ls -l /path/to/device
stat /path/to/device
file /path/to/device

brw-rw---- 1 ifxprod ifxprod 8, 49 Sep  9 03:02 /dev/sdd1
              ^ block device        ^ major 8, minor 49
prw-r--r-- 1 ifxprod ifxprod     0 Sep  9 03:02 /informix/pipes/unload.pipe
^ 'p' — this is a FIFO, not a device

Then ask whether the kernel currently knows about a device with those numbers:

lsblk
lsblk -o NAME,MAJ:MIN,SIZE,TYPE
lsscsi
cat /proc/partitions
blkid

If the node is present and lsblk does not list it, that is your answer — the node is stale or the device is not attached.

Check whether the device went away, and when:

dmesg -T | grep -iE 'removed|offline|detached|rejecting I/O|lost|unmapped'
journalctl -k --since '1 day ago' | grep -iE 'sd[a-z]|rport|remote port'
multipath -ll

For chunk paths specifically, resolve and test each one:

onstat -d
onstat -d | awk '/^[0-9]/ {print $NF}' | while read -r p; do
    printf '%s: ' "$p"
    if [ -e "$p" ]; then
        dd if="$p" of=/dev/null bs=4k count=1 2>/dev/null && echo readable || echo "PRESENT BUT NOT READABLE"
    else
        echo MISSING
    fi
done

That loop separates the three states cleanly: missing path (-2), present but unreadable (-6 or -5), and fine.

For tape:

mt -f /dev/rmt0 status
mt -f /dev/st0 status
lsscsi -g | grep -i tape

For a FIFO, find out whether anything has it open for reading:

ls -l /path/to/pipe          # leading 'p'
fuser -v /path/to/pipe
lsof /path/to/pipe

If storage has just been presented and may simply not be scanned yet:

ls /sys/class/scsi_host/
# rescan (writes to sysfs — safe, but know that you are asking the HBA to re-probe)
for h in /sys/class/scsi_host/host*; do echo "- - -" > "$h/scan"; done
multipath -r
lsblk

Solutions / Resolution

1. Establish which of the four cases you are in using the table above. ls -l plus lsblk answers it in two commands, and the remedy differs completely.
2. If the device is genuinely absent, this is a storage task, not a database one — the LUN needs presenting, the path restoring, or the drive bringing online. Escalate with the device node's major/minor and the dmesg timestamps.
3. If the storage is present but unscanned, rescan the HBA and refresh multipath, then confirm with lsblk before restarting anything in Informix.
4. If the node is stale — hardware genuinely gone and not coming back — remove the node and correct the configuration that still references it. Leaving stale nodes in place guarantees this error recurs and misleads the next person.
5. If it is a FIFO, start the reader before the writer. In a backup pipeline that means ordering the consumer first, and in an external-table unload it means having the reading process attached before the unload begins.
6. If the configuration is wrong, fix the chunk path or offset rather than creating a device node to match it. Manufacturing a node to satisfy the error is the worst available outcome — it will appear to work and then fail somewhere much less obvious.
7. Do not bring a chunk back online until dd can read from the device.
8. Re-test the Informix operation rather than assuming the storage fix propagated.

Examples

The device node is there; the LUN is not

$ ls -l /dev/sdd1
brw-rw---- 1 ifxprod ifxprod 8, 49 Mar 14  2024 /dev/sdd1

$ lsblk | grep sdd
$ 

$ dmesg -T | grep -i sdd | tail -3
[Mon Sep  8 22:11:04 2026] sd 2:0:1:4: [sdd] Synchronizing SCSI cache
[Mon Sep  8 22:11:04 2026] sd 2:0:1:4: [sdd] Stopping disk
[Mon Sep  8 22:11:05 2026] scsi 2:0:1:4: rejecting I/O to offline device

The node survived; the device was removed from the host the previous evening. No amount of work inside Informix will help — the LUN has to come back, and onstat -d will show the chunk down until it does.

A named pipe with no reader

An external-table unload configured to write to a FIFO:

$ ls -l /informix/pipes/unload.pipe
prw-r--r-- 1 ifxprod ifxprod 0 Sep  9 09:14 /informix/pipes/unload.pipe

$ fuser -v /informix/pipes/unload.pipe
$ 

Nothing has the pipe open. The unload opens it for writing, finds no reader, and gets ENXIO. Starting the consuming process first resolves it — the ordering is the fix, not the permissions or the path.

A tape device with no tape

Archive failed: cannot open device /dev/rmt0
system error = 6

$ mt -f /dev/rmt0 status
/dev/rmt0: No such device or address

The device node exists because it was created when the drive was configured. The drive is empty, offline, or powered down. Load media and re-check mt status before re-running the archive.

A configuration carried from another host

$ grep -n datadbs "$INFORMIXDIR/etc/$ONCONFIG"
# chunk path /dev/vx/rdsk/ifxdg/datadbs01

$ ls -l /dev/vx/rdsk/ifxdg/datadbs01
crw-r----- 1 ifxprod ifxprod 199, 12 Jul 02 11:20 /dev/vx/rdsk/ifxdg/datadbs01

$ lsblk | grep -c ifxdg
0

A Veritas volume path from the host this configuration was copied from. The node was copied or recreated; the volume group was not imported here. Fix the configuration to name this host's storage — do not create a matching device node.

Platform Note

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

Device naming and the tools for inspecting it are not portable at all, and on this error those tools are the diagnosis:

Task	Linux	Solaris	AIX
List devices	lsblk, lsscsi	format, cfgadm -al	lsdev -Cc disk, lspv
Rescan for new storage	echo "- - -" > …/scan	devfsadm, cfgadm -c configure	cfgmgr
Stale node cleanup	udevadm, remove node	devfsadm -C	rmdev -dl <dev>
Tape status	mt -f /dev/st0 status	mt -f /dev/rmt/0 status	tctl -f /dev/rmt0 status
Multipath	multipath -ll	mpathadm list lu	lspath

On AIX, a device in Defined rather than Available state is the usual cause and lsdev shows it immediately — that has no direct Linux equivalent and is worth checking first on that platform.

Related Errors / Related Topics

• -2 — No such file or directory. The path itself is gone, rather than the device behind it. The two are often confused and the check that separates them is ls -l followed by lsblk.
• -5 — I/O error. The device is present and is failing. If the storage came back and you now see -5 instead of -6, you have moved from an absent device to a faulty one.
• -13 — Permission denied on a device node that is present and working.
• -19 — No such device, a closely related condition worth checking if the operation involved mounting or a device-specific ioctl.

Where -6 appears against chunks after SAN work, a host rebuild or a VM clone, check every chunk path rather than the one that failed. Device nodes and configuration files travel between hosts far more readily than the storage they describe, and the remaining chunks are usually one restart from the same fault.