Open DeadManWalkingTO opened 2 years ago
I see same sync/connections errors, daemon consistently stalls out
can any devs comment?
The hard-codes seed nodes in v0.14.1.0 became non-operational at some point, and have been updated in #235, #238, #256. This is the main reason why we’re preparing for the new release v0.14.2.0.
how do I build from source, binaries are a no-go for me , sorry
git clone --recursive https://github.com/aeonix/aeon
cd aeon
make
that builds 0.14.1.0 tho correct? which has connection issues? how do I build 0.14.2.0 from source?
No, v0.14.1.0-aeon
is a particular tag given to a specific commit 612714c which has the seed node issue. The above command checks out the latest commit of the master branch which currently is e3ed1d0 where the seed node issue is fixed.
The release v0.14.2.0 has not yet been made.
No, that specific commit does not fix the seed node issue.
2022-03-05 19:56:03.759 [P2P5] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 431608/1450620 (29% 1019012 blocks remaining) 2022-03-05 19:56:05.436 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 431808/1450620 (29% 1018812 blocks remaining) 2022-03-05 19:56:07.066 [P2P4] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432008/1450620 (29% 1018612 blocks remaining) 2022-03-05 19:56:08.778 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432208/1450621 (29% 1018413 blocks remaining) 2022-03-05 19:56:10.378 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432408/1450621 (29% 1018213 blocks remaining) 2022-03-05 19:56:11.953 [P2P4] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432608/1450621 (29% 1018013 blocks remaining) 2022-03-05 20:14:13.964 [P2P5] WARN global src/p2p/net_node.inl:1344 No incoming connections - check firewalls/routers allow port 11180 2022-03-05 21:14:14.036 [P2P8] WARN global src/p2p/net_node.inl:1344 No incoming connections - check firewalls/routers allow port 11180
Your node is syncing just fine. The warning message is just suggesting you to open port 11180 so that others can download blocks from your node.
I do not believe my node is running fine. I will run it for 72 hours and report back here, which I have already done before with your previously mentioned commits.
I am not using Docker or TOR, why is there an issue with 11180? Why is it not mentioned in the basic instructions?
You will eventually see "SYNCHRONIZED OK" message when your node catches up 100% with the network.
It’s common that your router or firewall to block incoming connections by default.
You don’t have to open the port and ignore the warning.
Thanks, I am ignoring that warning, seems like network needs more nodes?
It is up to 65% right now 500382 blocks for me.
Network sync is much slower than in years past, seems borderline frustrating to use. It seems like if you quit the daemon and restart it, it seems to progress further, but if you just leave the daemon running, it does not sync as fast, if at all seemingly.
Is there a need to spin up more seed nodes?
When new release v0.14.2.0 is released, that will be good, but only if the sync is fast, otherwise the pruning/mobile/small block chain size aspect of this coin that originally drew me to it is not as much of an advantage. It's hard to have a mobile phone running this long to sync the chain from block 0 to block 100%.
The number of seed nodes doesn’t affect the sync speed. Sync is very slow if your storage is a spinning hard disk drive rather than an SSD. Otherwise, sync speed is determined by the number of transactions in each block; if the usage gets higher, the sync time gets necessarily longer. There’s no getting around this principle. Pruned node only reduces the required storage size, not the sync time.
My storage is SSD with 50GB+ free space.
It it still stuck at [206.189.157.58:11180 OUT] Synced 950304/1450686 (65% 500382 blocks remaining)
I used to be able to sync into the 1,000,000+ blocks just fine. Now, it gets stuck around block 950304. Stuck for over an hour on the same block? So the computational time for the transactions argument makes no sense based on past experience.
I am using Ubuntu 20.04.4 LTS Focal so that has got to be part of the issue. But I will try on 18.04 VM at some point soon.
The daemon gets hung up completely on 20.04.4 LTS Focal
This looks like a daemon crash to me.
Any other insights?
I just got done testing the daemon on Ubuntu 18.04 and it stalls out too with the exact same behavior as noted above. Got my first stall when syncing from block 0 at block 589840 40%
I gave up for now... if the answer is to restart the daemon X number of times before you can get a full sync from block 0... that's not cutting it for me. No crypto exchange could tolerate that. You can't even do escrow reliably. Ping me if there is ever a serious attempt to stabilize the daemon. Doesn't seem like help is wanted at the moment.
@stoffu "pruned node"? that's a re-write of history. this whole coin used to be pruned.
I have been running VPS compiled current release compiled on it (Aeon 'Chronos' (v0.14.1.0-12e5dad85)) on Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-100-generic x86_64) with no issues syncing from 0 the first try.
You may be connecting to a bad outdated node that's been stuck for quite some time on an old chain (possibly old seed node?) but it sounds like you tried compiling master branch which should have the new seed nodes. I have not had much good luck using a VM to run a node on. You should try compiling on native OS. Additionally, if you use VPN connection your above issue will happen even on native OS.
Also, you can try the binaries from the Github CI build: https://github.com/aeonix/aeon/suites/5440605553/artifacts/172660856
sync stable now 100% no restart daemon less 50% to 100% ubuntu 20 focal
Original release v0.14.1 (win 64bit) have sync/connection errors... Build from source (win 64bit) (v0.14.1.0-e3ed1d0e6) have fix those errors!!!