IGD issues… Tried to connect 3 times… All good, best of luck with latest test net also best of luck to @StephenC, will be missed!
Also didn’t think that would be possible…bug! cc @lionel.faber !
I’ve updated the cmd to launch a node when using port forwarding in the OPs on both topics to contain all the original droplet node IPs - this is because the genesis node, which was the only IP specified originally, seems to be having more errors than other nodes - perhaps because it was being used by those port fwding?
If you are port fwding then consider killing your node & relaunching with all IPs listed as hard coded contacts
$ $HOME/.safe/node/sn_node --public-addr <public ip:port> --local-addr <localnet ip:port> --hard-coded-contacts=[\"178.128.164.253:52181\",\"46.101.21.162:34546\",\"178.128.169.151:34948\",\"178.62.20.236:12000\",\"159.65.60.126:44800\",\"178.128.161.75:34431\",\"178.128.162.219:55531\",\"178.128.169.114:35708\",\"178.128.161.137:59232\",\"178.128.170.69:45043\",\"178.128.169.206:59730\",\"178.128.169.23:52762\",\"178.128.166.44:50687\",\"178.128.169.93:58040\",\"178.128.172.153:52125\",\"178.128.167.101:53725\",\"178.128.169.109:55504\",\"159.65.24.159:56465\",\"178.128.170.97:37173\",\"178.128.172.235:53286\",\"178.128.160.4:52049\",\"178.128.169.33:46106\",\"178.128.169.57:42902\",\"178.128.168.75:36398\",\"138.68.191.226:46181\",\"178.128.175.25:33290\",\"188.166.175.46:46503\",\"178.128.169.227:54173\",\"206.189.121.46:32982\",\"178.128.169.152:33365\",\"178.128.162.146:59775\",\"178.128.172.1:54636\",\"178.128.161.127:48264\",\"46.101.17.48:59649\"]
EDIT - updated cmd above to add a \
before every "
to escape it.
I see more Encountered a timeout
results now and less Retrying after 3 minutes
. Same as with v6.
With v6 Retrying after 3 minutes
count dropped to zero on the next day. Let’s see what will happen with v6.1.
Any successful nodes out there? With or without fixed IP? What OS?
Node PID: 10792, prefix: Prefix(1), name: c8384f..
Public, static IP, Windows 7.
My node is getting huge amount of ChunkStorage: Immutable chunk already exists, not storing
messages.
So it tries to store the same chunk over and over.
Mine has finally been connected, despite the errors,
I had to let it try to connect every minute though…
On fixed IP (skip IGD) and RPI
I got "Retrying after 3 minutes’’ on Mac with fixed IP, but now it is back to ERROR
Looks like a bug:
My node, c8384f
, stores chunks c0...
to df...
- 249 files.
But I see in logs:
[tokio-runtime-worker] DEBUG 2021-06-25T00:21:47.158351+03:00 [src\node\event_mapping\node_msg.rs:26] Handling Node message received event with id fb5cec99..: NodeQuery { query: Chunks { query: Get(Public(9e82a8(10011110)..)), origin: EndUser { xorname: 121758(00010010).., socket_id: 121758(00010010).. } }, id: fb5cec99.. }
[sn_node] DEBUG 2021-06-25T00:21:47.158351+03:00 [src\node\node_api\handle.rs:51] Handling NodeDuty: ReadChunk
[tokio-runtime-worker] INFO 2021-06-25T00:21:47.158351+03:00 [src\node\chunks\mod.rs:74] Checking used storage
[tokio-runtime-worker] INFO 2021-06-25T00:21:47.158351+03:00 [src\node\data_store\mod.rs:153] Used space: 115099548
[tokio-runtime-worker] INFO 2021-06-25T00:21:47.158351+03:00 [src\node\data_store\mod.rs:154] Total space: 50000000000
[tokio-runtime-worker] INFO 2021-06-25T00:21:47.158351+03:00 [src\node\data_store\mod.rs:155] Used space ratio: 0.00230199096
[sn_node] DEBUG 2021-06-25T00:21:47.158351+03:00 [src\node\node_api\handle.rs:51] Handling NodeDuty: Send [ msg: OutgoingMsg { msg: Node(NodeQueryResponse { response: Data(GetChunk(Err(DataNotFound(Chunk(Public(9e82a8(10011110)..)))))), id: 2144af70.., correlation_id: fb5cec99.. }), dst: Section(9e82a8(10011110)..), section_source: false, aggregation: None } ]
Why anyone should ask 9e82a8
chunk from me?
By the way, ReplicateChunk(
storm is still going.
Using 2-3 MB/s of incoming traffic and writing 0 files for ~half an hour.
Nice one this could be the source of a bug we have missed. Replication was redone last testnet quite quickly. @yogesh and @lionel.faber will check this out. Could be the last of the data missing issues if we are not relocating chunks properly. We have not seen this in house even with churn network, tests. So great catch
Well that was fun while it lasted - @dirvine said he did not expect this one to be up for long. I hope plenty was learned from this iteration and fresh bugs uncovered.
EDIT: posting at the same time - looks like valuable clues gathered
I want to clarify what happened.
At 0:12 of local time my node joined network.
Instantly it started filling with chunks.
At 0:19 node is having 100 chunks.
At 0:21 - 200 chunks.
Then both things happened: file creation speed slowed down, but replicate commands were not slowing down.
At 0:27 node is having 249 chunks.
At 0:52 node is still having 249 chunks, replicate commands arriving.
At 0:54 one additional chunk arrived: 250 in total. Replicate commands are slowing down.
At 1:01 node activity is stopped. But not completely.
During night node stored 12 additional chunks and now, at 6:57, it have 262 of them.
Is the network up still? I was late to the party and there seems to be a suggestion it is not up anymore, but no direct statement.
Network is looking like zombie now.
Some activity is happening, but it mostly broken.
For example, someone sent me chunk 86e107
4 minutes ago and checked if my node actually stored it 2 minutes ago.
(why 86e107
by the way? Other chunks are in c0
…df
range)
Yes, it is in zombie mode as @Vort says. So we can mark this as now effectively offline. There is an issue with data replication for sure. So we need to crush that.
@neo I’ve just tried creating keys, uploading a small text file to the network then cat
ing it and it worked for me, so I’d say the network can still be used for very light testing at least.
I missed most of the action last night so I will try to see ifit is sufficiently alive that I can play wit @Traktion 's IMIM blog app.
wsl 2 ubuntu
safe node install doesnt work with 1.1.1.1 dns with WARP,
only dns 1.1.1.1 works