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
- Increase the monitor timeout so sipsak has time to receive a SIP response.
- Verify the SIP server answers OPTIONS requests (sngrep / tcpdump on port 5060).
- Confirm UDP vs TCP transport matches what the SIP server expects.
- 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
- Set the monitor timeout generously for SIP/UDP retransmits.
- Verify the SIP server responds to OPTIONS with sngrep/tcpdump.
- Distinguish 'no output' (timeout) from 'error in output' (server-rejected).
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
- Error in output: ${stderr.toString()}
- Connection to Docker daemon timed out.
- Per-ping timeout must be between ${PING_PER_REQUEST_TIMEOUT_
- Timeout must be between ${PING_GLOBAL_TIMEOUT_MIN} and ${PIN
- Screenshot delay must be less than ${maxDelayFromTimeout}ms
AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12).
Data as JSON: /api/errors/d48b11018fd20da2.
Report an issue: GitHub.