So seems like this env variable needs to be set explicitly every time, irrespective of being set in .bashrc and restarting it.Super weird. I never realized it because whenever I did echo on CARDANO_NODE_SOCKET_PATH, it gave me the right path so I “assumed” it was properly being set from .bashrc
I’m confused at what I’m supposed to do. No matter how many times I run the “export CARDANO_NODE_SOCKET_PATH=~/relay/db/node.socket” in the terminal I continue to receive the same <socket: 11> after I re-testing using “ardano-cli shelley query tip --testnet-magic 1097911063”
Any assistance provided would be greatly appreciated.
Interesting thing is that now I get almost the same error when I run the “cardano-cli shelley query tip --testnet-magic 1097911063” within my home directory
cardano-cli: Network.Socket.connect: <socket: 10>: does not exist (Connection refused)
And receive the standard error after running the same function as above “cardano-cli shelley query tip --testnet-magic 1097911063” within my relay directory
cardano-cli: Network.Socket.connect: <socket: 11>: does not exist (Connection refused)
Idk what I’m doing wrong with this tbh… Thank you for anymore assistance.
No matter how many times I verify and execute the correct path for the socket file to be exported into the db folder it doesn’t work. I go back and verify within the db folder if the socket file get’s placed there it doesn’t show up.
Maybe because when you kill your cardano node process, this doesn’t kill the established socket connection that the database uses, and so to “reset it” and let your system know that a new socket connection needs to be created because the db is using the old one, so in order to run a new instance of cardano node, maybe you have to ‘kill the socket connection’, and export the “path socket” again because the system thinks it doesn’t exist because it’s still in use even though you shut down the node,or it could be that if you wait too long to restart your node, maybe there is a socket timeout, and if you don’t restart it soon enough, the cardano-cli or system will treat the socket as being open when it actually isn’t…I don’t know anything about it…I’m just taking a wild stab…what else would explain the bizarre intermittently working behavior of the “export path” command for the socket when you have already written it to .bashrc and ‘sourced’ it? I’m just taking a wild guess…maybe this weird behavior can be pinpointed by using a combination of commands like netstat -a | grep -i socket, echo $CARDANO_NODE_SOCKET_PATH, etc.
I didn’t bother trying to pinpoint to figure out why it fails sometimes, I just make a short alias to circumvent this ‘headache’ whenever it appears. Yes, it appears to be a persistent problem for many users.
I hope that other people can find this solution and it’ll help them maneuver this issue. It’s taken me days to get passed this small issue using the Stake Pool School guide and know that others will face this same tiny issue.
Thank you so much everyone for all of your assistance!
Yes, absolute paths and relative paths make a big difference, your cardano-cli ‘’–socket-path ~/relay/db/node.socket" flag will work from anywhere because you’re using an absolute path which specifies the location independently of whatever location (directory) you run cardano-cli command from as long as you don’t change to some other user like root; whereas, a relative path like ‘–socket-path db/node.socket’ only works when you do the command inside the directory that contains the ‘db’ directory.
Understood so I will definitely need to be aware once I do start making changes to my users and such once I start working towards releasing my Mainnet version.
I still get <socket: 11> error often. That’s one of the most persistent issues on cardano node.
One way to deal with it is add the following line to ~/.bashrc:
alias xnp=“export CARDANO_NODE_SOCKET_PATH=~/relay/db/node.socket && source ~/.bashrc”
Then whenever the problem arises just type “xnp” without the quotes in the command line. You only need to source .bashrc the first time, then after than you can just type “xnp” without quotes to ‘eXport Node-socket Path’ and ‘source ~/.bash’ with a single command, you can call the alias whatever you want, just make it something you can remember and that it doesn’t
clash with an existing bash command.
Note: This only works for people who have their ‘relay’ folder in their home directory. If you have your relay folder insider your cardano-node directory, and cardano-node directory is in your home directory, then change the line in .bashrc to…
alias xnp=“export CARDANO_NODE_SOCKET_PATH=~/cardano-node/relay/db/node.socket && source ~/.bashrc”
I realize now why this is a persistent issue (one of the reasons if not the only reason).
Source .bashrc only works on a ‘per terminal window’ basis.
if you open a terminal (emulation) window using xterm, terminator, terminal, etc. then ‘sourcing’ .bashrc only works within that window; i.e., alias, functions, etc. within .bashrc only work within the ‘sourced’ term window. If you open up a new terminal window and try to run an alias from that window, it won’t work. You have to ‘re-source’ .bashrc from within that new term window.
The exception to this rule is that ‘sourcing’ . bashrc from any terminal window will enable aliases, etc. within .bashrc to be executed within console windows after you log into them, regardless of which console window you’re using;i.e., you don’t need to ‘re-source’ .bashrc for consoles (console windows).
Note: This isn’t the case for every term window you use. Only certain term windows need to have .bashrc ‘re-sourced’. Still can’t figure that one out.
should I see the node socket path just like I see ~/.local/bin and ~/.cabal/bin because I see those two but I have yet (never) seen the socket one show up in that same place (environment path).
