Re: Determining whether gnunet is connected

[madmurphy]

When I had it running years ago, and saw actual "peers" connected, I had no idea what I did right, and since then I've never managed to replicate the success.

You had written in a previous email that you had been able to run GNUnet but then you filled the disk and got this error:

error: database or disk is full

Martin suggested you to reduce the quota assigned to the database to 1 GB. At the same time I attached a link (among others) to the § /var/lib/gnunet/ grows too big section of the ArchWiki which explains how to edit manually the /etc/gnunet.conf file to reach the same effect.

If the disk space is already full you might also need to get rid of the previous database manually.

But there are things we don't know and therefore we cannot help you unless you tell us.

• What command do you use to launch GNUnet?
  1. gnunet-arm -s?
  2. sudo -u gnunet gnunet-arm -s?
  3. sudo -u gnunet gnunet-arm -c /etc/gnunet.conf -s?
  Each of them has slightly different consequences on where the database and the configuration file are located.
• What distribution do you use? Did you compile and install GNUnet manually or did you use a precompiled package?

Instead of being us not willing to explain, could it be that you might be skipping some of the suggestions?

On Tue, Mar 1, 2022 at 8:48 PM Bob Ham <rah@settrans.net> wrote:

On 01/03/2022 18:25, madmurphy wrote:
>     I find it astonishing that you talk about "Applications provided by
>     GNUnet" as if someone can download GNUnet right now and run these
>     things. They can't. Please don't write web pages as though they can.
>
> I don't know which distribution you use, but if you use Arch you can
> install the |gnunet| <https://aur.archlinux.org/packages/gnunet> AUR
> package and a bunch of other related packages
> <https://aur.archlinux.org/packages?K=gnunet>, and they will work.

Not according to the denizens of the #gnunet IRC channel:

13:26 < dvn> GNUmoon: gnunet is useless until transport (and connected
layers) are fixed/rewritten
13:26 < dvn> that's the fact of the matter
13:27 < dvn> how can you debug CADET when the layers beneath have bugs
which make it unreliable
13:27 < dvn> it's a fools errand
13:28 < dvn> i mean no offence by saying this -- especially not to you
for trying -- but i get sad seeing people try to use this and running
into the same walls
13:28 < dvn> (over and over)