Hey, I was recently reading over some of the code in CLI and in the node, and was wondering about the node shutdown policy. It seems the current policy of the CLI at least is, to shutdown a node, it issues a killall to the node processes with a SIGKILL (on POSIX systems. Windows does something similar though). There is a shutdown command in sn_node/utils.rs but I don’t see it used anywhere yet.
As far as I can tell, SIGKILL seems to be the only code path to shutdown a node in today’s code. Is this correct?
That’s correct at least from CLI point of view. In the future, I think we should have some API/service expose by sn_node which can be used to send all kind of commands including to shut it down. E.g. changing config params, rewards/farming payments wallet address, storage/resources that the user is willing to make available for farming, etc. This service could be used to also gather stat info, like farming rewards, number of chunks served, etc.
This could be a JSON-RPC over QUIC service similar to what we have between authd and CLI (I thhink it’s a good choice as it will help us to support remote connections/management from anywhere), or any other type of type of protocol we want the API to be exposed on.
Ahh, now that you mention this, I recall another thread on this forum where that idea came up!
You mentioned that sn_authd does something like this already, so I took a look at that as well. The library qjsonrpc currently sits in the sn_api crate, but are there any plans to spin it off into its own crate? It seems that, if one were to remove the specific references to sn_authd, it could semi-readily be re-used in sn_node or elsewhere we wanted.
Just thinking out loud now, but some of the json-rpc types are also agnostic of quic (e.g. JsonRpcRequest and friends ), so it may be possible to bring those in as a dependency eventually and cut down on code. Admittedly, I, personally, don’t know of any crates that offer just the json-rpc data types as of right now.
As far as cleaning up node resources on exit goes, the reason I ask is because I was thinking it might make some of the error handling simpler and result in a bit faster node operation. Certain operations could definitely benefit from not having to anticipate a sudden termination at any moment.
Here’s one example that comes to mind. If we had a clear exit path we wouldn’t need to sync_all() so much when storing chunks. The process of storing the used storage value, syncing to disk, storing the chunk, and syncing again could be simplified (and sped up) to storing the used value and the chunk without any flush to disc, trusting the node will sync the OS buffer to disk when the program exits properly (given that a SIGKILL termination would not ensure any of the data makes it disk). Then the node isn’t obligated to ensure a graceful exit on sudden termination, which seems more in line with the purpose of killing a process aggressively (like when using SIGKKILL).
Yes, it’s already a separate crate, it’s for the moment and just to keep it simple for us to maintain now to be in the same repo as sn_authd and sn_api, but all components in that repo are independent crates, you can use qjsonrpc from any app already: crates.io: Rust Package Registry. Don’t expect the API to be super polished though, but if you happen to start using it, it will be great to hear about your experience with it, and/or receive PRs with improvements.
Just following up with this thread. I’ve been playing around with the qjsonrpc interface to try and implement something like discussed above. The interface has been actually rather smooth, save a few bumps here and there.
There’s some quality of life stuff I found while playing around that might make the experience smoother, and I’ve started submitting issues to GitHub as I run across them. In any case, I may start a new thread for that, since the original topic is a little out of scope. I figure, worst case, it’s a good playground app for testing the qjsonrpc interace
Sounds good! we can even consider committing what you are playing with as an example app within that crate? that’s for sure something devs usually look at first to try to understand how to use it.
