FIFO and API

External commands — passive results, acknowledgements, downtimes — reach jaque through two doors, the FIFO and the ConnectRPC API, that both feed the same command channel.

The FIFO

jaque implements Nagios’s external command file, unchanged on the wire: enable it with -command-file <path> and write lines like

[<unix_ts>] PROCESS_SERVICE_CHECK_RESULT;<host>;<service>;<code>;<output>

See FIFO external commands for every verb the FIFO accepts, the full wire format, and field-by-field detail, including what a downtime line must and must not carry (only fixed=1, trigger_id=0 — flexible and triggered downtimes are rejected, not silently downgraded).

The API

The same commands are also available over ConnectRPC, speaking JSON (curl-friendly), gRPC, and gRPC-Web on the same port as the dashboard. CommandService exposes six RPCs: ProcessCheckResult, ProcessCheckResults (batch), AcknowledgeProblem, RemoveAcknowledgement, ScheduleDowntime, DeleteDowntime. Optional bearer auth via -api-token protects writes only — reads (QueryService) are always open. See Command and query service for the full RPC surface.

Batch is all-or-nothing

ProcessCheckResults validates every item in the batch before enqueueing any of them: one malformed result fails the whole call, nothing partial gets queued. Once validation passes, results enqueue in order and the first delivery failure stops the rest — a translator receiving bursts (an SNMP trap pipeline, say) gets one clear failure point instead of a partially-applied batch.

A passive result posted through the API lands on the exact same command channel as one from the FIFO, tagged origin: passive. An OK response means enqueued, never applied — the engine still resolves it at its own pace, and a result for an object that isn’t declared passive is discarded with a warning, not silently accepted.

One channel, either door

Both the FIFO reader and the API handler feed the same internal command channel, merged before the engine ever sees a command. A result addressed to an object owned by a different engine (in a multi-engine deployment) is forwarded once to its actual owner — see Cluster and coordination — so a client can send to any engine, or even a -target ui process, without knowing who owns what.