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 |
Status | closed | Resolution | fixed | ||
Product Version | 0.10.1 | ||||
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. | ||||
Attached Files | |||||
|
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" [arm] DISABLEV6 = YES SYSTEM_ONLY = YES USER_ONLY = NO [PATHS] 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. |
|
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. Thanks! |
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 |