View Issue Details

IDProjectCategoryView StatusLast Update
0005071GNUnetfile-sharing servicepublic2017-06-10 19:19
Reporterdavid_lAssigned Toamatus 
PrioritynormalSeveritymajorReproducibilityalways
Status assignedResolutionopen 
Product VersionSVN HEAD 
Target VersionFixed in Version 
Summary0005071: gnunet-search fails to return results after around 1-2 hours of running gnunet
DescriptionTested this on a Devuan and a Parabola GNU/Linux installation.

First left gnunet running over night and had no search results when waking up which had worked when I started gnunet-arm. I then restarted gnunet and got search-results for the same search right after. 2 hours later it failed to return results again and then I restarted it and it worked. Waited 2 hours again and it failed and worked again after restart.
Steps To Reproducegnunet-arm -c /etc/gnunet.conf -s
gnunet-search test
<some output>

[wait 2 hours]

gnunet-search test
[no search results]
Tagsfile-sharing service, gnunet-search

Activities

amatus

2017-06-08 16:38

developer   ~0012240

09:10 < amatus> were the search results files that you published or ones from
                the network?
09:11 < amatus> just wondering if this can be reproduced on a disconnected node
09:11 < davidl> some of both
09:11 < davidl> same host, local network host and someone else.

david_l

2017-06-10 15:47

reporter   ~0012246

So I had a download of a 2.6GB file from another peer which I canceled at 18% then restarted the services on seeder peer and restarted the download on the other.

Then from the seeder peer I ran a gnunet-search which gives results, but within a minute - approximately 30 seconds - the gnunet-search fails (hangs). This failure is however, temporary and a new search soon works again.

The other failure - when leaving gnunet running for a couple hours or over night - I have not found to come back into a working state again.

david_l

2017-06-10 19:19

reporter   ~0012247

In reply to the last note: the gnunet-search hangs exactly up until the last percentage point at which it was before canceling a download.

In slightly more detail:

The download peer starts a download and runs it up to 20% then cancels it. They then restart the download which will again start from 0% - now the seeding peer can't use gnunet-search. I ran gnunet-search several times after the restart and exactly when the downloading peer reached the 20% that it previously canceled at, the seeders gnunet-search started working again (giving results).

Issue History

Date Modified Username Field Change
2017-06-08 16:07 david_l New Issue
2017-06-08 16:09 david_l Tag Attached: file-sharing service
2017-06-08 16:09 david_l Tag Attached: gnunet-search
2017-06-08 16:38 amatus Note Added: 0012240
2017-06-08 17:16 amatus Assigned To => amatus
2017-06-08 17:16 amatus Status new => assigned
2017-06-10 15:47 david_l Note Added: 0012246
2017-06-10 19:19 david_l Note Added: 0012247