Reload & restart

After you edit runwisp.toml, tell the running daemon to pick it up:

runwisp reload

Configuration reloaded.
  + added   nightly-backup
  ~ changed report (schedule)
  - removed old-cleanup
  ~ setting notifications

The daemon never watches the file. It reloads only when you ask, and every way of asking runs the same reload:

runwisp reload from the CLI.
SIGHUP to the daemon: kill -HUP "$(cat .runwisp/daemon.pid)" (the PID file is in the data directory).
R in the TUI.
The Reload button on the Web UI banner that appears when the file changed since the daemon loaded it.

runwisp status and the TUI header show the same “config changed” notice.

A daemon started with runwisp station reloads the same way. The Station schedules the tasks there, so no local cron entries change; after the reload the daemon sends the new task list to the Station.

A bad config changes nothing

The daemon loads and validates the whole new config before it touches anything. If the file doesn’t parse, fails validation, or changes a setting that needs a restart, the reload is rejected and the running tasks stay exactly as they were.

$ runwisp reload
Error: reload rejected: [daemon] tls changed; requires `runwisp restart`

Fix the file and reload again. To check a file without involving the daemon, run runwisp validate.

What a reload applies

Adding, removing, and changing tasks and services: commands, schedules, environment, instances, overlap, and retry settings.
[defaults]: shows up as a change on every task that inherits the changed key.
include and include_cron, and the files they pull in.
[notify], [notifiers.*], and [[route]], and the files template_path points to. Notifications sent after the reload use the new settings. Deliveries already being retried finish under the old ones.
[storage].
timezone. Every cron schedule and health check that doesn’t set its own timezone moves to the new zone from now on. Ticks the move skips over are not caught up. With timezone unset, the daemon keeps the host zone it started with; a host zone change needs a restart.
Every other [daemon] key, except the ones below.

runwisp reload lists the changed settings on ~ setting lines.

What needs a restart

A reload that changes any of these is rejected:

The bind address and port are command-line flags, and RUNWISP_* environment variables are read at startup. Both change only on a restart.

runwisp restart

Running tasks get shutdown_timeout to finish before the daemon stops. See runwisp restart.

Reload is not a restart

Added tasks start from now. A task added by a reload doesn’t run its run_on_start command and doesn’t catch up on earlier ticks.
Running runs finish under the old definition. Changing or removing a task never kills a run that’s already going. The next run uses the new definition.
Removed services are stopped.
A stopped service stays stopped, even if the new definition says autostart = true. The reload prints a ! warning about it. Start it with runwisp start <service>.
A known cron task keeps firing, even if the new definition says autostart = false. The reload prints a ! warning about it. Pause it with runwisp pause <task>.

If you want run_on_start and catch-up to happen, use runwisp restart. A run_on_start = "boot" task that already ran this boot stays skipped.

Warnings after a reload

After the diff, runwisp reload prints warnings for the new config on ! lines. The most common is a crontab job that include_cron couldn’t schedule, with its file and line. That job isn’t a task, so it never shows in the diff: a reload after a bad crontab -e can say “no task changes” and still warn. The same warnings show in runwisp status, the Web UI and TUI header, and runwisp validate.

A reload also checks again whether the system cron daemon is still running. Jobs RunWisp was holding back for cron become RunWisp’s right away. The daemon does this check on its own about once a minute too, so the reload only makes it immediate.

Moving a task into runwisp.toml with runwisp promote usually reloads as “no task changes”. See Staging and promoting.