Live reloading

One of the design decisions of Fisher is to rely on an in-memory queue to store all the jobs waiting to be processed. While this allows Fisher to be faster (and avoids the need to configure an external database), having no persistency means if the Fisher process is restarted all the jobs in the queue will be lost.

Fisher needs to be restarted from time to time though, mainly if you need to add new scripts or the configuration has to be changed. In order to avoid losing the queue in those cases, Fisher has support for reloading the scripts list and its configuration at runtime, without restarting the process.

Reloading with signals

In order to reload Fisher, you need to send a SIGUSR1 to the main Fisher process: if you don't use any process manager on your machine, a simple killall should do the trick:

$ killall -USR1 fisher

This command will reload all the Fisher instances the current user has the rights to send signals to: if you have multiple instances running it might be best to get the right PID and send the signal only to that one (with the kill command).

What happens when you reload a Fisher instance

When you tell a Fisher instance to reload, multiple things happens to ensure everything is reloaded properly. Here is a list of all the steps. Please note there are no guarantees this list will be accurate in past or future releases.

  • First of all, the Fisher instance is locked, to prevent errors with new jobs coming in while updating the configuration: this means no new queued jobs will be processed, and the webhook endpoint will reply with 503 Unavailable.

  • Then, if any setting in the [http] configuration section is changed, the entire internal HTTP server is restarted.

  • Then, if any of the other configuration entries is changed, their value is updated.

  • Then, all the scripts will be reloaded from disk.

  • Finally, the Fisher instance is unlocked, even if the reload fails.