Oninit
Talk to an expert →

Informix Error -8

-8 Exec format 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

On Unix and Linux, errno 8 is ENOEXEC — Exec format error. The kernel was handed a file to execute, found it, had permission to read it, but did not recognise it as something it can load and run in this environment.

This is worth separating from the errors it gets confused with:

errno Symbol Meaning What actually failed
2 ENOENT No such file or directory The file — or a script's interpreter — was not found
13 EACCES Permission denied The file was found but is not executable, or a directory on the path is not searchable
8 ENOEXEC Exec format error The file was found and is readable, but its format is not loadable

Informix is not diagnosing anything here. It asked the operating system to run a program, the exec() call failed, and the engine is surfacing the OS's errno. The useful question is therefore not "what does Informix mean by -8?" but "what did the operating system refuse to execute, and why?"

What This Means in Informix

Informix executes external programs in more places than people usually expect. Error -8 can surface from:

  • ontape / onbar invoking a storage-manager or backup script
  • ON_BAR configuration pointing at BAR_BSALIB_PATH or a backup helper
  • ALARMPROGRAM (typically alarmprogram.sh / log_full.sh) fired on an event
  • External tables using a named PIPE with a command, or EXTERNAL table load/unload filters
  • A C UDR or DataBlade shared object being loaded
  • SYSTEM calls from SPL, and system() from ESQL/C or 4GL
  • Reports with a REPORT TO PIPE specification
  • dbexport / dbimport wrapper scripts
  • Custom monitoring, housekeeping, or cron scripts run under the installation owner's account
  • Client-side application launchers in a 4GL or ESQL/C estate
Common Causes
  1. Wrong CPU architecture — a binary built for a different processor family than the host.
  2. Binary copied between operating systems — an AIX (XCOFF) or Solaris (SPARC ELF) executable dropped onto a Linux x86_64 host, or vice versa.
  3. Bad or missing shebang line — the interpreter path in a script's first line does not exist on this host.
  4. Windows CRLF line endings — the shebang reads #!/bin/bash\r, so the kernel looks for an interpreter whose name ends in a carriage return.
  5. A data file executed as a program — a path or variable built incorrectly, so the engine tries to run a .dat, .sql, or .txt file.
  6. Truncated or corrupt binary — an interrupted copy, a failed scp, or a file restored from a partial archive.
  7. 32-bit binary on a host without 32-bit runtime support, or a shared object built for the wrong bitness.
  8. Container/host architecture mismatch — an image built for linux/amd64 scheduled onto an arm64 node, or a helper binary inside the image built for the wrong platform.
Diagnostic Checks

Start with the object itself. In almost every case, file answers the question in one line.

file /path/to/the/object
uname -m
head -1 /path/to/the/script | cat -v
ls -l /path/to/the/object

Find which object Informix tried to run — the message log usually names it, or names the operation that led to it:

tail -200 "$INFORMIXDIR/tmp/online.log"
grep -n -E 'ALARMPROGRAM|BAR_BSALIB_PATH|BAR_ACT_LOG' "$INFORMIXDIR/etc/$ONCONFIG"
onstat -m

Confirm the interpreter a script asks for actually exists:

head -1 script
ls -l /usr/local/bin/bash
command -v bash

For shared objects and UDRs, the loader gives a better message than the kernel does:

file /path/to/udr.so
ldd /path/to/udr.so
readelf -h /path/to/udr.so | head -20
Solutions / Resolution

Work in this order — the cheap checks resolve the large majority of cases:

  1. Run file on the object. If it reports text, a different OS's format, or a different architecture, you already have your answer and no permission or ownership change will help.
  2. Architecture or OS mismatch — obtain or rebuild a binary for the target platform. Do not attempt to force execution of a foreign-format binary.
  3. Shebang — correct the interpreter path, or make it portable: #!/usr/bin/env bash.
  4. CRLF endings — strip them: dos2unix script, or sed -i 's/\r$//' script.
  5. Wrong object being executed — fix the path or variable construction. If file says the target is ordinary text or data, chmod +x is the wrong fix; it converts a clear error into a confusing one.
  6. Truncated binary — compare size and checksum against a known-good copy and re-transfer in binary mode.
  7. Re-test the specific Informix operation (the backup, the alarm, the UDR call) rather than assuming the fix took.
Examples
Wrong CPU architecture

A monitoring helper called from ALARMPROGRAM fails after a server migration:

$ file /opt/oninit/bin/process_data
/opt/oninit/bin/process_data: ELF 64-bit LSB executable, ARM aarch64
$ uname -m
x86_64

The binary was built on an aarch64 build host. It cannot execute natively on this x86_64 server; it must be rebuilt for the target.

Binary carried across from AIX

During a migration from AIX to Linux, a /informix filesystem is restored wholesale, including local tooling:

$ file /informix/bin/custom_loader
/informix/bin/custom_loader: executable (RISC System/6000) or object module

This is an XCOFF object — an AIX executable. Restoring an old /informix tree onto a new OS commonly brings along ESQL/C tools, 4GL runners, and loaders that must all be rebuilt for the new platform.

Bad shebang
$ head -1 /informix/scripts/log_full.sh
#!/usr/local/bin/bash
$ ls -l /usr/local/bin/bash
ls: cannot access '/usr/local/bin/bash': No such file or directory
$ command -v bash
/bin/bash

The script was written on a host where Bash lived under /usr/local. Note that this case can also surface as errno 2 rather than 8 depending on platform — another reason to check the object rather than reason from the number.

Windows CRLF line endings

A script edited on a Windows workstation and copied to the server:

$ head -1 alarmprogram.sh | cat -v
#!/bin/bash^M
$ file alarmprogram.sh
alarmprogram.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

The kernel is looking for an interpreter literally named /bin/bash\r. Fix with dos2unix alarmprogram.sh.

Data file executed as a program

A wrapper builds a command from a variable and gets the wrong one:

$ file /informix/data/export.dat
/informix/data/export.dat: ASCII text

The intended target was /informix/bin/process_export. The fix is in the command construction, not on the data file.

Container / OpenShift architecture mismatch

A container can start correctly and still contain a helper binary for the wrong architecture:

$ uname -m
x86_64
$ file /informix/bin/start_helper
/informix/bin/start_helper: ELF 64-bit LSB executable, ARM aarch64

On OpenShift, check what the pod actually landed on:

oc get nodes -o wide
oc get node <node> -o jsonpath='{.status.nodeInfo.architecture}'

In a mixed-architecture cluster, pin the workload with a nodeSelector on kubernetes.io/arch, or publish a multi-architecture image manifest.

Platform Note

errno 8 is ENOEXEC on Linux, AIX, Solaris, HP-UX, and the BSD-derived systems — this is one of the low-numbered errno values that is stable across Unix implementations, so the number can be trusted here more than it can in the -32 to -99 range.

What is not uniform is which failure produces it. A missing interpreter may yield errno 2 on one platform and errno 8 on another, and some platforms report a mis-formatted shebang differently again. Confirm the meaning on the host if anything looks inconsistent:

grep -w 8 /usr/include/asm-generic/errno-base.h     # Linux
python3 -c 'import os; print(os.strerror(8))'       # any host with Python
perl -e 'print $!=8, "\n"'                          # any host with Perl
Related Errors / Related Topics
  • -2 — No such file or directory. The object, or a script's interpreter, was not found at all.
  • -13 — Permission denied. The object exists and is loadable, but the execute bit or a directory's search permission blocks it.
  • -12 — Not enough core / cannot allocate memory, which can also surface during process creation.

If -8 appeared during a migration, server rebuild, or a move onto containers, it is usually one symptom of a broader platform-compatibility sweep that should cover every custom binary in the estate — ESQL/C tools, 4GL runners, UDR shared objects, and backup helpers alike.