View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004757||GNUnet||file-sharing service||public||2016-11-03 00:19||2018-06-07 00:24|
|Reporter||adfeno||Assigned To||Christian Grothoff|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||0.11.0pre66||Fixed in Version||0.11.0pre66|
|Summary||0004757: gnunet-publish keeps terminal busy if using -P|
|Description||According 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 Reproduce||gnunet-identity -C "test-ego"|
gnunet-publish -P "test-ego" -t 1 -N 2 "test-path"
|Tags||No tags attached.|
gnunet-publish.log (1,699,589 bytes)
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.
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"
DISABLEV6 = YES
SYSTEM_ONLY = YES
USER_ONLY = NO
SERVICEHOME = "/var/lib/gnunet"
# End of "/etc/gnunet.conf"
# Begin of "$HOME/.config/gnunet.conf"
SYSTEM_ONLY = NO
USER_ONLY = YES
DEFAULTSERVICES = gns
# 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)
||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.|
||Tried to reproduce, this time with split user-only/system-only, but could not reproduce.|
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.
I have decided to, instead of using the outdated GNUnet I have, to upgrade it using the Guix recipe provided at https://gnunet.org/git/gnunet.git/tree/guix-env.scm.
I'll also try redoing the user and groups setup.
I'll see if the bug persists.
Hi all! I have good news!
Using the latest development version solves the issue.
|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|