Informix Error -37

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.

Determine the Native Error Meaning

Another code where the three numbering families disagree, and where the official text describes the one platform Informix does not run on:

Platform family	errno 37	Meaning
Linux (glibc)	ENOLCK	No locks available
Solaris, AIX, HP-UX (System V)	ECHRNG	Channel number out of range
BSD, macOS/Darwin	EALREADY	Operation already in progress

The official text — Operation already in progress — is EALREADY, the BSD value.

In practice this is ENOLCK on Linux. The System V value is a STREAMS-era device error that essentially never appears in a database context, and the BSD value is not an error at all.

Confirm on the host that logged it:

python3 -c 'import os; print(os.strerror(37))'
perl -e '$! = 37; print "$!\n"'
grep -w 37 /usr/include/asm-generic/errno.h        # Linux
grep -w 37 /usr/include/sys/errno.h                # Solaris, AIX, HP-UX

What ENOLCK Actually Tells You

A file-locking operation could not be performed because the system had no lock resources to give, not because the lock was already held by somebody else.

That distinction decides the whole investigation, because the three lock-related errors are routinely conflated and only one of them is a problem:

Situation	errno on Linux	Is it a fault?
The lock is held by another process (F_SETLK)	EACCES (13) or EAGAIN (11)	No. Normal contention — this is what locking is for
Waiting for the lock would deadlock (F_SETLKW)	EDEADLK (35)	Yes — the kernel detected a cycle and refused
No lock resources available at all	ENOLCK (37)	Yes — the system could not even attempt it

EACCES and EAGAIN mean the locking mechanism worked. ENOLCK means it did not run.

There are two ways to get there:

• The kernel's lock table is exhausted. Rare on a modern Linux system, where record locks are limited by memory rather than by a fixed table, but real on older kernels and on systems with a deliberate cap.
• The lock could not be arranged at all, which on NFS means the lock manager is missing, unreachable, or disabled. This is overwhelmingly the common case.

What This Means in Informix

NFS and the lock manager — the realistic cause

POSIX file locks on an NFS filesystem are not local. They are brokered by the Network Lock Manager — rpc.lockd and rpc.statd on the client and the server, or the integrated lock state in NFSv4. When that machinery is absent or unreachable, a lock request fails with ENOLCK.

Three configurations produce it, and they look quite different from one another:

• The lock daemons are not running on the client, the server, or both.
• The mount, the export or a firewall blocks the lock protocol. On NFSv3 the lock manager uses its own ports, negotiated through the portmapper, and those are easy to miss when someone writes firewall rules for "NFS" and opens 2049 alone. NFSv4 carries locking in the main protocol and does not have this problem.
• The filesystem is mounted -o nolock (or local_lock), which makes locks local to the client and, depending on version and option, either succeeds misleadingly or fails.

Where this reaches Informix:

• Backup and archive targets on NFS. The most common context by a wide margin — ontape, onbar staging, or a wrapper script writing to a shared filesystem.
• A wrapper using flock for mutual exclusion — a nightly job that takes a lock file to stop two runs overlapping, with the lock file on a shared mount.
• External table load and unload files on a shared filesystem.
• Cooked chunks on NFS. Running chunks over NFS has specific requirements that vary by version and platform, and is not something to arrange casually — check your version's documentation rather than assuming either way. If you are seeing ENOLCK against chunk paths, the lock manager is one of the things that configuration depends on.

Whether a specific Informix operation takes a POSIX lock on a given file is version- and platform-dependent, and is not asserted here. What is certain is that ENOLCK means a lock request failed for want of resources — so the question to answer is which file was being locked, and by what. A system-call trace answers it directly.

The -o nolock trap

Mounting with nolock is the most common "fix" found by searching for this error. It should not be used as one.

nolock does not make locking work. It makes locks local to the client, so two hosts mounting the same export can each believe they hold an exclusive lock on the same file simultaneously. For a lock file guarding a backup that is a scheduling annoyance. For anything guarding shared data it removes the protection entirely while leaving every appearance that it is present.

If a mount option is what makes the error go away, understand what was being protected before leaving it that way.

Common Causes

1. NFS lock manager not running — rpc.statd or rpc.lockd absent on the client, the server, or both.
2. Lock protocol blocked by a firewall or a security policy that opened the NFS data port and nothing else. NFSv3 only.
3. A filesystem mounted -o nolock or local_lock, making locks local or unavailable.
4. An NFS server that does not support locking for that export — some appliances and gateway filesystems.
5. A stale lock state after a server or client restart, where statd has not completed recovery.
6. Kernel lock resources exhausted — uncommon on modern Linux, but check it before dismissing it.
7. A shared filesystem that is not NFS at all — a cluster or object-store gateway whose locking semantics differ from a local filesystem's.

Diagnostic Checks

Confirm the symbol, since on the System V platforms this number means something else entirely:

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

Find out whether a network filesystem is involved. This is the first branch and it resolves most cases:

findmnt -t nfs,nfs4,cifs -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS
mount | grep -E 'nfs|cifs'

Look specifically at the options for nolock or local_lock:

grep -E 'nfs' /proc/mounts | grep -oE 'nolock|local_lock=[a-z]+'

Check the lock machinery on the client:

rpcinfo -p localhost | grep -iE 'nlockmgr|status'
systemctl status rpc-statd rpcbind 2>/dev/null
ss -lunp | grep -iE 'statd|lockd'

And on the NFS server, which is where it is more often missing:

rpcinfo -p <nfs-server> | grep -iE 'nlockmgr|status'
showmount -e <nfs-server>

nlockmgr absent from that listing is the answer.

Check the protocol version, since NFSv4 does not have the separate-lock-manager problem at all:

findmnt -t nfs,nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -oE 'vers=[0-9.]+'
nfsstat -m

A v3 mount with nlockmgr unreachable is the classic combination.

Look at the locks the system currently holds, both to gauge scale and to see whether anything is accumulating:

lslocks                              # util-linux, the readable form
wc -l /proc/locks
awk '{print $5}' /proc/locks | sort | uniq -c | sort -rn | head

Identify what was actually being locked:

strace -f -e trace=fcntl,flock -p <pid> 2>&1 | grep -iE 'SETLK|LOCK_EX|ENOLCK'

# Solaris / AIX — though note that errno 37 means something else there
truss -f -t fcntl -p <pid>

Check the kernel side before concluding the table is exhausted, which it usually is not:

dmesg -T | grep -iE 'lockd|statd|nfs.*lock|no locks'
journalctl -k --since '1 day ago' | grep -iE 'lockd|nfs'
sysctl fs.leases-enable fs.lease-break-time 2>/dev/null

Establish the Informix side:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -m
tail -100 "$BAR_ACT_LOG" 2>/dev/null

Solutions / Resolution

1. Establish whether the path is on NFS first. If it is, the lock manager is where to look and the rest of this list mostly does not apply. If it is not, this is a genuinely unusual error and worth tracing.
2. Start the lock daemons on whichever side is missing them — rpcbind and rpc-statd on the client, the equivalent service on the server. This is the fix in most cases and it is a service-management change, not a database one.
3. Open the lock protocol through the firewall, or move the mount to NFSv4 where locking travels in the main protocol. Pinning NFSv3 lock ports and opening them is the traditional approach; moving to v4 removes the problem rather than managing it.
4. Do not reach for -o nolock. It makes locks local to the client, which means two hosts can hold the same exclusive lock at once. Understand what the lock was protecting before you make it ineffective — see the warning above.
5. If statd recovery is incomplete after a restart, give it time and check again before changing anything. Lock reclaim after a server restart takes a grace period by design.
6. If the target is a storage appliance or gateway, confirm it supports NFS locking for that export at all. Some do not, and the answer is to put the file somewhere else rather than to work around it.
7. Reconsider the location rather than the locking. A backup staging area or a lock file does not have to live on a shared filesystem; moving it to local storage removes an entire dependency. Where the file genuinely must be shared, that is a design constraint worth stating explicitly rather than discovering through this error.
8. If kernel lock resources really are exhausted, find what is holding them — /proc/locks grouped by process will name it — rather than raising a limit and moving on.

Examples

An NFS backup target with no lock manager

A nightly archive to a shared filesystem, failing since a server rebuild:

$ findmnt -T /backups -o SOURCE,FSTYPE,OPTIONS
SOURCE               FSTYPE OPTIONS
nas01:/vol/backups   nfs    rw,relatime,vers=3,...

$ rpcinfo -p nas01 | grep -i nlockmgr
$

NFSv3 with no lock manager registered on the server. Every lock request against that mount fails for want of resources, and nothing on the database host has changed — the rebuild dropped a service.

Starting the lock service on the NAS resolves it. Moving the mount to NFSv4 resolves it and removes the dependency.

The mount option that hides the problem

$ grep nas01 /proc/mounts
nas01:/vol/backups /backups nfs rw,nolock,vers=3,... 0 0

The error is gone and the locking is gone with it. Two hosts mounting this export can each take what they believe is an exclusive lock on the same file at the same moment.

If this guards a backup against overlapping runs, that is a scheduling problem waiting to happen. If it guards anything that writes shared data, the protection someone designed is no longer there and nothing in the system will say so.

Contention is not this error

fcntl(4, F_SETLK, {l_type=F_WRLCK, ...}) = -1 EAGAIN (Resource temporarily unavailable)

Someone else holds the lock. That is locking working correctly, and it is -11 on Linux, not -37. A wrapper script that treats every lock failure identically will report this as the same incident and send you looking for a fault that does not exist.

Platform Note

Platform	errno 37	Realistic in a database context
Linux	ENOLCK	Yes — file locking, usually over NFS
Solaris	ECHRNG	No — STREAMS-era device error
AIX	ECHRNG	No
HP-UX	ECHRNG	No
BSD, Darwin	EALREADY	Not an error

ENOLCK exists on the System V platforms too, at a different number — 46 on Solaris and HP-UX, and outside the -1..-99 errno range's usefulness in any case. So a lock-resource failure on those platforms will not arrive as -37, and a -37 on them is not a locking problem.

The NFS machinery differs as well. Solaris uses lockd/statd under SMF, AIX under its own subsystem controller, and the commands to inspect them are not shared:

Task	Linux	Solaris	AIX
Lock service state	systemctl status rpc-statd	svcs nlockmgr	lssrc -s rpc.lockd
Registered RPC services	rpcinfo -p	rpcinfo -p	rpcinfo -p
Mount options	findmnt, /proc/mounts	mount -v, nfsstat -m	mount, nfsstat -m
Current locks	lslocks, /proc/locks	mdb, pfiles	lslk if installed

rpcinfo -p <server> is the one check that works everywhere and answers the question directly.

Related Errors / Related Topics

• -35 — on Linux, EDEADLK: the kernel refused a blocking lock request because granting it would deadlock. The other genuine lock failure, and a completely different situation from having no lock resources.
• -13 — EACCES. What fcntl(F_SETLK) returns when another process holds the lock. Normal contention, not a fault — the most important thing to keep separate from -37.
• -11 — EAGAIN. The other normal-contention return, and the one most scripts actually see.

Where -37 appears on Linux against a path on a shared filesystem, treat it as an infrastructure question rather than a database one. The useful outcome is usually a service that needs starting, a firewall rule that needs widening, or a file that should not have been on a shared mount in the first place.