Operations

Oninit® MySQL-2-Informix — Operations

The control script

The m2i shell script wraps process lifecycle for the proxy binaries. It handles PID-file management, picks the right binary based on the M2I_BINARY environment variable, and provides the standard start / stop / restart / status verbs.

./m2i {start|stop|restart|status} [config]

Verb	Action
start	Reads the configured backend binary, daemonises it, writes a PID file. Refuses to start if a PID file already exists for the same binary on the same port.
stop	Sends SIGTERM to the PID in the PID file and waits for the process to exit. Removes the PID file.
restart	Stop followed by start — useful after a config edit.
status	Reports whether the configured backend is running. Returns a non-zero exit status if not running, suitable for monitoring scripts.

Choosing the backend

The script defaults to ./m2ie. Switch to the SQLI backend by exporting M2I_BINARY:

# ESQL backend (default)
./m2i start

# SQLI backend
M2I_BINARY=./m2is ./m2i start

# Status / stop / restart pick up the same binary
M2I_BINARY=./m2is ./m2i status
M2I_BINARY=./m2is ./m2i stop

The two binaries can run side by side on different ports. The PID file path is derived from the binary name, so they don't collide.

Listening address

The default bind is 127.0.0.1:3307. Override with M2I_PORT:

M2I_PORT=3308 M2I_BINARY=./m2is ./m2i start

Bind to a non-loopback interface only when downstream MySQL clients need to reach the proxy across the network. Inbound traffic is the MySQL 4.1 wire protocol — secure the path appropriately.

Connecting from a MySQL client

Any MySQL client that speaks the 4.1 protocol works. The standard mysql(1) command is the simplest verification:

mysql -h 127.0.0.1 -P 3307 -u informix --database=mydb
mysql> SHOW DATABASES;
mysql> SHOW TABLES;
mysql> SHOW CREATE TABLE customer;
mysql> SELECT * FROM customer LIMIT 5;

The same connection works for JDBC, ODBC, the Connector/Python driver, an ORM, or a long-running application: point at 127.0.0.1:3307, present any user (the proxy authenticates to Informix using the credentials in cfg/ifx.conf; the user the client presents is reported by SELECT USER() for audit / logging continuity).

Logging and observability

Standard error carries any handshake / dispatch failures.
A debug build of the proxy logs every SQL statement sent to Informix on standard error — useful when tracing a specific MySQL-side query through the translator.
For wire-level visibility against the SQLI backend, the Oninit® Snooper can sit between m2is and the IDS server and decode every PFPDU in real time.

Lifecycle and signals

Signal	Effect
SIGTERM	Stops accepting new client connections; in-flight pthreads finish their current request and exit. The PID file is removed.
SIGINT	Same as SIGTERM — useful when running in the foreground for development.
SIGHUP	Reserved; not currently a runtime config-reload trigger. Restart the proxy to pick up config changes.

Capacity

The proxy runs one pthread per accepted client connection, plus the acceptor thread. Each connection holds its own Informix backend session (an ESQL/C connection for m2ie, a SQLI socket for m2is). Sizing follows the same rule as any per-connection backend: budget memory and Informix-side connection slots for the peak concurrent client count, not the average.