If scripts, cron jobs, or a dashboard already write to Nagios's command file, jaque reads the exact same wire format, so there is nothing to rewrite on the sending side. The cost is strictness: a line that does not parse, or names a verb jaque does not recognize, is always an error. jaque never guesses at malformed input the way a more permissive reader might.

1. Enabling it

-command-file /var/lib/jaque/rw/jaque.cmd

jaque creates the named pipe if it does not already exist. Empty, the default, disables passive ingestion via this route entirely.

2. The line format

[<unix_ts>] COMMAND_NAME;field1;field2;...

<unix_ts> is a Unix timestamp in brackets; the command name and fields follow, semicolon-separated.

3. The verbs, exactly

3.1 Passive results

PROCESS_SERVICE_CHECK_RESULT;<host>;<service>;<code>;<output>
PROCESS_HOST_CHECK_RESULT;<host>;<code>;<output>

<output> splits on the first | into text and perfdata; <code> is the familiar 0-3 exit-code convention.

3.2 Acknowledgements

ACKNOWLEDGE_SVC_PROBLEM;<host>;<service>;<sticky>;<notify>;<persistent>;<author>;<comment>
ACKNOWLEDGE_HOST_PROBLEM;<host>;<sticky>;<notify>;<persistent>;<author>;<comment>
REMOVE_SVC_ACKNOWLEDGEMENT;<host>;<service>
REMOVE_HOST_ACKNOWLEDGEMENT;<host>

<sticky> is 0/1: any nonzero value (Nagios UIs sometimes write 2) is treated as sticky. <notify> set to 1 sends an ACKNOWLEDGEMENT notification to the object's current escalation level. <persistent> is parsed for arity and discarded: persistent comment retention has no equivalent here.

3.3 Downtimes

SCHEDULE_SVC_DOWNTIME;<host>;<service>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
SCHEDULE_HOST_DOWNTIME;<host>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
DEL_HOST_DOWNTIME;<downtime_id>
DEL_SVC_DOWNTIME;<downtime_id>

<start> must be before <end>; a window that is empty or runs backwards is a parse error. <fixed> must be 0 or 1, anything else is a parse error; <trigger_id> is 0 or a downtime ID. The combination of the two decides the kind:

• <fixed>=1, <trigger_id>=0: a fixed downtime. <duration> is parsed and discarded.
• <fixed>=0, <trigger_id>=0: a flexible downtime. <duration> is read as a positive number of seconds.
• <fixed>=1, a nonzero <trigger_id>: a triggered downtime, with <trigger_id> as the downtime it triggers on. <duration> is parsed for arity and discarded.
• <fixed>=0 with a nonzero <trigger_id> is a parse error: a downtime cannot be both flexible and triggered.

See Downtimes for what each kind actually does once scheduled. DEL_HOST_DOWNTIME and DEL_SVC_DOWNTIME carry only a downtime ID on the wire: both names parse to the same command, and the two names exist purely for wire compatibility.

3.4 Group-scoped downtimes

These translate a legacy group name into a label selector via the same normalization the importer used when it emitted the label:

SCHEDULE_HOSTGROUP_HOST_DOWNTIME;<hostgroup>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
SCHEDULE_HOSTGROUP_SVC_DOWNTIME;<hostgroup>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
SCHEDULE_SERVICEGROUP_HOST_DOWNTIME;<servicegroup>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
SCHEDULE_SERVICEGROUP_SVC_DOWNTIME;<servicegroup>;<start>;<end>;<fixed>;<trigger_id>;<duration>;<author>;<comment>

Nagios has no group-scoped acknowledgement command, so there is no equivalent translation for ACKNOWLEDGE_*.

3.5 Selector-scoped verbs

These verbs are new; Nagios never had them.

SCHEDULE_DOWNTIME;<selector>;<scope>;<start>;<end>;<author>;<comment>
ACKNOWLEDGE_PROBLEM;<selector>;<scope>;<sticky>;<notify>;<author>;<comment>
REMOVE_ACKNOWLEDGEMENT;<selector>;<scope>
SCHEDULE_CHECK;<selector>;<scope>

<selector> is any label selector text; <scope> is host or service, and anything else is a parse error. These carry only the fields the engine actually uses: no <persistent>/<fixed>/<trigger_id>/<duration> baggage. SCHEDULE_DOWNTIME by selector schedules a fixed downtime only; a flexible or triggered downtime by selector is not available here.

3.6 Custom notifications

SEND_CUSTOM_HOST_NOTIFICATION;<host>;<options>;<author>;<comment>
SEND_CUSTOM_SVC_NOTIFICATION;<host>;<service>;<options>;<author>;<comment>

<options> is parsed for arity and discarded: broadcast, forced and increment have no equivalent here. The notification goes to the object's current escalation level with the author and the comment; a downtime silences it.

3.7 Switching notifications on and off

ENABLE_NOTIFICATIONS
DISABLE_NOTIFICATIONS
ENABLE_HOST_NOTIFICATIONS;<host>
DISABLE_HOST_NOTIFICATIONS;<host>
ENABLE_SVC_NOTIFICATIONS;<host>;<service>
DISABLE_SVC_NOTIFICATIONS;<host>;<service>
ENABLE_OBJECT_NOTIFICATIONS;<selector>;<scope>
DISABLE_OBJECT_NOTIFICATIONS;<selector>;<scope>
ENABLE_CONTACT_HOST_NOTIFICATIONS;<contact>
DISABLE_CONTACT_HOST_NOTIFICATIONS;<contact>
ENABLE_CONTACT_SVC_NOTIFICATIONS;<contact>
DISABLE_CONTACT_SVC_NOTIFICATIONS;<contact>

ENABLE_NOTIFICATIONS and DISABLE_NOTIFICATIONS take no fields and switch every notification off or on for the whole program; ENABLE_HOST_NOTIFICATIONS/DISABLE_HOST_NOTIFICATIONS, ENABLE_SVC_NOTIFICATIONS/DISABLE_SVC_NOTIFICATIONS and ENABLE_OBJECT_NOTIFICATIONS/DISABLE_OBJECT_NOTIFICATIONS (the last pair taking a <selector> and a <scope> of host or service, parsed the same way as the selector-scoped verbs above) switch one object off or on. ENABLE_CONTACT_HOST_NOTIFICATIONS/DISABLE_CONTACT_HOST_NOTIFICATIONS and ENABLE_CONTACT_SVC_NOTIFICATIONS/DISABLE_CONTACT_SVC_NOTIFICATIONS switch one contact off or on for the object kind named in the verb.

3.8 Stopping checks, flap detection and event handlers

START_EXECUTING_HOST_CHECKS
STOP_EXECUTING_HOST_CHECKS
START_EXECUTING_SVC_CHECKS
STOP_EXECUTING_SVC_CHECKS
ENABLE_FLAP_DETECTION
DISABLE_FLAP_DETECTION
ENABLE_EVENT_HANDLERS
DISABLE_EVENT_HANDLERS
ENABLE_HOST_CHECK;<host>
DISABLE_HOST_CHECK;<host>
ENABLE_SVC_CHECK;<host>;<service>
DISABLE_SVC_CHECK;<host>;<service>
ENABLE_HOST_FLAP_DETECTION;<host>
DISABLE_HOST_FLAP_DETECTION;<host>
ENABLE_SVC_FLAP_DETECTION;<host>;<service>
DISABLE_SVC_FLAP_DETECTION;<host>;<service>
ENABLE_HOST_EVENT_HANDLER;<host>
DISABLE_HOST_EVENT_HANDLER;<host>
ENABLE_SVC_EVENT_HANDLER;<host>;<service>
DISABLE_SVC_EVENT_HANDLER;<host>;<service>
ENABLE_OBJECT_ACTIVE_CHECKS;<selector>;<scope>
DISABLE_OBJECT_ACTIVE_CHECKS;<selector>;<scope>
ENABLE_OBJECT_FLAP_DETECTION;<selector>;<scope>
DISABLE_OBJECT_FLAP_DETECTION;<selector>;<scope>
ENABLE_OBJECT_EVENT_HANDLER;<selector>;<scope>
DISABLE_OBJECT_EVENT_HANDLER;<selector>;<scope>

The first eight switch active checks per kind, flap detection and event handlers for the whole program; the rest switch the same three for one object, by name or by a <selector> and <scope> of host or service, parsed the same way as the selector-scoped verbs above. A forced check (SCHEDULE_FORCED_HOST_CHECK, SCHEDULE_FORCED_SVC_CHECK) still obeys a stopped active-checks switch here, where Nagios runs it regardless.

3.9 Rescheduling a check

SCHEDULE_FORCED_HOST_CHECK;<host>;<check_time>
SCHEDULE_FORCED_SVC_CHECK;<host>;<service>;<check_time>
SCHEDULE_HOST_CHECK;<host>;<check_time>
SCHEDULE_SVC_CHECK;<host>;<service>;<check_time>
SCHEDULE_CHECK;<selector>;<scope>

The check runs at <check_time>, or now when that is 0 or past. The forced and non-forced spellings are the same command here, because there is no check period to bypass yet. The next regular check keeps its slot, so asking for a check now does not shift the object's cadence.

3.10 Comments

ADD_HOST_COMMENT;<host>;<persistent>;<author>;<comment>
ADD_SVC_COMMENT;<host>;<service>;<persistent>;<author>;<comment>
DEL_HOST_COMMENT;<comment_id>
DEL_SVC_COMMENT;<comment_id>

<persistent> is parsed for arity and discarded, because every comment is kept on the log and survives a restart. <comment_id> is the ID the API returned when the comment was added, and the one the query API and the dashboard show. DEL_HOST_COMMENT and DEL_SVC_COMMENT are one command, as with downtimes.

4. Where these commands go

Everything the FIFO parses lands on the same command channel the ConnectRPC API feeds. See FIFO and API for how the two doors converge, and what happens to a command aimed at an object owned by another engine.

5. Security considerations

The named pipe is filesystem-local IPC: anything able to write to -command-file can inject commands, so its permissions are the operator's to set, the same as they were under Nagios. Parsing does not soften that: strict rejection of malformed input closes off one failure mode. It does not change the trust boundary of the pipe itself.