Oninit
Talk to an expert →

Informix Error -50

-50 Network is down.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. If you are attempting to use Informix STAR or IBM Informix NET, contact your system administrator to find out when the network will be backed up. If not, 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.

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
Value Symbol
Catalogue text — Network is down 50 ENETDOWN on BSD
The same condition on Linux 100 ENETDOWN
Errno 50 on Linux 50 ENOCSI — No CSI structure available, STREAMS-era

Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux.

python3 -c 'import os; print(50, os.strerror(50)); print(100, os.strerror(100))'
What ENETDOWN Actually Tells You

The local interface that would carry this traffic is not operational. The stack refused the operation because the path out of the host does not exist right now.

The neighbouring distinction:

  • -50 ENETDOWN — the interface is down.
  • -51 ENETUNREACH — the interface is fine; there is no route to the destination.

An interface going down usually removes its routes, so a -50 and a -51 often appear together. Check the interface first, because the route is the consequence.

Unlike most errors in this range, this one has a clear physical or administrative cause: a cable, a switch port, a bond with no surviving member, a ip link set down, or a driver reset.

What This Means in Informix

The engine's own log shows this on outbound work — replication partners, Connection Manager, a storage manager, a distributed query, an alert script. Inbound clients fail on their side, and the message log records nothing about connections that never arrived.

What produces it:

  • A bond or team with no active member. The most common cause on a properly built database host, because a single-interface failure is supposed to be survivable and this error means it was not.
  • A switch port disabled or a cable removed during maintenance.
  • A NIC driver reset or firmware fault, which can take an interface down briefly and return it without anyone noticing except the applications.
  • An administrative change — an interface taken down for reconfiguration, or a network restart that took longer than expected.
  • A VLAN or sub-interface removed while the parent stays up, so the host looks healthy at a glance.
  • A container's veth pair being torn down.

The instance is usually an innocent bystander. The value in the page is confirming that quickly and handing a clear report to whoever owns the network.

Common Causes
  1. A bond or team with every member down.
  2. A switch port disabled, or a cable unplugged.
  3. A NIC driver reset or hardware fault.
  4. An interface administratively taken down.
  5. A VLAN or sub-interface removed.
  6. A container network rebuilt beneath a running process.
  7. A failed network configuration change that left an interface unconfigured.
Diagnostic Checks

Check interface state, including carrier, which distinguishes an administrative change from a physical one:

ip -br link
ip -br addr
ip link show <iface>
cat /sys/class/net/<iface>/operstate
cat /sys/class/net/<iface>/carrier

operstate of down with carrier of 0 is a physical or switch-side problem. operstate down with carrier present means something took it down locally.

For a bond or team, look at the members rather than the aggregate:

cat /proc/net/bonding/bond0 2>/dev/null
ip -d link show bond0
teamdctl team0 state 2>/dev/null

A bond reporting down means every member is down — which is a different conversation from one member failing, and worth stating plainly when escalating.

Find when it happened, and whether it has flapped:

dmesg -T | grep -iE 'link is (down|up)|carrier|NIC Link'
journalctl -k --since '1 day ago' | grep -iE 'link|carrier|bond|team'
ip -s link show <iface>

Repeated up/down transitions point at a cable, an optic or a driver rather than at a single event, and that changes who needs to look at it.

Check the switch side where you can, since the host's view is only half of it:

lldpctl 2>/dev/null
lldpcli show neighbors 2>/dev/null
ethtool <iface>
ethtool -S <iface> | grep -iE 'err|drop|carrier'

lldp naming the switch and port turns "a network problem" into a specific port on a specific device.

Confirm the Informix impact:

onstat -
onstat -g dri
onstat -g ntt
tail -300 "$INFORMIXDIR/tmp/online.log"
Solutions / Resolution
  1. Confirm the interface state and hand it over. This is a network or hardware fault in almost every case, and the useful output from the database side is a precise report: interface name, operstate, carrier, the dmesg timestamps, and the LLDP neighbour if available.
  2. Check whether it is a bond with no surviving member, and say so explicitly. "The bond is down" and "one member failed" get very different responses, and only the first explains why the database noticed.
  3. Do not restart the instance. Nothing about the engine is wrong, and a restart during a network outage adds a recovery to an incident that did not need one.
  4. Check whether it flapped rather than failed. A brief transition that has already recovered explains a burst of errors in the log and needs no action beyond recording it — but a flapping link will do it again.
  5. For replication, verify the partner state after the link returns. Connections do not always re-establish silently, and an HDR or ER pair that has been separated needs checking rather than assuming.
  6. Look at the VLAN as well as the parent where sub-interfaces are in use. A parent interface that is up tells you nothing about the sub-interface the database traffic actually uses.
  7. Record the correlation. If the outage coincided with scheduled network maintenance, that is worth establishing before any further investigation — it is the most common explanation and the cheapest to confirm.
Examples
A bond with nothing left
$ ip -br link | grep bond0
bond0   DOWN   0a:11:...

$ cat /proc/net/bonding/bond0 | grep -E 'MII Status|Slave Interface'
MII Status: down
Slave Interface: eno1
MII Status: down
Slave Interface: eno2
MII Status: down

Both members down, so the bond is down and the redundancy did not help. That points at something common to both — a switch stack, a shared uplink, or maintenance affecting both ports — rather than at two coincidental failures.

A link that flapped and recovered
$ dmesg -T | grep -i 'link is' | tail -4
[Sat Sep 12 02:14:07 2026] eno1: NIC Link is Down
[Sat Sep 12 02:14:09 2026] eno1: NIC Link is Down
[Sat Sep 12 02:14:22 2026] eno1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[Sat Sep 12 02:19:41 2026] eno1: NIC Link is Down

Down, up, down again within minutes. The burst of errors in the message log is explained, and nothing is currently broken — but a flapping link is a fault in its own right and will recur. The optic, the cable and the switch port are the candidates.

Platform Note
Platform This condition Errno 50 there means
Linux errno 100 ENOCSI — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 50 this condition
Task Linux Solaris AIX
Interface state ip -br link, /sys/class/net dladm show-phys, ipadm netstat -in, entstat
Aggregation state /proc/net/bonding/* dladm show-aggr -x entstat -d ent<N> (EtherChannel)
Link events dmesg, journalctl -k dmesg, fmadm faulty errpt -a

On AIX, errpt -a records link transitions with timestamps and is the first place to look; on Solaris, dladm show-aggr -x gives per-member state equivalent to reading /proc/net/bonding.

Related Errors / Related Topics
  • -51 — Network is unreachable. No route to the destination. An interface going down removes its routes, so the two appear together and the interface is the one to check first.
  • -49 — Can't assign requested address, which is what a bind attempt produces when an interface has lost the address it was to bind.
  • -52 — Network dropped connection on reset, for connections that existed and did not survive.

Where -50 appears, the database investigation is short: confirm the interface, collect the evidence, and give it to whoever owns the link. The time worth spending is on whether it flapped, because that decides whether the incident is over.