Skip to main content

How-to guide

Operate a running Signals

Change a setting and reload with no restart, pause and resume collection, and stop and start the daemon — the day-2 tasks for a Signals install that is already collecting.

Day-2 tasks for a Signals daemon that is already installed and collecting: change a setting, pause and resume collection, and stop and start the service. For the settings themselves see Signals configuration.

The examples use the control API on http://localhost:8081 with a bearer token; substitute your own API token (the value of SIGNALS_API_TOKEN / SIGNALS_API_TOKEN_FILE, or the strong token Signals generated at startup).

Change a setting

There are two kinds of setting, and they take effect differently.

Config-file settings — reload, no restart

Settings in signals.yaml (targets, retention_days, poll_interval, target_timeout, query_timeout, per-target fields, …) are hot-reloadable. Edit the file, then tell the running daemon to re-read it:

curl -X POST http://localhost:8081/reload \
  -H "Authorization: Bearer <token>"

The daemon re-reads its config with no downtime and no lost collection history. Sending SIGHUP does the same:

kill -HUP "$(pgrep -x signals)"

Confirm the change with the status endpoint (for example, a newly added target appears immediately):

curl -s http://localhost:8081/status -H "Authorization: Bearer <token>"

Startup settings — change the environment, then restart

Settings supplied as environment variables (SIGNALS_*, such as SIGNALS_LISTEN_ADDR, SIGNALS_POLL_INTERVAL, SIGNALS_API_TOKEN, SIGNALS_METRICS_ENABLED) override the file and are read at startup. Change the environment and restart the service (see below); a reload does not pick these up.

Pause and resume collection

Stop running collection cycles without taking the daemon down — the API stays reachable and no data is lost:

curl -X POST http://localhost:8081/collect/pause  -H "Authorization: Bearer <token>"
curl -X POST http://localhost:8081/collect/resume -H "Authorization: Bearer <token>"

Equivalently with the CLI:

signalsctl pause
signalsctl resume

Use this for a maintenance window on a monitored database, or to hold collection while you reconfigure.

Stop and start the service

Stopping the daemon preserves the local snapshot store; collection resumes from where it left off on the next start.

Container:

docker stop signals
docker start signals
# or, in a Compose project:
docker compose stop signals
docker compose start signals

systemd (see Install and run Signals for the unit):

sudo systemctl stop signals
sudo systemctl start signals
sudo systemctl restart signals    # apply an environment change

To enable config reload through systemd, add ExecReload=/bin/kill -HUP $MAINPID to the unit, then sudo systemctl reload signals.

Quick reference

GoalCommand
Reload config file (no restart)POST /reload (or SIGHUP)
Pause / resume collectingPOST /collect/pause · /collect/resume (signalsctl pause/resume)
Stop / start the daemondocker stop/start · systemctl stop/start
Apply an environment changerestart the service
Check current stateGET /status (signalsctl status)

Next: Monitor Signals with Prometheus and Grafana.