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

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 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: [storage] 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.

What needs a restart

A reload that changes any of these is rejected:

• [daemon], every key except include and include_cron. This includes timezone.
• [storage].
• [notify], [notifiers.*], and [[route]].

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>.

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.