Failed to initialize p2p server -- only when adding node #8034
Comments
|
Are you able to compile monero yourself? |
|
Thanks for the tip. I will do that. |
|
I have Monero 'Oxygen Orion' (v0.17.2.3-release) - It has no --proxy parameter Additionally, is there a guide on what parameters to use with the proxy-supporting version? |
|
Monero 'Oxygen Orion' (v0.17.2.3-97b7a41bf) $ ./build/Linux/release-v0.17/release/bin/monerod --help |grep -i proxy (no --proxy option) I've just compiled this, supposedly it's the latest version from github. Is there a different hash I should have checked out? |
|
2021-11-02 10:24:47.903 I Monero 'Oxygen Orion' (v0.17.0.0-e22ec26be) |
|
I remove this one line from the arguments: And immediately I no longer get the "failed to initialize p2p server" error message and it no longer quits. |
|
I see the issue now. You are trying to add priority nodes with the wrong port. 18089 is the RPC port, what you need is the P2P port at 18080. |
|
Wouldn't/shouldn't the P2P port be the one listed in the node lists online? That's what I went by. I saw both 18080 and 18089 in the same lists, so the various port numbers didn't seem off because of that. Strange. Anyway, thanks for the tip. I'll do just that and will report back. |
|
If you want to connect with a wallet then you need the RPC port (most of time 18081 or 18089), if you want to connect with your node to another node you need the P2P port (18080). Please report back if this worked, closing it for now. |
|
So that didn't work, either. Here's my full start line (sans backslash): ~/bin/monerod --proxy 192.168.X:9050 2021-11-02 15:00:22.680 I Monero 'Oxygen Orion' (v0.17.0.0-e22ec26be) So... that didn't solve it. And I don't see why the startup should fail if I add a node that doesn't work. Some could go down or come back up later as I restart it. But as you can see, the port number wasn't the issue. I've changed it to 18080 as suggested, still the same startup issue. |
|
That's a lot of options and it makes it difficult to find the issue. Try this: This works fine on my system. Does it also work on yours? |
|
I'll check in a sec. +1 question in the meantime: everything goes through the proxy when using --proxy and --tx-proxy is unnecessary when using it, correct? |
|
$ ~/bin/monerod --proxy 192.168.X:9050 --add-priority-node node.moneroworld.com:18080 $ ~/bin/monerod --add-priority-node node.moneroworld.com:18080 |
|
Maybe yours is fully synced? Mine is only at around 50%. But regardless, none of these arguments should cause an issue, even during sync. Especially add-priority-node alone (with not even a proxy). |
|
Can you start with --log-level 2? |
|
2021-11-02 15:47:29.543 I Loading checkpoints Hm. Should I still specify TCP DNS on the command line before starting it up? The proxy is a TOR proxy. The log isn't saying what DNS it's attempting to use. Or whether it's trying to resolve through the proxy or not. The account running monerod does not have direct internet access, only to reach the TOR SOCKS proxy. |
|
I've added DNS_PUBLIC=tcp://91.239.100.100 before the start line (a public DNS server which allows TCP connections on port 53). Still the same result. Although I would expect/hope that the hostname is simply passed to the SOCKS server rather than a public DNS. But either way, it doesn't work. I've also given full access to the account running monerod to connect to and reach that public DNS server. No change. |
|
There is also the |
|
DNS_PUBLIC=tcp://89.233.43.71 ~/bin/monerod --proxy 192.168.X:9050 --proxy-allow-dns-leaks --add-priority-node node.moneroworld.com:18080 --db-sync-mode fast --log-level 2 ... $ host node.moneroworld.com 89.233.43.71 node.moneroworld.com has address 96.43.139.226 |
|
More debug info: no connection is made to the SOCKS proxy - with or without --proxy-allow-dns-leaks. |
|
+1 piece of info: no packets sent to the DNS server 89.233.43.71 - whether using --proxy-allow-dns-leaks or not. It just somehow decides the hostname is wrong regardless of what I do, and without communicating through the proxy or otherwise. |
|
So I've added iptables rules to log so I could check what's happening:
All of those are problematic, but especially with (3), it will be pretty hard to connect to onion nodes, right? Shouldn't the hostname be passed to the TOR SOCKS proxy when I don't have --proxy-allow-dns-leaks as an argument? I might be able to route TOR's DNS lookups to it, but at the very least I need to be able to pass monerod a custom DNS server that it will use to look up peers/priority nodes passed on the command line. If I put something in /etc/resolv.conf it will affect everything else on the box and I would prefer monerod to use something custom, separate from everything else. It would be great if I didn't need to do any of that and it could just use the socks proxy given to it on the command line. |
|
Seeing the ignored parameters, should this issue be re-opened perhaps? It was closed under the assumption that the issue was caused by a wrong port - which is not the case. Though even with a bad port, I believe the program should start up regardless. Otherwise nodes going down would cause the launcher to no longer be able to start up monerod. |
|
I can reopen it, but it seems something related to your local setup which I'm not familiar with so someone else has to reply. |
|
@martinoshub The --proxy flag doesn't have DNS support implemented. This means it tries to use your system DNS when using the --add-priority-node flag, which fails. As a workaround you can simply add an IP address for now. |
|
That explains. But it also prevents me from using .onion nodes. Sure, I can do a lookup and then use that on the command line. But when TOR is restarted, the associated IPs will no longer work. I wonder what --enable-proxy-dns-leaks does though, if monerod will keep bypassing the proxy to look up hostnames anyway. To summarize, IMHO the things to do are:
Since these are definitely things to add, implement and fix, I propose the issue be re-opened (or consolidated into a new issue). |
monerod will lookup dns seed nodes, dns ban list and do dns update checks if you specify Specifying hostnames via command line arguments will resolve on startup and the program will terminate if this isn't possible (that's what you are seeing), with or without
It's fine if a node stops working, the daemon will only abort on startup if it is unable to resolve a hostname. If you only specify IP addresses this won't happen.
To sum things up, try the following:
|
Thanks for your answers, they have been helpful (see later below). One thing I'd like to argue though: if I specify an IP address, it may be out of date even though the hostname is kept up-to-date. If monerod will start with a non-working node and would continue to look up DNS for the nodes as their IP changes, it doesn't make sense to refuse to launch and it would be a degraded way of handling nodes for me to do one IP lookup and insist on that for all future launches. I get the suggestion as a workaround (and I am doing just that), but the correct proxies should be used even on startup. It should be no different in the long run. That is why I kindly request a fix to that part. I do appreciate your pointers about adding both --proxy and --tx-proxy, something I asked about earlier. It's my fault that I missed the documentation on anonymity networks. I thought --tx-proxy was only for transactions and didn't know the implications when it's used in conjunction with --proxy. The only question I still have is, if monerod gets hostnames seeded from other nodes and it tries to look them up - will it be able to do that? Since there's no local DNS available that it can use. During runtime, will those hostnames be looked up through the SOCKS proxy, or using the TCP DNS through the socks proxy? Or will it only be able to connect to nodes with an IP address advertised, if it can't use the system DNS? I'll close the issue for now, but would appreciate clarification on the last question regardless. Thanks in advance. |
Monerod starts fine (with torsocks). However, when I try to add any nodes with --add-priority-node or --add-peer, it never gets to the point of properly starting up and instead quits with:
ERROR daemon src/daemon/main.cpp:362 Exception in main! Failed to initialize p2p server.
The peer can be regular ipv4 or .onion, the same thing happens. It just quits. As soon as I remove the --add-priority-node or an --add-peer argument, it starts up.
Not sure what to make of this. Since monerod will connect to nodes on its own after some time, I don't see how specifying a few extra nodes on the command line should prevent it from starting up, so my guess is that this is some bug. But could be wrong. Any feedback would be appreciated.
The text was updated successfully, but these errors were encountered: