View Issue Details

IDProjectCategoryView StatusLast Update
0004757GNUnetfile-sharing servicepublic2018-06-07 00:24
Reporteradfeno Assigned ToChristian Grothoff  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.10.1 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004757: gnunet-publish keeps terminal busy if using -P
DescriptionAccording to the documentation that already comes with gnunet-publish, if I create a namespace and use it with -P option, I'm allowed to update shares when needed (in case I forget some metadata, keyword or file content).

And since our documentation on this process no longer reflects the actual namespace creation steps, I decided to ask on IRC for where to create such namespace. So I was told to use gnunet-identity's -C option to do so. I did:

$ gnunet-identity -C adfeno-shares

And then, `gnunet-identity -d` does list the ego "adfeno-shares" there, along with a set of characters in the right side.

I also asked what must be done to associate such ego to a namespace, and was told that it's already done by gnunet-identity.

So I went ahead and tried to use gnunet-publish, like so:

$ gnunet-publish -P adfeno-shares -t 1 -N 2 "Xera - Llume"

Note: Llume is a music album from Xera. In this case, it's a directory containing the audio tracks as .opus files.

To my surprise, however, the last command (gnunet-publish with -P option) keeps the current terminal busy, not even accepting Ctrl + C or termination signal. It only accepts kill signal.

Despite this, gnunet-publish tells me that the publication of the directory was successful and gives me the gnunet-download syntax to try out.

If, however, I remove -P, -t, and -N, gnunet-publish does the publication and exits when finished, although this might not allow me to make future updates to the content published.

I have attached an strace of `gnunet-publish -P "adfeno-shares" -t 1 -N 2 "Xera - Llume"`.
Steps To Reproducegnunet-identity -C "test-ego"

gnunet-publish -P "test-ego" -t 1 -N 2 "test-path"
TagsNo tags attached.



2016-11-03 00:19


gnunet-publish.log (1,699,589 bytes)


2016-12-24 22:49

reporter   ~0011610

Using `gnunet-publish` with -l [Some log file path] -L "DEBUG" and the publishing options described earliear gives the following message in the log file:

# Begining of message
INFO Reserving space for 791 entries and 2637568 bytes for publication
# Ending of message

However, in the case of this log message, the files being published have a total size of only 24 MB, and it's only 8 files inside one directory.


2017-01-03 17:22

reporter   ~0011613

For those who want to know how GNUnet is running here:

I installed it as local user through Guix (package manager).

And created a gnunet user (with its home set to "/var/lib/gnunet"), a gnunet group, and made my local user a member of gnunet group.

Then, made a crontab entry for the gnunet user so that gnunet-arm starts when rebooting the system and takes "/etc/gnunet.conf" as configuration file.

And for the local user, I start gnunet-arm at will, taking "$HOME/.config/gnunet.conf" as configuration file.

Here follows the configuration files' contents:

# Begin of "/etc/gnunet.conf"

SERVICEHOME = "/var/lib/gnunet"
# End of "/etc/gnunet.conf"

# Begin of "$HOME/.config/gnunet.conf"
# End of "$HOME/.config/gnunet.conf"

Addendum: Sorry for the duplicated "/etc/gnunet.conf" file, the page doesn't show the buttom to remove the attachment.
etc gnunet.conf (96 bytes)

Christian Grothoff

2017-01-03 18:30

manager   ~0011614

Just tried it on my system, but without the split user-only/system-only setup, and it worked fine. So I _suspect_ it is because some IPC failure caused by the user-only/system-only split (note that this is not the fault of the reporter, but simply a configuration that I rarely use while testing). So I should try again with a more precise reproduction of the setup.

Christian Grothoff

2017-01-04 21:52

manager   ~0011616

Tried to reproduce, this time with split user-only/system-only, but could not reproduce.

Christian Grothoff

2017-01-04 21:55

manager   ~0011617

Looked at the log file, it's also not useful :-(.

=> We need to urgently update our bug reporting procedures, especially to help with bugs relating to non-termination, as properly reporting those is tricky and requires some instruction.


2017-01-08 15:03

reporter   ~0011621

I have decided to, instead of using the outdated GNUnet I have, to upgrade it using the Guix recipe provided at

I'll also try redoing the user and groups setup.

I'll see if the bug persists.


2017-03-27 13:45

reporter   ~0011979

Hi all! I have good news!

Using the latest development version solves the issue.


Issue History

Date Modified Username Field Change
2016-11-03 00:19 adfeno New Issue
2016-11-03 00:19 adfeno File Added: gnunet-publish.log
2016-12-24 22:49 adfeno Note Added: 0011610
2017-01-03 17:14 Christian Grothoff Assigned To => Christian Grothoff
2017-01-03 17:14 Christian Grothoff Status new => assigned
2017-01-03 17:22 adfeno File Added: etc gnunet.conf
2017-01-03 17:22 adfeno Note Added: 0011613
2017-01-03 18:30 Christian Grothoff Note Added: 0011614
2017-01-04 21:52 Christian Grothoff Note Added: 0011616
2017-01-04 21:55 Christian Grothoff Note Added: 0011617
2017-01-08 15:03 adfeno Note Added: 0011621
2017-02-21 18:46 Christian Grothoff Target Version => 0.11.0pre66
2017-02-22 21:49 Christian Grothoff Status assigned => feedback
2017-02-22 21:49 Christian Grothoff Target Version 0.11.0pre66 =>
2017-03-27 13:45 adfeno Note Added: 0011979
2017-03-27 13:45 adfeno Status feedback => assigned
2017-03-27 16:47 Christian Grothoff Status assigned => resolved
2017-03-27 16:47 Christian Grothoff Resolution open => fixed
2017-03-27 16:47 Christian Grothoff Fixed in Version => 0.11.0pre66
2017-03-27 16:47 Christian Grothoff Target Version => 0.11.0pre66
2018-06-07 00:24 Christian Grothoff Status resolved => closed