Informix Error -17

Operating-System Meaning

errno 17 is EEXIST — File exists. Something was asked to create an object that is already there, and the request specified that creation must be exclusive.

The key word is exclusive. An ordinary open() of an existing file succeeds happily; EEXIST only arises where the caller said create this, and fail if it already exists — O_CREAT | O_EXCL, mkdir(), link(), or a System V IPC creation with IPC_EXCL.

That makes -17 unusual in this range: it is frequently a protective refusal rather than a fault. Something declined to overwrite what was already there. The right response is often to work out why the object exists, not to remove it so the operation can proceed.

The name is also narrower than the error. Despite "File exists", the most consequential Informix case involves no file at all — it is a shared-memory segment.

What This Means in Informix

Shared-memory key collision — the case that matters

The shared-memory key is derived from SERVERNUM. Two instances on the same host must therefore have distinct SERVERNUM values. If they collide, the second instance to start finds segments already present under the key it is trying to create, and fails — and errno 17 is what that can surface as.

This has the same origin as the duplicate chunk path on -16: a configuration copied to build a second instance, with the values left unchanged. It is worth checking both at once, because a copied onconfig usually carries more than one collision.

The two fail differently. A duplicate SERVERNUM fails loudly at startup, because the resource is already there to collide with. A duplicate chunk path fails at nothing and destroys data quietly.

What follows for cleanup

Deriving the key from SERVERNUM has a second consequence, which applies before reaching for a cleanup.

onclean releases the shared memory and semaphores selected by SERVERNUM, not by instance name. That is what makes it the right tool — it knows what belongs to the instance instead of relying on you picking IDs out of ipcs by eye — and it is also why the value being unique matters at exactly this moment.

It is not a loaded gun. The engine's startup and lock files are checked, and they will normally stop onclean releasing the resources of an instance that is actually running. So the realistic failure here is a wasted step and a misread fault, not a destroyed production instance.

The reason to care is simpler than danger: on a SERVERNUM collision there are no stale segments to clean. The segments are present because another instance legitimately has them. A cleanup is the wrong response because it is aimed at a problem that does not exist, and running it leaves the actual fault — two configurations sharing a value — untouched and undiagnosed.

So on a -17 at startup, in this order:

1. Compare SERVERNUM across every onconfig on the host, before anything else. It is one command and it decides everything that follows.
2. If two collide, that is the fault. Fix the configuration; there is nothing to clean up.
3. Only once you have established the values are distinct does the stale-segment path below apply.

A cleanup is rarely the first correct response to a -17 on a multi-instance host, and on a collision it is never the right one.

A useful aside on privilege

Removing segments by hand with ipcrm usually requires root, because on a root installation the segments are owned by root. onclean does not: it releases the instance's shared memory and semaphores without needing root, even where the segments are root-owned.

So if you are working as the instance owner and ipcrm refuses with Operation not permitted — which is -1 — the answer is onclean, not sudo. It is both the tool that does not need elevating and the tool that checks whether the instance is really down first.

Stale segments after an abnormal termination

The other common case is an instance that did not shut down cleanly. Its shared memory can outlive the processes, so a restart finds segments under its own key and refuses.

Before removing any shared-memory segment, prove the instance is actually down. Removing segments belonging to a running engine will corrupt it immediately and without warning. ipcrm does not ask, and there is no undo.

Protective refusals

• A backup or unload target that already exists, where the tooling declines to overwrite.
• REPORT TO in 4GL, named directly by the official text — a report attempting to create an output file that is already there.

Elsewhere

• mkdir in a script for a directory that exists, usually harmless and usually a missing -p
• Lock files created with O_EXCL by wrappers and housekeeping jobs, where a stale one blocks the next run
• Temporary files with predictable names colliding between concurrent runs

Common Causes

1. Duplicate SERVERNUM between instances on one host.
2. Stale shared memory from an instance that terminated abnormally.
3. An existing file where a utility or script was asked to create one exclusively.
4. A stale lock file from a previous run of a script.
5. A missing mkdir -p in a wrapper.
6. Concurrent runs of the same job colliding on a fixed temporary filename.

Diagnostic Checks

Establish whether this is the shared-memory case first, since it is both the most likely and the most serious:

grep -nE '^(SERVERNUM|DBSERVERNAME|SHMBASE)' "$INFORMIXDIR"/etc/onconfig*

Any two configurations sharing a SERVERNUM is the answer. Then look at what is actually allocated, and who owns it:

ipcs -m
ipcs -m | awk 'NR>3 {print $1, $2, $3, $6}'    # key, id, owner, nattch
onstat -g seg

nattch is the column that matters. A segment with processes attached belongs to something that is running; a segment with nattch of zero is a candidate for cleanup — but confirm that independently rather than trusting the count alone:

ps -o pid,user,cmd -C oninit
onstat -                      # per instance, with that instance's environment

For each instance you believe is down, verify it really is before touching anything:

INFORMIXSERVER=ol_test ONCONFIG=onconfig.test onstat -
# "shared memory not initialized" = down
# anything else                    = RUNNING, do not remove its segments

If the failing operation was a file creation rather than shared memory:

ls -l /path/to/target
stat /path/to/target
lsof /path/to/target           # is anything using it?
fuser -v /path/to/target

Before removing what looks like an orphaned chunk file, check it is not a live chunk in another dbspace:

onstat -d | awk '/^[0-9]/ {print $NF}' | while read -r p; do readlink -f "$p"; done | grep -F "$(readlink -f /path/to/target)"

For stale lock files, find out whether the owner still exists:

ls -l /path/to/lockfile
cat /path/to/lockfile                       # often a PID
kill -0 "$(cat /path/to/lockfile)" 2>&1     # see -3

Solutions / Resolution

1. Work out why the object exists before removing it. On this error the object is usually there for a reason, and removing it is frequently the wrong move.

For the shared-memory cases:

2. Give every instance on a host a distinct SERVERNUM. Check DBSERVERNAME and the chunk paths at the same time — a copied onconfig rarely gets only one thing wrong.
3. Rule out a SERVERNUM collision before cleaning anything. On a collision there is nothing stale to clean — the segments belong to a running instance that legitimately has them — so a cleanup is effort spent on a problem that does not exist while the real fault goes unfixed.
4. Then clean stale segments, once the instance is confirmed down. onclean releases the shared memory and semaphores the engine was using, selected by SERVERNUM, and checks the startup and lock files rather than taking your word for it — which is what makes it the right tool. It also needs no root. If you use ipcrm instead — which typically does need root, since the segments are commonly root-owned — remove only the specific IDs you have confirmed, never everything owned by the account:

   # confirm down first, then, for a specific id:
   ipcrm -m <shmid>
   

5. Never remove a segment with processes attached, and never remove segments belonging to an instance you have not individually verified as down. On a host running several instances this is the most dangerous operation described here.

For the file cases:

6. Do not blindly delete the existing file. Confirm it is not a live chunk, a current backup, or an output someone is relying on.
7. Do not assume a utility refused in order to protect you. Establish what the refusal actually was before removing anything — see the note under Examples on what onspaces actually checks, which is far less than people expect.
8. Fix scripts rather than their symptoms — mkdir -p, unique temporary filenames, and lock files that are cleaned up on exit and validated with kill -0 on read.
9. For REPORT TO, have the report write to a unique name or remove the previous output deliberately as part of the job.

Examples

Duplicate SERVERNUM

$ grep -H '^SERVERNUM' "$INFORMIXDIR"/etc/onconfig.prod "$INFORMIXDIR"/etc/onconfig.test
/opt/informix/etc/onconfig.prod:SERVERNUM 0
/opt/informix/etc/onconfig.test:SERVERNUM 0

$ ipcs -m | head -4
key        shmid      owner      perms      bytes      nattch
0x52564800 163841     ifxprod    660        536870912  42

Both configurations claim server number 0, so both derive the same key. The production instance holds it with 42 processes attached; the test instance cannot create it and will not start. The fix is in onconfig.test, and nothing about the running instance should be touched.

Stale segments after a crash

$ INFORMIXSERVER=ol_prod onstat -
shared memory not initialized for INFORMIXSERVER 'ol_prod'

$ ipcs -m | grep ifxprod
0x52564800 163841     ifxprod    660        536870912  0
0x52564801 163842     ifxprod    660        268435456  0

$ ps -C oninit
   PID TTY          TIME CMD
$

Three checks agree: the engine reports itself down, no oninit processes exist, and the segments have nothing attached. Only now is cleanup safe. Had nattch been non-zero, or had onstat returned anything other than "not initialized", removing these would have destroyed a running instance.

What onspaces actually checks — and what it does not

It is worth being precise here, because the assumption that a utility refused in order to protect you is a comfortable one and it is wrong.

When creating a cooked chunk, onspaces checks that the path is valid and that the permissions are 660, owned by the instance owner — informix:informix on a root installation, or the installing account's own user and group on a non-root one.

Two consequences follow, and neither is what people expect:

• The file existing is a precondition, not a refusal. A cooked chunk file is created and given the right ownership and mode before onspaces is run. "File already exists" is the normal state, not an error condition.
• onspaces does not check whether that file is in use by another instance. The permission check is the whole of the safety, and a live chunk belonging to a different instance passes it perfectly. This is the creation-time face of the hazard described on -16, and it deserves the same proactive check.

So the errors you will genuinely meet here are permission and ownership errors — -13 — rather than -17:

$ ls -l /informix/chunks/datadbs2
-rw-r--r-- 1 root root 2147483648 Aug 14 09:11 /informix/chunks/datadbs2

Wrong owner, wrong mode. The requirement is the instance owner and 660:

$ chown ifxprod:ifxprod /informix/chunks/datadbs2
$ chmod 660            /informix/chunks/datadbs2
$ ls -l                /informix/chunks/datadbs2
-rw-rw---- 1 ifxprod ifxprod 2147483648 Aug 14 09:11 /informix/chunks/datadbs2

Before creating the chunk, confirm independently that nothing else already owns that path — onspaces will not do it for you.

A stale lock file

$ ls -l /informix/run/nightly.lock
-rw-r--r-- 1 ifxprod ifxprod 6 Sep  8 02:00 /informix/run/nightly.lock
$ cat /informix/run/nightly.lock
28841
$ kill -0 28841
bash: kill: (28841) - No such process

Yesterday's run was terminated without cleaning up. The lock's owner is long gone, so the file is safe to remove — but the durable fix is a wrapper that validates the recorded PID rather than treating the file's existence as proof, and removes its lock on exit.

Platform Note

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

Shared-memory inspection and cleanup differ:

Task	Linux	Solaris	AIX
List segments	ipcs -m	ipcs -m	ipcs -m
Attached processes	ipcs -mp, nattch column	ipcs -mp	ipcs -mp
Remove a segment	ipcrm -m <id>	ipcrm -m <id>	ipcrm -m <id>
Who is attached	lsof | grep <id>, /proc/*/maps	pmap, pfiles	svmon -P, procmap

The System V IPC interface is consistent across these platforms, which is unusual for this range — but the consequence of removing a live segment is identical everywhere, so the verification step matters regardless of platform.

Related Errors / Related Topics

• -16 — Device or resource busy. The other error produced by two instances colliding on the same host, and worth checking together: a copied configuration that duplicates SERVERNUM very often duplicates chunk paths too.
• -2 — No such file or directory, the opposite condition.
• -13 — Permission denied, worth ruling out where a creation fails and the object does not appear to exist.

Where -17 appears after cloning an instance, check SERVERNUM, DBSERVERNAME, ROOTPATH and the chunk paths as a set. They are all derived from the same copied file, and finding one collision is good reason to assume there are others.