Oninit
Talk to an expert →

Informix Error -3

-3 No such process.

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 3 is ESRCH — No such process. A process ID was given to an operation such as kill() and no process with that ID exists.

ESRCH means the target is gone, which is why it is usually benign. It arrives almost exclusively from signalling, and the pairing with -1 is what makes it diagnosable:

kill() result Meaning What to do
success The process exists and you may signal it —
EPERM (-1) The process exists; you may not signal it Run as the right account
ESRCH (-3) The process does not exist Usually nothing — it has already exited

A script that treats both failures as "could not stop the server" will send you looking for a permissions problem when the server had in fact already stopped, or the reverse. The two need different handling.

What This Means in Informix

Nearly always a shutdown, cleanup, or monitoring path signalling a process that has already exited:

  • A stop script reading a stale PID file left behind by a previous run
  • onmode -ky or a wrapper signalling oninit after the server has already come down
  • A monitoring script that captured a PID from ps, then signalled it moments later — the process exited in between
  • Cleanup code signalling the processes attached to a shared-memory segment, where those processes are already gone
  • A watchdog signalling a session's client process after the session ended
  • Container PID namespaces — a PID observed on the host is meaningless inside the container and vice versa, so a cross-namespace signal reports ESRCH even though the process is running
Common Causes
  1. A stale PID file naming a process that no longer exists — by far the most common.
  2. A race between reading a PID and using it. Unavoidable in principle; the fix is to handle it, not to prevent it.
  3. The operation already succeeded. The server was stopped, and something tried to stop it again.
  4. PID namespace mismatch in a containerised deployment.
Diagnostic Checks

kill -0 is the right existence test — it sends no signal and distinguishes all three outcomes:

kill -0 "$pid" 2>&1; echo "exit=$?"
#   exit 0                  -> exists, signallable
#   "Operation not permitted" -> exists, wrong user  (see -1)
#   "No such process"         -> gone                (this error)

Then confirm what is actually running, and compare against whatever recorded the PID:

ps -p "$pid" -o pid,user,cmd
ls -d /proc/"$pid" 2>/dev/null || echo "pid $pid is gone"
ps -o pid,user,cmd -C oninit
cat /path/to/pidfile

For a server that may already be down:

onstat -        # "shared memory not initialized" means it is already stopped
onstat -g seg
ipcs -m | grep -i "$(id -un)"

In a container, check which namespace you are looking from:

readlink /proc/self/ns/pid
ps -ef                       # inside the container
nsenter -t "$pid" -p ps -ef  # from the host, into the container's namespace
Solutions / Resolution
  1. Check whether the operation already succeeded. If the intent was to stop something and it is not running, -3 is a success reported as a failure. This covers most occurrences.
  2. Fix stale PID files — have the writer remove its file on exit, and have the reader validate with kill -0 before acting on the contents rather than trusting them.
  3. Handle the race explicitly in scripts. Treat ESRCH as "already gone, continue" and EPERM as a real error:
    if kill -0 "$pid" 2>/dev/null; then
    kill -TERM "$pid"
else
    echo "pid $pid already gone — nothing to do"
fi
  4. Do not retry in a loop. The process will not come back; repeated signalling only delays the script.
  5. For containers, signal from within the correct namespace rather than translating PIDs across the boundary.
Examples
A stale PID file
$ cat /informix/run/oninit.pid
28841
$ kill -0 28841
bash: kill: (28841) - No such process
$ ps -o pid,cmd -C oninit
   PID CMD
  31006 oninit -iv

The server is running — under a different PID. The file was written by a previous start and never cleaned up, so the stop script is signalling a dead PID while the live server carries on. The fault is in the PID file's lifecycle, not in the server.

Already stopped
$ onmode -ky
$ echo $?
0
$ /informix/scripts/stop_ifx.sh
kill: (31006) - No such process

The wrapper ran after the server was already down. Nothing is wrong; the script simply reports its own redundancy as an error. Guarding the kill with kill -0 removes the noise.

Platform Note

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

On most platforms kill -0 against a process owned by another user returns EPERM rather than ESRCH, which is what makes the two distinguishable. Do not rely on ESRCH alone to mean "not running" when the process might belong to a different account — check with ps as well.

Related Errors / Related Topics
  • -1 — Operation not permitted. The other outcome of a failed signal, and the one that actually needs fixing: the process exists and the caller may not signal it.
  • -4 — Interrupted system call, also commonly seen around signal handling.