View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011711 | GNUnet | ARM service | public | 2026-08-03 00:28 | 2026-08-05 06:59 |
| Reporter | Jllx | Assigned To | schanzen | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 0.29.0 | ||||
| Summary | 0011711: can't bootstrap (again :( ) | ||||
| Description | linked to https://bugs.gnunet.org/view.php?id=11629 so I tried today again and now it don't connect... after gnunet-arm -s I monitor connections states using # gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT DXYV direct tcp,udp 4 0 0 1857 ms so it seems to be connected to DXYV and # gnunet-pils -1 82D13WPCJXQ4ZPYKS3XNAEKSSYCM0KG7Z1GKNTK99A391CXJ2MD0 (but not sure it's relevant, since it also output the same result later) # gnunet-core -s Mon Aug 03 00:14:29 2026: Awaiting initiation (R) DXYV (timeout in 0 ms) so it's waiting initiation I do this several time and after some time it ends like this : # gnunet-transport -a No virtual links. # gnunet-core -s nothing displayed # gnunet-pils -1 82D13WPCJXQ4ZPYKS3XNAEKSSYCM0KG7Z1GKNTK99A391CXJ2MD0 still display something # gnunet-arm -I Services (excluding stopped services): (started: 19 / stopped: 16) cadet (binary='gnunet-service-cadet', status=started) core (binary='gnunet-service-core', status=started) dht (binary='gnunet-service-dht', status=started) gns (binary='gnunet-service-gns', status=started) hostlist (binary='gnunet-daemon-hostlist', status=started) namecache (binary='gnunet-service-namecache', status=started) nat (binary='gnunet-service-nat', status=started) nse (binary='gnunet-service-nse', status=started) peerstore (binary='gnunet-service-peerstore', status=started) pils (binary='gnunet-service-pils', status=started) rest (binary='gnunet-rest-server', status=started) revocation (binary='gnunet-service-revocation', status=started) rps (binary='gnunet-service-rps', status=started) setu (binary='gnunet-service-setu', status=started) statistics (binary='gnunet-service-statistics', status=started) topology (binary='gnunet-daemon-topology', status=started) transport (binary='gnunet-service-transport', status=started) communicator-tcp (binary='gnunet-communicator-tcp', status=started) communicator-udp (binary='gnunet-communicator-udp', status=started) done it several time today and it always end like this, is RTT Round Trip Time ? if yes the value varies slightly during my polling from 1857ms to 1859ms so it don't seems to be a "ghost" message (previous message not updated and still displayed, as for gnunet-pils -1 output) | ||||
| Tags | No tags attached. | ||||
|
|
I think I put the wrong catergory : should rather be gnunet-core ? |
|
|
Yeah but this is fine. I can confirm your issue, my peers also disconnected. A simple restart of thepeers would solve the issue temporarily, but I have to investigate this new issue that arises after a day or so of running the peer :( |
|
|
Currently again starting long test. You may try to re-connect. Leaving this bug open until we have a stable connect for a couple of days. |
|
|
ok right now : # gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT PBM3 dv (2 hops) - 4 0 0 0 ms V512 dv (2 hops) tcp 4 0 0 182 ms 7Y6R dv (2 hops) tcp 4 0 0 276 ms DXYV direct tcp 4 0 71 29 ms # gnunet-core -s Tue Aug 04 21:21:18 2026: Hello sent (I) 7Y6R (timeout in 0 ms) Tue Aug 04 21:21:18 2026: Hello sent (I) V512 (timeout in 0 ms) Tue Aug 04 21:21:18 2026: Connected (R) DXYV (timeout in 299 s) |
|
|
for information, I redone the gns test to resolv, it did succeed in 1h20min... ;) I now have more peer reported by gnunet-transport -a but I'm still puzzled where to find the sql database containing peers... my gnunet configuration is "system wide" and I find strange that the database could be stored in root home directory... (and there is nothing in /root/.cache/ related to gnunet) so if you know where to look, you're welcome! |
|
|
Ah I see I understand now what you mean by system wide. This also explains why you have no namestore and identity services running (those must be started per user) and why gnunet-identity hangs when you run it as root (the identity service is not running as that user). To find all paths, you can run $ gnunet-config -f -s paths obviously, GNS should not take over an hour. I guess this warrants some research. |
|
|
Connections seems to be stable for around 12 hours now, can you occasionally try to resolve: $ gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt this record expires every 30 mins (at which point it is re-resolved in the network). If the connections remain stable, and the resolution works, we are good. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-03 00:28 | Jllx | New Issue | |
| 2026-08-03 00:40 | Jllx | Note Added: 0029355 | |
| 2026-08-04 17:27 | schanzen | Note Added: 0029363 | |
| 2026-08-04 17:43 | schanzen | Target Version | => 0.29.0 |
| 2026-08-04 17:43 | schanzen | Assigned To | => schanzen |
| 2026-08-04 17:43 | schanzen | Status | new => assigned |
| 2026-08-04 20:18 | schanzen | Note Added: 0029364 | |
| 2026-08-04 21:23 | Jllx | Note Added: 0029365 | |
| 2026-08-05 00:06 | Jllx | Note Added: 0029366 | |
| 2026-08-05 06:52 | schanzen | Note Added: 0029370 | |
| 2026-08-05 06:59 | schanzen | Note Added: 0029371 |
