Chronos, no peers available

Support
1

Issue Report

Source data. Several computers were disconnected from the network from the end of December 2025. Before the disconnection, everything was fine, or even excellent, with the peers. The computers were powered on in the second week of January 2026, but the node has not been able to catch any peers since.

Problem. Nodes cannot find peers.
Service files are old (pre-disconnection), meaning they were working. Nodes see the old block height, cannot see a single peer, synchronization does not happen.

How I tried to solve the problem:

  1. Updated the client version. Tried all possible versions:

    • chronos-2025-nov-07;
    • chronos-2026-jan-05;
    • chronos-2026-jan-15;

  2. Updated the operating system. Was 22.04, now 24.04 (do-release-upgrade);

  3. Changed internet service provider;

  4. Deleted all Autonomys data (not just the db folder) and tried to sync from scratch. In this case, some information exchange happens and the node folder grows to about ~314 MB, but there are still no peers.

This issue is not occurring on just one machine; it’s happening across different providers. I hypothesized that there might be a blockade by the national communications oversight agency, but there is a computer nearby that hasn’t been rebooted for a LONG time and is working perfectly. Also, on this working computer, I am running version chronos-2026-jan-05 from 06/01/26 (I am hesitant to update to chronos-2026-jan-15).

Environment

  • Operating System: Ubuntu 22.04-24.04
  • Space Acres/Advanced CLI/Docker: CLI

Problem

No one peer

[Paste any errors or relevant logs here]

Logs.
Option 1 (machines with a reset node):
2026-01-24T23:20:32.438229Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), :down_arrow: 0 :up_arrow: 10 B/s
2026-01-24T23:20:37.438787Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), :down_arrow: 0 :up_arrow: 7 B/s
2026-01-24T23:20:40.683589Z INFO Consensus: subspace_service::sync_from_dsn: Received notification to sync from DSN, deactivating substrate sync reason=NoImportedBlocks last_completed_segment_index=SegmentIndex(0) last_processed_block_number=0
2026-01-24T23:20:42.439276Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), :down_arrow: 0 :up_arrow: 50 B/s
2026-01-24T23:20:47.439792Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), :down_arrow: 0 :up_arrow: 36 B/s
2026-01-24T23:20:52.440260Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), :down_arrow: 0 :up_arrow: 36 B/s

Option 2. Attempt to continue synchronization not from zero:

2026-01-24T23:22:50.017221Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), :down_arrow: 0 :up_arrow: 10 B/s
2026-01-24T23:22:55.017458Z INFO Domain: substrate: :zzz: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), :down_arrow: 0 :up_arrow: 0
2026-01-24T23:22:55.017538Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), :down_arrow: 0 :up_arrow: 7 B/s
2026-01-24T23:23:00.017729Z INFO Domain: substrate: :zzz: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), :down_arrow: 0 :up_arrow: 0
2026-01-24T23:23:00.017777Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), :down_arrow: 0 :up_arrow: 32 B/s
2026-01-24T23:23:03.125032Z INFO Consensus: subspace_service::sync_from_dsn: Received notification to sync from DSN, deactivating substrate sync reason=NoImportedBlocks last_completed_segment_index=SegmentIndex(187) last_processed_block_number=1159520
2026-01-24T23:23:05.017991Z INFO Domain: substrate: :zzz: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), :down_arrow: 0 :up_arrow: 0
2026-01-24T23:23:05.018034Z INFO Consensus: substrate: :zzz: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), :down_arrow: 0 :up_arrow: 7 B/s
2026-01-24T23:23:07.274943Z WARN Domain: libp2p_kad::behaviour: Failed to trigger bootstrap: No known peers.
2026-01-24T23:23:10.018216Z INFO Domain: substrate: :zzz: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), :down_arrow: 0 :up_arrow: 0

2

Upd.
Start command

ExecStart=/usr/local/bin/subspace-node-lib2p run --name 7958x5 --base-path /mnt/predator1/ --chain chronos --sync full --farmer --blocks-pruning archive-canonical --state-pruning archive-canonical --rpc-listen-on 0.0.0.0:9944 --rpc-methods unsafe --rpc-cors all – --domain-id 0 --blocks-pruning archive-canonical --state-pruning 28800

3

This sounds like you may be experiencing issues hitting the boostrap servers. Could you provide output for the below please (feel free to scrub anything you don’t want to share - we just need to know if they succeed)?

# Check if the DNS resolves correctly
dig bootstrap-0.chronos.autonomys.xyz
nslookup bootstrap-0.chronos.autonomys.xyz

# Test port connectivity
nc -zv bootstrap-0.chronos.autonomys.xyz 30333
nc -zv bootstrap-0.chronos.autonomys.xyz 30533
nc -zv bootstrap-0.auto-evm.chronos.autonomys.xyz 30334

If any of those fail it may help to run a trace to see your network routing:

traceroute bootstrap-0.chronos.autonomys.xyz
4

Sure.
1.
root@x5-B650-Pro-RS:/home# # Check if the DNS resolves correctly
dig bootstrap-0.chronos.autonomys.xyz
nslookup bootstrap-0.chronos.autonomys.xyz

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> bootstrap-0.chronos.autonomys.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4141
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bootstrap-0.chronos.autonomys.xyz. IN A

;; ANSWER SECTION:
bootstrap-0.chronos.autonomys.xyz. 2153 IN A 65.108.232.15

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jan 26 21:11:12 MSK 2026
;; MSG SIZE rcvd: 78

Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: bootstrap-0.chronos.autonomys.xyz
Address: 65.108.232.15

root@x5-B650-Pro-RS:/home# # Test port connectivity
nc -zv bootstrap-0.chronos.autonomys.xyz 30333
nc -zv bootstrap-0.chronos.autonomys.xyz 30533
nc -zv bootstrap-0.auto-evm.chronos.autonomys.xyz 30334
Connection to bootstrap-0.chronos.autonomys.xyz (65.108.232.15) 30333 port [tcp/] succeeded!
Connection to bootstrap-0.chronos.autonomys.xyz (65.108.232.15) 30533 port [tcp/] succeeded!
Connection to bootstrap-0.auto-evm.chronos.autonomys.xyz (3.141.201.231) 30334 port [tcp/*] succeeded!

root@x5-B650-Pro-RS:/home# traceroute bootstrap-0.chronos.autonomys.xyz
traceroute to bootstrap-0.chronos.autonomys.xyz (65.108.232.15), 30 hops max, 60 byte packets
1 router.lan (192.168.88.1) 0.171 ms 0.232 ms 0.291 ms
2 188.242.16.1.pool.sknt.ru (188.242.16.1) 0.941 ms 0.957 ms 0.971 ms
3 router.sknt.ru (93.100.0.158) 0.997 ms 1.007 ms 1.020 ms
4 * * *
5 * * *
6 as24940.ix.dataix.eu (178.18.226.223) 7.142 ms 6.691 ms 6.681 ms
7 core32.hel1.hetzner.com (213.239.224.26) 6.814 ms 6.944 ms core31.hel1.hetzner.com (213.239.224.38) 9.101 ms
8 ex9k1.dc1.hel1.hetzner.com (213.239.252.50) 7.537 ms ex9k1.dc1.hel1.hetzner.com (213.239.252.54) 9.215 ms 9.388 ms
9 static.15.232.108.65.clients.your-server.de (65.108.232.15) 6.662 ms 6.452 ms 6.629 ms

5

Hi @user7

Have you also check if the node on your machine reachable externally. Might also be ideal to check on firewall as well

6

A port scan (https://portscaner.ru/) shows that ports 30333 and 30433 are open for my IP.

7

@ved any advice on what information is required to debug further? OP has confirmed this is a home server so not in a DC.

8

If they are running on a home server, could be an issue with their networking if peers are unable to connect through open connection. Will have to check what is causing this unfortunately

9

Thanks for your patience @user7. We’ve been discussing this internally and given that everything checks out on the connectivity side (DNS, port checks, traceroute all look clean), our suspicion is that the do-release-upgrade from 22.04 to 24.04 may have changed some underlying network or firewall settings. This is a common side effect of that upgrade.

Could you run the following and share the output?

Check what the upgrade did to your network/DNS config:

resolvectl status
cat /etc/resolv.conf
ls -la /etc/resolv.conf
cat /etc/netplan/*.yaml
ip addr show
ip route show

Check for firewall rules that may have been introduced or changed:

sudo iptables -L -n -v
sudo ip6tables -L -n -v
sudo ufw status verbose

Test whether a connection to the bootnode actually persists (not just opens): The nc -zv tests you ran earlier only prove a quick TCP handshake works. We need to confirm the connection can stay alive long enough for the libp2p handshake. Let this run for about 60 seconds then Ctrl+C and share the output:

timeout 60 bash -c 'exec 3<>/dev/tcp/bootstrap-0.chronos.autonomys.xyz/30333 && echo "Connected" && cat <&3'

Check if there are any active connections to peers while the node is running:

ss -tnp | grep -E '30333|30533|30334'

This should help us narrow down whether it’s a firewall/DNS issue from the upgrade or something else at the network level.