Nano-node: Add RPC endpoint and SIGHUP for reloading toml files

[zhyatt]

Add a new RPC endpoint and SIGHUP for proper process management to allow config.json file to be reloaded by the node without requiring a restart.

[think4sec]

In addition, can the "config.json" file to be used as an override for internal defaults? This way "config.json" is never changed by node software. Exceptions should be thrown for deprecated config entries (to inform admin of stale configuration items).

To show state of the running config, the option "--showconfig" should be added. To change config, either user must update "config.json" and set override value (restart or issue SIGHUP signal to take effect), or issue "--setconfig " from command line.

[cryptocode]

SIGHIP implemented for config-access.toml in #2487. This is harder to do for configs in general because config options are passed by both copies and reference in the node. I think the best route is to do a refactoring - first step maybe to remove json config support to clean things up.

[zhyatt]

@theohax We are looking to get some of the low risk, likely atomic, config options to allow here for V22.

[My1]

I think this is awesome, especially if the config-rpc can be reloaded, e.g. to start a lazy bootstrap (which requires RPC control) without being down for a while due to a restart

[zhyatt]

I think this is awesome, especially if the config-rpc can be reloaded, e.g. to start a lazy bootstrap (which requires RPC control) without being down for a while due to a restart

Note the initial implementation of this will be restricted to certain config values being allowed to be changed and being able to do so through RPC specifically is not available in this initial setup for V22 I believe.

@theohax @dsiganos Can you share which config values are setup to allow changing in V22? And also how this signal is sent to the node to reload?

[My1]

@zhyatt I think you misunderstood me a little. I am not planning to use RPC to do the reload, but just would sent the sighup via the bash I can launch via docker exec. being able to just RPC in some process signals sounds kinda crazy anyway.

my current main issue is that if I need to do some commands that need RPC control I always need a full restart of the node which is just annoying and if I could sighup reload the config that could be cool.

the point that it weill be restricted for certain settings is a lot more interesting tho, as that might actually be a concern.

[theohax]

I think this is awesome, especially if the config-rpc can be reloaded, e.g. to start a lazy bootstrap (which requires RPC control) without being down for a while due to a restart

Note the initial implementation of this will be restricted to certain config values being allowed to be changed and being able to do so through RPC specifically is not available in this initial setup for V22 I believe.

@theohax @dsiganos Can you share which config values are setup to allow changing in V22? And also how this signal is sent to the node to reload?

AFAIK, at least in the PR which I had created earlier, only bandwidth_limit and bandwidth_limit_burst_ratio were allowed to be updated. Also, the signal can be just sent to the nano-node process once the config file has changed and the process would re-read the file. Please correct me @dsiganos if the new implementation differs in any way.

[dsiganos]

Doing a complete config reload is too difficult at this point in time.
We added code to reload only the bandwidth_limit and bandwidth_limit_burst_ratio when a SIGHUP is received.
This functionality does not exist on Windows.
There is also existing functionality that reload the IPC config on receipt of SIGHUP.

[zhyatt]

This ticket is broader than the existing #3257 and other signal management tasks. Moving to V23