Oninit
Talk to an expert →

Oninit® Logwalker — Overview

Logwalker is a standalone diagnostic / forensic tool for inspecting IBM Informix logical-log files. It walks a log forward from a given uniqid and prints each record in a human-readable form — one line per record header, indented per-type body decoders for the common ops (BEGIN, COMMIT, HINSERT, HUPAFT, HUPBEF, HDELETE, ADDITEM, UNIQID, CHALLOC, CHFREE, PTRUNCATE, TRUNCATE, BEGCOM, …), and an optional schema-aware row formatter that renders row-image bytes as (col1=val1, col2=val2, …).

This is read-only inspection. Logwalker is not a CDC capture mode; it does not emit a replay stream, does not subscribe via the CDC API, and does not modify any $INFORMIXDIR state. Every open() uses O_RDONLY and every read uses pread(). Use the Oninit Log Ripper for live CDC capture + target replay; logwalker is what you reach for when you want to understand what's actually in a particular log file.

The walker reuses the byte-level raw-log reader shipped with the Log Ripper (oni_log_resolve_uniqid, oni_log_cursor_read, the ONI_LOG_* macros) by linking against liboni_logripper.so. The byte-level log machinery stays canonical in the Ripper project; logwalker is the operator-facing diagnostic tool that consumes those primitives.

When to use it

  • Customer support / PMR: when a customer ships you a log file along with a defect report, walk it and search by record type, transaction id, or partnum to localise the failing record.
  • Reverse engineering: when extending the Ripper's coverage to a new column type or a new record class, logwalker is the cheap way to look at what the engine actually emits without standing up a full CDC subscription.
  • Audit / forensics: confirm which transactions modified a given partition over a window, with operator + pid + timestamp from BEGIN records. The -t / --table object-track mode does exactly this — name a table (or its partnum) and a --from-log / --to-log range, and logwalker reports every change to that one object across the whole span of logs.
  • Replacing onlog -l: the legacy onlog dump is terse and undocumented; logwalker prints named fields and supports --filter for grepping a single record class out of a busy log.

Hard deployment constraint

Logwalker must run locally on the source Informix server, as user informix (or in the informix group), with read access to the log dbspace files. Raw log dbspaces live with 0660 informix:informix permissions and there is no remote / network protocol that exposes them. The binary refuses to start with a [CRITICAL] line if access(R_OK) fails on any chunk in the resolved extent map. A sysmaster ESQL/C connection is also required for the LSN → chunk-path resolve.

Output

Logwalker emits three output shapes:

  • Default (HUMAN) — one line per record, prefixed with the canonical Informix LSN U:0x<low> form and the transaction id, then a plain-English description of what the record means.
  • --compat onlog — drop-in legacy onlog -l 6-column form for scripts that already parse it.
  • --group-by-xid — same per-record content as HUMAN, wrapped with explicit BEGIN / COMMIT framing markers per transaction; handles the not-unique-xid recycling explicitly.

Cutting across all three shapes is the object-track mode (-t / --table): rather than walking one log in full, it follows a single table or partition across a range of logs — scoped to a date window by mapping the dates to a --from-log / --to-log id range — and composes with HUMAN, --compat onlog, and --decode-rows alike.

See the Output Examples page for a side-by-side comparison plus links to live samples of each mode.