View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011713 | GNUnet | GNS | public | 2026-08-06 10:48 | 2026-08-07 00:14 |
| Reporter | Jllx | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0011713: GNS takes ages to resolv | ||||
| Description | during bootstrap issue investigation https://bugs.gnunet.org/view.php?id=11711 @schanzen did create a TXT dns record in `info.higepi.gnunet.gns.alt' that expire every 30 min when trying to get this records : $ gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug 2026-08-05T21:25:27.527848+0200 gnunet-gns-35901 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' ... 2026-08-06T02:02:18.690705+0200 gnsrecord-35901 DEBUG Determined expiration time for block with 2 records to be Thu Aug 06 02:32:04 2026 <<< 2 record(s) found: TXT: `Thu Aug 06 02:02:04 2026: Connected (R) M0J8 (timeout in 248 s)' TXT: `Thu Aug 06 02:02:04 2026: Awaiting initiation (R) E2R1 (timeout in 0 ms)' Record set expires in 29 m. 5h... | ||||
| Tags | No tags attached. | ||||
|
|
This needs testing (and some bug hunting). I cannot reproduce such long lookups, but my peers are also rather close to each other and one of them is publishing this record. |
|
|
I tried to fix this in the last couple of commits. Maybe you can test on your side. |
|
|
I now have a cleaner setup of gnunet : multiuser services are started using a init.d openrc script, using gnunet user with home directory /var/lib/gnunet, access mode rwx------ I now also start user services for my user when I try to resolve `gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug` with the user, I have lot of util-client-179138 DEBUG Failed to establish connection to `gns', no further addresses to try, will try again in xxx s. when I `su gnunet -c "gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug" ` there is no such error, and it faster fail ;) 2026-08-06T23:24:37.270459+0200 gnunet-gns-179694 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' ... 2026-08-06T23:27:37.421824+0200 gns-api-179694 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-06T23:27:37.421848+0200 util-scheduler-179694 DEBUG GNUNET_SCHEDULER_shutdown with latest update, I've much more peers : $ gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT 0TG0 dv (2 hops) udp,tcp 4 0 0 856 ms E2R1 dv (2 hops) udp,tcp 4 0 0 605 ms PBM3 dv (2 hops) udp,tcp 4 0 4 553 ms V5T8 dv (2 hops) udp,tcp 4 0 2 367 ms V512 dv (2 hops) udp,tcp 4 0 0 132 ms 2GPG dv (2 hops) udp,tcp 4 0 0 275 ms 7Y6R dv (2 hops) udp,tcp 4 0 4 105 ms DXYV direct udp,tcp 4 0 0 0 ms YSEZ dv (2 hops) udp,tcp 4 0 0 421 ms and don't know if it's related to setup, or to your changes, but I feel like the connection and getting peers was much more fast, almost instant (I run the gnunet-transport command a few seconds after starting the service, and it was already populated |
|
|
by the way, how do I know my peer ID? |
|
|
su gnunet -c "gnunet-gns -t EDKEY -u higepi.gnunet.gns.alt -L debug" 2026-08-06T23:41:09.871528+0200 gnunet-gns-181169 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `EDKEY' records under `higepi.gnunet.gns.alt' ... 2026-08-06T23:44:10.052555+0200 gns-api-181169 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-06T23:44:10.052595+0200 util-scheduler-181169 DEBUG GNUNET_SCHEDULER_shutdown so both resolv did failed, but faster ;) (about 3min) maybe this could be great to have some "traceroute" like feature in gnunet-transport? not displaying ip addresses but peer ID instead? I don't know how the DHT is accessed, and if there is some "relays" (for example if I connect to DXYV, and ask for dns resolution, but since DXYV don't have the answer, it forward the request to it's own peer, so OTG0, E2R1... (is "dv (2 hops)" means that there is DXYV between me and the (for example) 0TG0?) if yes, this could be interesting to have some "on the fly info" like HH:mm:ss sending request to DXYV HH:mm:ss DXVY asked 0TG0 : no answer (duration ms) HH:mm:ss DXVY asked E2R1 : no answer (duration ms) HH:mm:ss DXVY asked PBM3 : PBM3 asked XYZA : no answer (duration ms) ... |
|
|
or maybe something like HH:mm:ss sending request to DXYV HH:mm:ss DXYV : no answer, forwarding request HH:mm:ss DXVY.0TG0 : no answer (duration ms between DXVY request and OTG0 answer) HH:mm:ss DXVY.E2R1 : no answer (duration ms between DXVY request and E2R1 answer) HH:mm:ss DXVY.PBM3 : no answer, forwaring request (duration ms between DXVY request and PBM3 answer) HH:mm:ss DXVY.PBM3.XYZA : no answer (duration ms between PBM3 request and XYZA answer) ... or if trusting ntp, instead of duration, UTC start time and answer time... (format HH:mm:ss.xms) this would help finding if this is a connection issue (for example PBM3 to XYZA connection is really slow) and if there is some issue reaching the target that have the DHT information I don't know if there is some kind of cache mecanism like dns has (when requesting a name in dns, if the dns server you connect to don't have the answer, it will try to resolve and cache the result, so next time you ask to resolve, it will answer you straight) but having such trace could help resolv issue linked to cache.... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-06 10:48 | Jllx | New Issue | |
| 2026-08-06 11:17 | schanzen | Note Added: 0029384 | |
| 2026-08-06 22:58 | schanzen | Note Added: 0029396 | |
| 2026-08-06 23:38 | Jllx | Note Added: 0029397 | |
| 2026-08-06 23:44 | Jllx | Note Added: 0029398 | |
| 2026-08-06 23:58 | Jllx | Note Added: 0029399 | |
| 2026-08-07 00:14 | Jllx | Note Added: 0029400 |
