3

I'm trying to set some off-chain storage through a different terminal using a custom subcommand after starting up the node.

Question here is: Is there any way to call the custom CLI subcommand in the same context in which I've started my node?

In my opinion, if we start a node in the terminal and if we trigger a CLI subcommand in another terminal then they both will be executed in a different context(means the custom CLI will not be able to modify anything on the context in which the node is running).

So can we achieve this scenario? Do we need to wrap our custom CLI logic in the node startup logic or is there any other way?

3
  • Like we do for insert keys from the different terminal after running the node, I want to achieve the same for off-chain storage but the problem I'm facing here is to get the off-chain storage instance without creating a new runner. As we get the backend instance from the new_partial() and new partial accepts a sc_service::Configuration which we'll get from the after creating the runner. May 4, 2022 at 6:48
  • Then the RPC should be extended if your use-case is not possible rather than hacking with two terminals? May 9, 2022 at 9:32
  • Yes, you are correct, we can achieve this through RPC, but for now, I've added a check on the node startup logic to set the configurations. May 9, 2022 at 9:40

1 Answer 1

1

This is more of a Systems Programming question, rather than Substrate specifically.

The node you start with the first command is one process in the Operating System, and whenever you call the node binary again, you will be simply creating a new process.

Unless some clever Inter Process Communication solution is established for CLIs (which Substrate does not provide out-of-the-box), you can't communicate with a node via CLI after it's already started.

The only way to modify the behaviour of a node after it's already started is via RPC (which technically is just a flavour of IPC tailored for communication between separate machines over network).

Please note that the process for inserting keys (mentioned in the comments) is merely modifying the keystore on disk (e.g.: ~/.local/share/node-template/chains/local_testnet/keystore/). It happens regardless of the node being running, and if the node is running, it will have to be restarted for the changes to take effect.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.