Informix Error -36

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Why This Error Needs More Care Than Most

-36 is the sharpest illustration in this range of why the number alone tells you nothing. Errno 36 means three unrelated things across the three numbering families, and on the platforms where Informix actually runs it means neither of the things the official text describes.

Platform family	errno 36	What it means
Linux (glibc)	ENAMETOOLONG	A pathname or one of its components is too long
Solaris, AIX, HP-UX (System V)	EIDRM	An IPC object was removed while in use
BSD, macOS/Darwin	EINPROGRESS	A non-blocking connect is under way — not an error

The official text — Operation now in progress — is EINPROGRESS, the BSD value. Informix's message catalogue was written when that mapping was the common one and has carried the text forward unchanged.

The consequences are not symmetrical:

• On Linux it is a configuration problem. Something is named too long. Annoying, contained, fixable.
• On Solaris, AIX or HP-UX it means something removed a shared-memory segment, semaphore set or message queue out from under a running process. For a database server that is not a configuration problem, it is an emergency.
• On BSD-derived systems it is not a fault at all — it is the documented response to a non-blocking connect(), and code that treats it as an error is the defect.

One number. A filename, a catastrophe, and a normal return. Confirm which you have before doing anything else.

Determine the Native Error Meaning

On the host that logged the error, not on a workstation:

python3 -c 'import os; print(os.strerror(36))'
perl -e '$! = 36; print "$!\n"'
errno 36                                     # if moreutils is installed

grep -w 36 /usr/include/asm-generic/errno-base.h   # Linux
grep -w 36 /usr/include/asm-generic/errno.h        # Linux
grep -w 36 /usr/include/sys/errno.h                # Solaris, AIX, HP-UX

Each of the three follows below. Read the one that applies and ignore the others — they share nothing.

---

If It Is ENAMETOOLONG (Linux)

A pathname, or a single component of one, exceeded what the filesystem or the kernel will accept. Two separate limits apply and they are commonly confused:

Limit	Typical Linux value	Applies to
PATH_MAX	4096	The whole pathname
NAME_MAX	255	One component between slashes

getconf PATH_MAX /informix
getconf NAME_MAX /informix

The component limit is the one usually breached. A generated filename that concatenates instance name, dbspace, timestamp and sequence number can pass 255 bytes while the full path is nowhere near 4096 — so measuring the path and concluding it is fine is a wrong answer arrived at honestly.

Two further traps:

• Symlink resolution lengthens the path. A path comfortably inside PATH_MAX as written can exceed it once every symlink along it is expanded. The limit applies to the resolved path, not the one you typed.
• The limit belongs to the filesystem, not the host. An NFS export or a mounted filesystem of another type may accept less than the local one. getconf against the specific path is the check, not against /.

Where this arises in Informix

• Backup and archive targets with generated names — the usual source, because the name is assembled from several fields and nobody counts.
• DUMPDIR and assert-failure files, whose names are generated.
• Chunk paths built from long descriptive directory names, particularly after a migration into a deeper directory structure.
• External table data files named from query or job metadata.
• A deep tree that a restore or a container image placed below an already-long mount point.

Side note. Informix also applies its own maximum length to a chunk path, separate from PATH_MAX and NAME_MAX and shorter than both — and shorter again on a non-root installation. It is the engine that refuses, not the kernel, so the checks here will show nothing wrong. Worth knowing when laying out a storage tree; check the figure for your version and installation type.

Checks

printf '%s' "$P" | wc -c                 # whole path, in bytes
basename "$P" | wc -c                    # the component — check this one
readlink -f "$P" | wc -c                 # resolved length, after symlinks

Find the offenders across a tree in one pass:

find /informix -xdev -printf '%f\n' 2>/dev/null | awk '{ if (length($0) > 200) print length($0), $0 }' | sort -rn | head
find /informix -xdev -printf '%p\n' 2>/dev/null | awk '{ if (length($0) > 3500) print length($0), $0 }' | sort -rn | head

Note that these are byte limits, not character limits. A name containing multi-byte UTF-8 characters reaches the limit sooner than its visible length suggests.

Resolution

1. Measure the component, not just the path. Most of these are a 255-byte filename inside a perfectly reasonable directory.
2. Shorten the generated name, not the directory structure. A naming scheme that encodes four fields and a timestamp usually has one field that adds nothing.
3. Check getconf against the target filesystem, especially where a backup writes to NFS.
4. Re-measure after symlink resolution if the path traverses any.

---

If It Is EIDRM (Solaris, AIX, HP-UX)

This is the serious one. EIDRM — Identifier removed — means a System V IPC object that a process was using has been deleted while the process still held a reference to it. The identifier is now invalid and every subsequent operation on it fails.

Informix uses System V shared memory and semaphores. So on these platforms, a -36 reaching the database server means something removed the instance's IPC resources while the instance was running.

That is almost never an accident of the operating system. It is an action somebody or something took.

What removes IPC resources

• ipcrm run against the instance's segments while it is up. The usual shape is a cleanup script that selects by owner — ipcs | grep <owner> | awk ... | xargs ipcrm — and catches a live instance alongside whatever stale objects it was written to remove.
• A "clean up stale IPC" job inherited from another system, or run by a housekeeping process that does not know an instance is running.
• An Informix cleanup utility used while the instance is up rather than after it has stopped.
• A shared host where another team's tidy-up script removes objects it does not own but can.
• A kill-and-clean sequence where the cleanup ran before every virtual processor had actually exited.

Checks — do these before anything else

ipcs -m                        # shared memory segments
ipcs -s                        # semaphore sets
ipcs -mp                       # creator and last-attach PIDs
ipcs -ma                       # full detail including nattch

onstat -g seg                  # what the engine believes it has
onstat -                       # is the instance up at all

Compare the two. Segments the engine expects that ipcs does not list is the confirmation, and it is unambiguous.

Then find out who did it and when:

tail -500 "$INFORMIXDIR/tmp/online.log"
last | head -20
grep -rn 'ipcrm' /etc/cron* /var/spool/cron 2>/dev/null
grep -rn 'ipcrm' /usr/local/bin /opt/*/bin 2>/dev/null

A cron entry containing ipcrm is worth finding whether or not it caused this particular event.

Resolution

1. Do not try to repair a running instance whose IPC has been removed. The shared memory it was using is gone; there is nothing to reattach to. Attempting to continue risks compounding the damage.
2. Establish the instance's actual state from onstat - and the message log before acting. Assume nothing about whether it is up.
3. Expect recovery to be required. The instance has lost its shared memory mid-operation, which is not a clean shutdown. Plan for fast recovery on restart and verify the outcome rather than assuming it.
4. Find and fix the script. This will happen again on the same schedule otherwise. Any cleanup that selects IPC objects by owner alone is unsafe on a host running a database instance.
5. Never remove IPC resources by owner without checking nattch. A segment with attached processes is in use by definition.
6. Clean up stale IPC only when the instance is verifiably down, using the utility Informix provides for it rather than raw ipcrm, and confirm the instance is stopped first.

If the instance will not come back cleanly after an event like this, stop and get help rather than making a second attempt. Oninit® are the Down System Specialists — bringing unresponsive Informix instances back is what we do, and we would far rather hear from you before a recovery attempt than after one.

---

If It Is EINPROGRESS (BSD-derived)

Not an error. connect() on a socket in non-blocking mode returns -1 with errno set to EINPROGRESS to say the connection attempt has started and has not yet completed. The caller is expected to wait for the socket to become writable and then check SO_ERROR for the outcome.

Code that treats this as a failure will break every non-blocking connect it makes. If a -36 appears on a BSD-derived host in connection-handling code, the bug is in the error handling rather than in the network.

Informix's supported platforms do not include the BSD-derived systems, so this meaning is here for completeness — and because it is the one the official text describes, which is why anyone reading the catalogue arrives at the wrong idea first.

---

Common Causes

Grouped by what the errno actually was, because they have nothing in common:

ENAMETOOLONG (Linux)

1. A generated backup or dump filename exceeding the 255-byte component limit.
2. A path that exceeds PATH_MAX only after symlink resolution.
3. A target filesystem — often NFS — with a lower limit than the local one.
4. A tree relocated below an already-long mount point by a restore, a container image or a migration.

EIDRM (Solaris, AIX, HP-UX)

5. ipcrm run against a live instance's segments, usually by a cleanup script selecting on owner.
6. A stale-IPC housekeeping job that does not check nattch.
7. Cleanup run before every virtual processor had exited.

EINPROGRESS (BSD-derived)

8. Error-handling code treating a normal non-blocking connect() return as a failure.

Diagnostic Checks

Confirm the symbol. On this code more than any other, everything downstream depends on it:

python3 -c 'import os; print(os.strerror(36))'

Then establish what the engine was doing, which usually distinguishes the two live meanings on its own — a file operation points at a name, an operation against shared memory points at IPC:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -m
onstat -                                    # instance state

The platform-specific checks are in the sections above. Run the set that matches the symbol you confirmed; running the other set will produce nothing and cost time you may not have if this is the EIDRM case.

Examples

Linux: the path is fine, the filename is not

$ printf '%s' "$TARGET" | wc -c
312

$ basename "$TARGET" | wc -c
271

$ getconf NAME_MAX /backups
255

The full path is a twelfth of PATH_MAX. The filename is over the component limit by sixteen bytes. Measuring the path — which is the instinctive check — says everything is fine.

The name here was assembled from instance, dbspace, backup level, hostname and an ISO timestamp. Dropping the hostname, which is implied by the directory it is written to, resolves it permanently.

Solaris: segments the engine expects are not there

$ onstat -
shared memory not initialized for INFORMIXSERVER 'prod_inst'

$ ipcs -m | grep <owner>
$

Nothing. The message log's final entries will show where it stopped.

$ grep -rn ipcrm /var/spool/cron/crontabs/ 2>/dev/null
/var/spool/cron/crontabs/root:0 3 * * 0 /usr/local/bin/cleanup_ipc.sh

A weekly job. Whatever it was written to tidy up, it selected this instance's segments too — and it will do so again next Sunday unless it is fixed. The immediate work is recovery; the work that prevents a repeat is in that script.

Platform Note

This is the code that justifies the platform check at the top of every page in this range.

Platform	errno 36	Severity
Linux	ENAMETOOLONG	A naming problem
Solaris	EIDRM	IPC removed under a running process
AIX	EIDRM	IPC removed under a running process
HP-UX	EIDRM	IPC removed under a running process
BSD, Darwin	EINPROGRESS	Not an error

Tooling follows the same split. For the name case: getconf, find -printf, readlink -f on Linux. For the IPC case: ipcs/ipcrm on all the System V platforms, with ipcs -ma giving the attach counts that make removal decisions safe.

A runbook that reads "-36 means an operation is in progress" is describing a platform Informix does not run on, and is actively dangerous on the three where the same number means a database server has just lost its shared memory.

Related Errors / Related Topics

• -35 — the code immediately before this one, and the first in the range where the numbering families diverge. The same discipline applies: read the symbol, not the sentence.
• -2 — No such file or directory. The other error a wrong path produces, and the one to check alongside ENAMETOOLONG when a generated path is involved — a truncated name usually reports -2 rather than -36.
• -17 — File exists, which covers Informix shared-memory identifiers and what happens when two instances collide over them. Relevant background for the EIDRM case above.

Where -36 appears on a System V platform, treat it as an operational incident rather than a diagnostic curiosity, and check ipcs before anything else. Where it appears on Linux, count the filename.