Oninit
Talk to an expert →

Informix Error -2

-2 No such file or directory.

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.

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 2 is ENOENT — No such file or directory. A path was resolved and something along it does not exist.

The trap is that ENOENT frequently refers to something other than the file you were thinking about:

You asked for ENOENT may actually mean
A file A directory in its path does not exist
A symlink The link exists; its target does not
A script The script exists; the interpreter in its #! line does not
A shared object The .so exists; a library it depends on does not
$INFORMIXDIR/etc/x $INFORMIXDIR was empty, so the path became /etc/x

So "but the file is right there" is a normal and correct observation on this error. It just is not the thing that was missing.

Distinguishing it from its neighbours:

  • -2 ENOENT — a path component genuinely does not exist.
  • -13 EACCES — everything exists, but a directory on the path lacks the search bit, or the file's mode denies the access.
  • -8 ENOEXEC — the file exists and is readable, but is not a loadable executable format.

A missing interpreter sits awkwardly between -2 and -8: the kernel reports ENOENT because /usr/local/bin/bash does not exist, while the user is looking at a script that plainly does.

What This Means in Informix

Common origins:

  • Chunk paths — a cooked file or, more often, a symlink to a raw device whose target has gone
  • $ONCONFIG — unset, misspelled, or naming a file that is not in $INFORMIXDIR/etc
  • sqlhosts — missing, or $INFORMIXSQLHOSTS pointing somewhere that does not exist
  • The environment being absent entirely, typically under cron or systemd, so every $INFORMIXDIR-relative path collapses
  • ALARMPROGRAM or a backup wrapper naming a script that is not there
  • Backup and restore — an archive or logical-log file not present at the expected path, or a tape device node missing
  • UDR and DataBlade shared objects — the .so present but a dependency missing
  • External tables — the data file or named pipe absent at load time
  • DBSPACETEMP naming a dbspace or directory that does not exist
Common Causes
  1. A dangling symlink to a raw device. Device names are not stable across reboots, so /dev/sdc1 can become /dev/sdd1 and the chunk symlink now points at nothing.
  2. The environment is not set in the context that failed — cron, systemd, a container entrypoint, or sudo without -i. $INFORMIXDIR unset turns $INFORMIXDIR/etc/$ONCONFIG into /etc/.
  3. $ONCONFIG names a file that does not exist, often after a copy where the variable was updated and the file was not, or vice versa.
  4. A missing interpreter in a script's #! line.
  5. A missing shared library behind a UDR or a client application.
  6. A path that was correct on another host — a runbook, script, or onconfig carried across from a server with a different layout.
  7. Something was cleaned up — a housekeeping job, a log rotation, or a restore that did not recreate the full tree.
  8. A relative path resolved from an unexpected working directory.
Diagnostic Checks

Find out which path failed, then test the whole path rather than the leaf:

tail -200 "$INFORMIXDIR/tmp/online.log"
onstat -m

namei -l is the most efficient check here — it walks every component and shows exactly where resolution stops:

namei -l /path/to/object
ls -l  /path/to/object
ls -lL /path/to/object        # dereference: a broken symlink shows here
readlink -f /path/to/object
test -e /path/to/object && echo exists || echo MISSING

A dangling symlink is the case ls -l alone will not reveal — it happily prints the link. Find them across the chunk paths in one pass:

onstat -d
onstat -d | awk '/^[0-9]/ {print $NF}' | while read -r p; do
    [ -e "$p" ] || echo "MISSING: $p"
done
find /informix/chunks -xtype l          # broken symlinks only

Confirm the environment is what you think it is, in the context that failed rather than in your login shell:

env | grep -i informix
echo "INFORMIXDIR=[$INFORMIXDIR] ONCONFIG=[$ONCONFIG]"
ls -l "$INFORMIXDIR/etc/$ONCONFIG"
ls -l "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"

Empty brackets in that second line are the answer on their own. To see what cron actually gives you, capture it rather than guess:

* * * * * env > /tmp/cron.env 2>&1

For scripts and shared objects, check the indirection:

head -1 /path/to/script
ls -l "$(head -1 /path/to/script | sed 's|^#!||; s| .*||')"
ldd /path/to/udr.so | grep 'not found'

For raw devices, check whether the name has moved:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
ls -l /dev/disk/by-id/ | grep -i informix
blkid
Solutions / Resolution
  1. Run namei -l on the full path before concluding anything. It names the missing component directly and ends most investigations immediately.
  2. If it is a dangling symlink, repoint it — and then fix the underlying instability rather than just the link. Chunk symlinks should target stable identifiers (/dev/disk/by-id/..., a udev rule, or an LVM logical volume), never kernel-assigned /dev/sdX names.
  3. If the environment is missing, set it in the failing context. Source the profile explicitly in the cron entry or the systemd unit rather than relying on inheritance, and use absolute paths in scripts.
  4. If $ONCONFIG is wrong, reconcile the variable and the file in $INFORMIXDIR/etc. Both must agree; neither alone is authoritative.
  5. If an interpreter is missing, correct the #! line or make it portable with #!/usr/bin/env bash.
  6. If a library is missing, install it or fix the search path — ldd naming a dependency as not found is the direct answer.
  7. Do not create an empty file to satisfy the error. A zero-length chunk file or onconfig turns a clear failure into a much worse one.
  8. Re-test the specific Informix operation rather than the path.
Examples
A chunk symlink pointing at a device that moved
$ ls -l /informix/chunks/datadbs1
lrwxrwxrwx 1 ifxprod ifxprod 9 Mar 14  2024 /informix/chunks/datadbs1 -> /dev/sdc1

$ ls -lL /informix/chunks/datadbs1
ls: cannot access '/informix/chunks/datadbs1': No such file or directory

$ lsblk -o NAME,SIZE
NAME   SIZE
sda    500G
sdb    2T
sdd    2T

The link is intact, the device is not. An HBA rescan or a reboot renumbered the disks and sdc is now sdd. Repointing the symlink restores service, but the correct fix is to target /dev/disk/by-id/ so the next reboot does not do it again.

The environment is empty under cron

A nightly job that works by hand and fails at 02:00:

$ crontab -l
0 2 * * * /informix/scripts/nightly_archive.sh

$ head -3 /informix/scripts/nightly_archive.sh
#!/bin/bash
ontape -s -L 0

cron provides almost no environment, so $INFORMIXDIR is unset, ontape is not on PATH, and any $INFORMIXDIR/etc/$ONCONFIG reference resolves to /etc/. The fix is in the script:

#!/bin/bash
. /home/ifxprod/informix/.profile        # or set the variables explicitly
export INFORMIXDIR INFORMIXSERVER ONCONFIG PATH
"$INFORMIXDIR/bin/ontape" -s -L 0
ONCONFIG names a file that is not there
$ echo "$ONCONFIG"
onconfig.prod
$ ls -l "$INFORMIXDIR/etc/$ONCONFIG"
ls: cannot access '/opt/informix/etc/onconfig.prod': No such file or directory
$ ls "$INFORMIXDIR/etc/" | grep -i onconfig
onconfig.std
onconfig.production

The file is onconfig.production; the variable says onconfig.prod. Either rename the file or correct the variable — but do it in the profile that the server actually starts from, not only in your interactive shell.

The file exists; its dependency does not
$ ls -l /informix/extend/mydatablade/mydb.so
-rwxr-xr-x 1 ifxprod ifxprod 284736 Aug  2 11:40 /informix/extend/mydatablade/mydb.so
$ ldd /informix/extend/mydatablade/mydb.so | grep 'not found'
        libxml2.so.2 => not found

The object named in the error is present. The loader is reporting ENOENT for something it needs, which only ldd will show you.

Platform Note

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

The diagnostic commands are less portable. namei is Linux (util-linux); on other platforms walk the path manually or use truss / dtrace / tusc to see which open() failed and on what:

Task Linux Solaris AIX
Trace failing syscall strace -f -e trace=file truss -f -t open truss -f -t open
Broken symlinks find … -xtype l find … -type l ! -exec test -e {} \; as Solaris
Stable device names /dev/disk/by-id /dev/dsk + format lspv, /dev/rhdisk*

Tracing the failing open() is the definitive method when the path is not obvious from the message.

Related Errors / Related Topics
  • -13 — Permission denied. Everything exists but a directory on the path lacks the search bit; namei -l distinguishes the two at a glance.
  • -8 — Exec format error. The file exists and is not a loadable executable. A missing interpreter reports -2 while looking like an -8 problem.
  • -1 — Operation not permitted, the other error that commonly appears when a script is manipulating files or processes it does not own.

Where -2 appears against chunk paths after a reboot, hardware change or restore, treat it as a storage-naming stability question across the whole instance rather than a single broken link — the other chunks are usually one reboot away from the same fault.