Oninit mysql-2-informix / MySQL wire proxy
Talk to an expert →

Troubleshooting

Oninit® MySQL-2-Informix — Troubleshooting

m2i start reports the proxy is already running

The control script keys the PID file off the binary name. If the previous run exited uncleanly, a stale PID file may still be on disk. Verify the process really is gone, then remove the stale PID file and retry: 

./m2i status         # confirm the script's view
ps -ef | grep m2i    # confirm the OS view
# If no process matches, remove the stale PID file:
rm /var/run/m2i*.pid     # or wherever the script stored it
./m2i start

The MySQL client cannot connect

Walk the path from outside in:

  1. ./m2i status — confirm the proxy itself is running.
  2. ss -ltnp | grep 3307 — confirm the listen port is open and the proxy is the bound process.
  3. nc -vz 127.0.0.1 3307 from the same host — confirm the TCP path is healthy.
  4. mysql -h 127.0.0.1 -P 3307 -u informix --database=mydb -e "SELECT 1" — the cheapest end-to-end probe; if this works, the wire path is fine and any later failure is application-side.

The proxy starts but every query fails on the Informix side

The proxy authenticates to Informix using the credentials in cfg/ifx.conf at start-up. If those credentials are wrong, the backend session never establishes. Check standard error for the connect failure, then verify by hand from the proxy host using the same address / port / user / password / database: 

# For the ESQL backend, dbaccess is the easiest probe:
dbaccess - -                          <<'EOF'
DATABASE mydb@your_server;
SELECT 1 FROM systables WHERE tabid=1;
EOF

For the SQLI backend, sit the Oninit® Snooper between m2is and the IDS server to watch the wire conversation directly — useful when the failure is on the authentication or session-negotiation path.

A specific query is returning the wrong shape

The translator is the most likely culprit. Build the SQL-tracing debug binary and rerun the query — standard error then carries every SQL statement the proxy is sending to Informix. From there, match the proxy's outbound SQL against what the MySQL client sent; if they differ in a way that matters, the classification or translation surface needs adjustment.

Backends disagree for the same SQL

The two backends produce the same MySQL-wire output for the same SQL on most rows. A small documented set of behaviours where the SQLI-protocol backend is strictly more correct than the ESQL/CSDK reference is captured on the Backends page; if a divergence falls outside that set, capture the case and report it.

To capture both backends' output for comparison, run the integration suite once per backend and diff the captures: 

# Capture both outputs:
./m2i start
M2I_PORT=3307 ./test_integ.sh >/tmp/m2ie.out 2>&1
./m2i stop

M2I_BINARY=./m2is M2I_PORT=3308 ./m2i start
M2I_PORT=3308 ./test_integ.sh >/tmp/m2is.out 2>&1
M2I_BINARY=./m2is ./m2i stop

diff -u /tmp/m2ie.out /tmp/m2is.out

The diff isolates the offending test case. From there, narrow with the SQL-tracing debug build to find the specific statement, and use the Oninit® Snooper in front of the SQLI backend to see exactly what bytes went out and came back.

License-key validation failure at start-up

The proxy refuses to start when the license key in cfg/ifx.conf is missing, malformed, mis-signed, or expired. The standard error message names which check failed. Re-issue the key with the Oninit-supplied keygen tool if the customer name or expiry needs to change.

USE database works once but the next query reverts

USE reconnects the backend session to the named database, but the reconnect is per-connection — not per-statement and not pooled. If your client is round-robining over a connection pool, each pooled connection lands wherever it last left off. Either set --database on the connect string so every new connection starts in the right place, or pin the application to a single connection for the duration of work that requires a specific database context.

The proxy adds noticeable latency

The translation path is in-process and small — per-request overhead is dominated by the round trip to Informix, not by the proxy itself. If end-to-end latency is higher than expected:

  • Confirm the proxy is co-located with one of the application or the database; one extra TCP hop is one extra round-trip-time.
  • Run the SQLI backend with the Oninit® Snooper in front to ground per-PFPDU timing — the snooper's per-PFPDU round-trip and gap-since-previous-PFPDU columns surface server-think-time stalls.
  • Profile the integration suite first; it's the closest thing to a baseline workload and runs reproducibly.