Community-Test (oct6) Offline

Unclear the state atm but 1.3MB upload fell over with some error I can’t parse:

Error: 
   0: e[91mNetDataError: Failed to get current version: NetDataError: Failed to read current value from Register data: NoResponsee[0m

Location:
   e[35m/rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rse[0m:e[35m1897e[0m

Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
1 Like

I am going to restart 1 more time with reduced max_capacity as suggested by @joshuef but mostly so that anyone who has not had time to play and would like to, can.

6 Likes

If you can keep your node logs to debug any of this timeout lark that’d be suuuper :+1: :bowing_man:

9 Likes

ok, I grabbed them, let me know where to put/send them.
(Three nodes had no logs)

Take 3 is up!

5 Likes

upload and dog are fast
but cat is stalling and giving nothing…

There should be the 1.3MB safe gif at
safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y

dog works
safe dog safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y

== URL resolution step 1 ==
Resolved from: safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
= File =
XOR-URL: safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
XOR name: 0x430c86999a1c881bc9d8f933ce137c85f8336bb334dd0de379ab6231443353f6
Native data type: PublicBlob
Media type: image/gif
6 Likes

yes I can’t cat it either.

I can cat my test file though.
safe cat safe://hygoygyybtrdgdisz1u9my5wpthjg8ziuw4sc7xatmnt85yn7yj5m7gkc5mgy > 12345.jpeg


Test is over… for now.

9 Likes

Blast! Missed the fun. I’ll be waiting in the wings.

5 Likes

I went through the logs for the second iteration, below is all that I can find.

root@alpha-safe-node-2:~/logs# cat sn_node.log.2021-10-06-15
“timestamp”:“Oct 06 15:27:16.923”,“level”:“ERROR”,“fields”:{“message”:“Error encountered when handling command: UntrustedProofChain(“provided proof_chain doesn’t cover the SAP’s key we currently know: SectionAuthorityProvider { prefix: Prefix(), public_key_set: PublicKeySet { public_key: PublicKey(1082…b98a), threshold: 1 }, elders: {497347(01001001)…: 159.65.48.36:12000, d3587d(11010011)…: 178.62.57.96:12000} }”)”},“target”:“safe_network::routing::routing_api::dispatcher”,“threadName”:“tokio-runtime-worker”}

“timestamp”:“Oct 06 15:36:57.265”,“level”:“ERROR”,“fields”:{“message”:“Sending message (msg_id: MessageId(7639…1831)) to 47.202.65.195:38087 (name 949436(10010100)…) failed with Some(ConnectionLost(TimedOut))”},“target”:“safe_network::routing::core::comm”,“threadName”:“tokio-runtime-worker”}

5 Likes

Crap, missed it…well next time…
Nice one @Josh

5 Likes

Are you able to upload the logs here in a DM? or perhaps a wee wetransfer or so?

The above error just looks like normal AE when one node perhaps doesnt know about a split as yet…

We’re trying to repro tehse timeout issues locally, but no joy yet.

5 Likes

just fyis, i’ve received the logs,

I’d miss understood w/r/t timeouts. Those are the whole node logs. Which means there was something wrong in startup I think. I’m trying to repro things here.

7 Likes

Trivia expecting not a factor… I wasn’t connected as a node for up.down expecting get is just available to all as normal.

Should the node be creating logfiles in .safe/node/local-node with the command from the OP?

I was seeing the log messages in the console but no logfiles. Ubuntu 20 (I think).

1 Like

So looking at the tool, atm there’s no log level set, which may explain why there’s nothing interesting in the logs.

There was chat about removing -vvv or no eg before, so I think we’ve committed that by mistake, I’m just readding that to the tool now.

ahh, and @happybeing the log files would be in <droplet>/logs

3 Likes

I’m not using a droplet. I tried this on both my laptop and a cloud instance of Ubuntu and it used to create logs in ~/.safe/node/local-node/.

I can’t find a logs directory.

Maybe the CLI needs a flag now? There’s nothing about this in safe node --help or safe node join --help though.

Ah sorry, I misunderstood. The Q is where do logs go for a locally started node?

the param log_dir exists on the node bin, you can specify it there. Otherwise the node will just log to stdout


Also a PR readding more verbose logs to the testnet tool: fix: add logging to droplets once more by joshuef · Pull Request #55 · maidsafe/sn_testnet_tool · GitHub

1 Like

This doesn’t seem to work. I tried --log_dir and --log-dir with both safe node --log-dir join and safe node join --log-dir and it doesn’t recognise the flag. Maybe that’s not what you mean?

Should we try again with better logging?
I will also use s-4vcpu-8gb instead of s-2vcpu-2gb.

4 Likes

Ahh, sorry, you’re another step away with the CLI. I’m not sure what the current status is there for specifying log dir (@chriso you’ve been in and about that recently, maybe you know if that’s possible?)

@happybeing you’d have to run the bin directyl I guess to use that flag if it’s no working w CLI. It should be installed here ~/.safe/node/sn_node so ~/.safe/node/sn_node --log-dir ~/.safe/node/mylogsta should get it going I think (assuming the bin is indeed in that location).

1 Like

Yeah so the node join command doesn’t have any arguments for specifying the logging directory, so you’ll end up with whatever the default logging behaviour is.

We could add this as a feature though.

For the time being, if you need control over the logging, you’d need to launch the node directly.

3 Likes