louislam/uptime-kuma · error · Error

No output from sipsak

Error message

No output from sipsak

What it means

If execFile resolved with neither stdout nor stderr content, sipsak produced nothing usable — no answer and no diagnostic. The monitor cannot determine success and throws 'No output from sipsak'. This is distinct from error 116 (which had stderr); here the binary was silent.

Source

Thrown at server/monitor-types/sip-options.js:43

     * @param {number} port SIP server port
     * @param {number} timeout timeout of options reply
     * @returns {Promise<string>} A Promise that resolves to the output of the Sipsak options ping
     * @throws Will throw an error if the command execution encounters any error.
     */
    async runSipSak(hostname, port, timeout) {
        const { stdout, stderr } = await execFile(
            "sipsak",
            ["-s", `sip:${hostname}:${port}`, "--from", `sip:sipsak@${hostname}`, "-v"],
            { timeout }
        );

        if (!stdout && stderr && stderr.toString()) {
            throw new Error(`Error in output: ${stderr.toString()}`);
        }
        if (stdout && stdout.toString()) {
            return stdout.toString();
        } else {
            throw new Error("No output from sipsak");
        }
    }

    /**
     * @param {string} res response to be parsed
     * @param {object} heartbeat heartbeat object to update
     * @returns {void} returns nothing
     */
    parseSipsakResponse(res, heartbeat) {
        let lines = res.split("\n");
        for (let line of lines) {
            if (line.includes("200 OK")) {
                heartbeat.status = UP;
                heartbeat.msg = line;
                break;
            }
        }
    }

View on GitHub (pinned to 6b5ea01557)

Solutions

  1. Increase the monitor timeout so sipsak has time to receive a SIP response.
  2. Verify the SIP server answers OPTIONS requests (sngrep / tcpdump on port 5060).
  3. Confirm UDP vs TCP transport matches what the SIP server expects.
  4. Run sipsak manually to see whether any output ever appears.

Example fix

// before
monitor.timeout = 2;  // sipsak killed before SIP reply
// after
monitor.timeout = 10;
Defensive patterns

Strategy: retry

Validate before calling

function preflightSipTimeout(timeout, interval) {
  if (timeout >= interval) return;
  // sipsak needs headroom for UDP retransmits; warn if too tight
  if (timeout < 5) console.warn('SIP timeout very low; sipsak may produce no output');
}

Type guard

function isSilentSipsak(out) { return !!out && !out.stdout && !out.stderr; }

Try / catch

try {
  await runSipSak(hostname, port, timeout);
} catch (e) {
  if (e.message === 'No output from sipsak') {
    // retry once with a longer timeout; if still silent, the SIP server is not answering
  }
  throw e;
}

Prevention

When it happens

Trigger: sipsak exited cleanly (so execFile did not throw) but emitted nothing on either stream: typically a timeout-truncated run where the { timeout } option killed the child mid-flight before output, or a version of sipsak that swallows output.

Common situations: SIP server not answering OPTIONS (silent drop), timeout too short, packet loss on UDP SIP, or sipsak built with output suppressed.

Related errors


AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12). Data as JSON: /api/errors/d48b11018fd20da2. Report an issue: GitHub.