Skip to main content

How-to guide

Run Signals as a service

The Signals daemon schedules collection itself on poll_interval, so run it as a long-lived service rather than a cron job that launches a one-shot. This guide gives the systemd recipe, the on-demand-collection recipe, and the one case where cron still belongs.

Run the daemon under systemd

Because the daemon schedules collection itself, the right model is to run it as a long-lived service— not a cron job that launches a one-shot. Signals does not ship a systemd unit; create one like this:

# /etc/systemd/system/signals.service
[Unit]
Description=Elevarq Signals collector
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/signals --config /etc/signals/signals.yaml
User=signals
Group=signals
Restart=on-failure
RestartSec=5
# Hardening: Signals is read-only against Postgres and writes only its data dir.
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/var/lib/signals

[Install]
WantedBy=multi-user.target
sudo systemctl enable --now signals

Point database.pathat a directory the unit user can write — it must be writable by the user the service runs as (for example /var/lib/signals/signals.db, covered by the ReadWritePaths above).

Trigger an on-demand collection

For an ad-hoc collection — say, right before a maintenance window — trigger one instead of waiting for the next cycle:

signalsctl collect now
# or, against the control API directly:
curl -X POST http://127.0.0.1:8081/collect/now \
  -H "Authorization: Bearer $SIGNALS_API_TOKEN"

The min_snapshot_intervalguard (default 60s) rate-limits collection so a burst of triggers can't flood the snapshot store; pass --force to override it when you genuinely need a snapshot sooner.

When cron still belongs

If your environment really does require an external scheduler, cron a signalsctl collect nowcall — but for steady-state monitoring the built-in poll_interval is the intended mechanism. Cron is only for an external trigger, never the primary cadence.

For the reasoning behind self-scheduling, see why poll_interval, not cron. For the full set of signalsctl subcommands and flags, see the signalsctl CLI reference.