My watchdog killed the gateway twelve seconds after start

Description and use

An hourly watchdog helper killed a messaging gateway during its cold start because its verification window was too short. Adding a receipt file, retiring the helper, and removing the obsolete launchd job stopped the repeated SIGUSR1 kills.

Problem

A scheduled helper that restarts a messaging gateway was killing the gateway during its cold start because its verification window was shorter than the gateway’s startup time.

Outcome

The gateway ran successfully after the helper was idempotent and the redundant launchd job was removed, eliminating the SIGUSR1 kills.

Workflow

• 1. Helper ran hourly via launchd with keepalive.
• 2. Helper invoked gateway restart and waited 180 s.
• 3. Helper verified gateway; on failure exited 1.
• 4. launchd relaunched helper, repeating the cycle.
• 5. SIGUSR1 from helper killed gateway during cold start.
• 6. Helper was changed to check a receipt file before restarting.
• 7. Helper marked itself retired and exited 0.
• 8. Obsolete launchd job was removed.

Evidence

An hourly helper around notification cadence kept restarting the shared messaging gateway behind my two chat bridges while everything inside the gateway was healthy.

Source

Mine did exactly that on my Mac. An hourly helper around notification cadence kept restarting the shared messaging gateway behind my two chat bridges while everything inside the gateway was healthy.

Source

First, the helper checks a receipt file before doing anything else. A prior done or retired receipt carrying notify_seconds=3600 returns success immediately, no config write, no restart subprocess, nothing for launchd to escape against.

Source