Installed new node v1.4.21 - did not generate keys.yml

Node Running
1

I have set up my first node very carefully using the official guide as updated for v1.4.21, on a machine at Cherry Servers - AMD Ryzen 7700X. Double checked every step. When I ran step 8B (to start the ceremonyclient service and create the files config.yml and keys.yml), only config.yml was created correctly. The file ‘keys.yml’ contains only a single line containing ‘null:’. So there is no key to back up in the next step of the instructions!

The service eventually fails like this (I have run it several times now).

root@content-sturgeon:~# service ceremonyclient status
● ceremonyclient.service - Ceremony Client Go App Service

  • Loaded: loaded (/lib/systemd/system/ceremonyclient.service; disabled; vendor preset: enabled)*

  • Active: active (running) since Wed 2024-07-10 20:11:39 UTC; 11s ago*
  • Main PID: 4058 (node-1.4.21-lin)*
  •  Tasks: 161 (limit: 76027)*

  • Memory: 2.1G*

  •    CPU: 18.737s*

  • CGroup: /system.slice/ceremonyclient.service*

  •         ├─4058 /root/ceremonyclient/node/node-1.4.21-linux-amd64*

  •         ├─4074 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=15 --parent-process=4058*

  •         ├─4075 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=5 --parent-process=4058*

  •         ├─4076 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=2 --parent-process=4058*

  •         ├─4077 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=10 --parent-process=4058*

  •         ├─4078 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=3 --parent-process=4058*

  •         ├─4079 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=1 --parent-process=4058*

  •         ├─4080 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=4 --parent-process=4058*

  •         ├─4081 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=7 --parent-process=4058*

  •         ├─4083 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=8 --parent-process=4058*

  •         ├─4084 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=13 --parent-process=4058*

  •         ├─4085 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=12 --parent-process=4058*

  •         ├─4087 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=11 --parent-process=4058*

  •         ├─4088 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=6 --parent-process=4058*

  •         ├─4090 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=9 --parent-process=4058*

  •         └─4091 /root/ceremonyclient/node/node-1.4.21-linux-amd64 --core=14 --parent-process=4058*

Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4088]: Signature check passed
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4091]: Signature check passed
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4088]: {“level”:“info”,“ts”:1720642300.367123,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:"data worker listen>
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4091]: {“level”:“info”,“ts”:1720642300.367752,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:"data worker listen>
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4078]: Signature check passed
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4078]: {“level”:“info”,“ts”:1720642300.374552,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:"data worker listen>
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4090]: Signature check passed
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4090]: {“level”:“info”,“ts”:1720642300.4055157,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:"data worker liste>
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4085]: Signature check passed
Jul 10 20:11:40 content-sturgeon node-1.4.21-linux-amd64[4085]: {“level”:“info”,“ts”:1720642300.450181,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:"data worker listen>
root@content-sturgeon:~# service ceremonyclient status
● ceremonyclient.service - Ceremony Client Go App Service

  • Loaded: loaded (/lib/systemd/system/ceremonyclient.service; disabled; vendor preset: enabled)*

  • Active: activating (auto-restart) (Result: exit-code) since Wed 2024-07-10 20:11:52 UTC; 577ms ago*
  • Process: 4058 ExecStart=/root/ceremonyclient/node/node-1.4.21-linux-amd64 (code=exited, status=2)*
  • Main PID: 4058 (code=exited, status=2)*
  •    CPU: 20.704s*

Could the parsing error shown below in syslog be the reason?

Jul 10 19:23:22 content-sturgeon node-1.4.21-linux-amd64[9895]: Loading ceremony state and starting node…
Jul 10 19:23:22 content-sturgeon node-1.4.21-linux-amd64[9895]: Spawning 15 data workers…
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9923]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9913]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9923]: {“level”:“info”,“ts”:1720639403.0777137,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40008”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9918]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9913]: {“level”:“info”,“ts”:1720639403.0783541,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40001”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9918]: {“level”:“info”,“ts”:1720639403.0788157,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40005”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9914]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9912]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9914]: {“level”:“info”,“ts”:1720639403.0824304,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40006”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9912]: {“level”:“info”,“ts”:1720639403.0831985,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40011”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9920]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9915]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9910]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9920]: {“level”:“info”,“ts”:1720639403.092732,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40003”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9910]: {“level”:“info”,“ts”:1720639403.0930424,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40004”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9915]: {“level”:“info”,“ts”:1720639403.0930583,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40000”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9922]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9922]: {“level”:“info”,“ts”:1720639403.1012797,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40007”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9909]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9928]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9917]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9909]: {“level”:“info”,“ts”:1720639403.103453,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40014”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9928]: {“level”:“info”,“ts”:1720639403.1036823,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40010”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9917]: {“level”:“info”,“ts”:1720639403.1038795,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40002”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9911]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9911]: {“level”:“info”,“ts”:1720639403.105767,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40009”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9927]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9927]: {“level”:“info”,“ts”:1720639403.1077962,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40013”}
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9925]: Signature check passed
Jul 10 19:23:23 content-sturgeon node-1.4.21-linux-amd64[9925]: {“level”:“info”,“ts”:1720639403.1118944,“caller”:“rpc/data_worker_ipc_server.go:92”,“msg”:“data worker listening”,“address”:“/ip4/127.0.0.1/tcp/40012”}
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: 2024/07/10 19:23:35 [JOB 1] WAL file .config/store/000005.log with log number 000005 stopped reading at offset: 6102; replayed 29 keys in 29 batches
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: panic: error constructing p2p: failed to parse multiaddr “/ip4/0.0.0.0/tcp/8336-v1”: invalid value “8336-v1” for protocol tcp: failed to parse port addr: strconv.ParseUint: parsing “8336-v1”: invalid syntax
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: goroutine 1 [running]:
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: source.quilibrium.com/quilibrium/monorepo/node/p2p.NewBlossomSub(0xc00026c140, {0x21b8b80, 0xc008114a10}, 0xc000052100)
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: #011/opt/ceremonyclient/node/p2p/blossomsub.go:179 +0xf98
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: source.quilibrium.com/quilibrium/monorepo/node/app.NewNode(0xc0003b63c0, 0xc0001f6fc0)
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: #011/opt/ceremonyclient/node/app/wire_gen.go:82 +0x1b8
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: main.main()
Jul 10 19:23:35 content-sturgeon node-1.4.21-linux-amd64[9895]: #011/opt/ceremonyclient/node/main.go:426 +0xae5
Jul 10 19:23:35 content-sturgeon systemd[1]: ceremonyclient.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jul 10 19:23:35 content-sturgeon systemd[1]: ceremonyclient.service: Failed with result ‘exit-code’.
Jul 10 19:23:35 content-sturgeon systemd[1]: ceremonyclient.service: Consumed 20.880s CPU time.
Jul 10 19:23:40 content-sturgeon systemd[1]: ceremonyclient.service: Scheduled restart job, restart counter is at 1.

Any suggestions?

2

your config file (ceremonyclient/node/.config/config.yml) is not correct.

find the 8336-v1 and remove the ‘-v1’ from the end and save. Then restart your node.

3

Many thanks! I will try that

4

Thanks!
That seems to have worked. The file keys.yml has been generated properly and the service is staying up. I suspect that the cause is this:
a) Original config.yml as downloaded in step 6 contains this line:

listenMultiaddr: /ip4/0.0.0.0/udp/8336/quic-v1

b) Then the instruction in step 9.1 does not update it correctly:

sed -i 's/listenMultiaddr: \/ip4\/0.0.0.0\/udp\/8336\/quic/listenMultiaddr: \/ip4\/0.0.0.0\/tcp\/8336/g' ~/ceremonyclient/node/.config/config.yml

Thanks again

5

Yes, I suspect that is the case. It is attempting to change the configuration to use TCP rather than UDP for connecting to the network.

The only change(s) for that line to make it work is udp->tcp and the removal of the quic-v1 from the end.

It’s optional, in the event UDP doesn’t actually work for some reason (unknown exactly why, but for some people UDP doesn’t work and switching to TCP fixes it).

I think the philosophy is to change it anyways so you never run into the issue.

1 Like
6

Okay, found why the v1 was there. In 1.4.19 Cassie changed the default ListenMultiaddr to “/ip4/0.0.0.0/udp/8336/quic-v1” (from ListenMultiaddr: “/ip4/0.0.0.0/udp/8336/quic”)

@cassie should I be going through my nodes to change this if still using the old format without the -v1?

1 Like
7

Also @ridgeway, which guide are you using. The official guide is https://quilibrium.com/docs/noderunning and not up to date at all, so assuming you are using one of the unofficial guides.

8

Using this one

as a result of following @demipoet in this forum and on WC and Telegram

9

Just wanted to tag them so they can get their scripts updated

10

Not required – the config handler automatically switches /quic to /quic-v1. It’s an unfortunate side effect of there being a draft version of QUIC and the official RFC, the former having no version on the protocol name, the latter getting stuck with quic-v1 for the multiaddr

1 Like
11

Thank you once again for responding so quickly to my problem the other night. I have since set up two more nodes without a problem.