[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Make "gnunet-arm -e" not hang

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Make "gnunet-arm -e" not hang
Date: Sat, 28 Sep 2019 22:38:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 9/28/19 10:01 PM, xrs wrote:
> I know too little right now to have a good option on the service
> architecture. I guess all CLI tools should check weather the respective
> service sockets are available and if not, simply end with en error
> message. Why should they deal nicely with crashed services? 

It's not just crashed.
Imagine you write a shell script that does:

gnunet-arm -s
gnunet-publish FOO

Then gnunet-publish _may_ run before ARM even initialized FS. Thus, it
makes sense for gnunet-publish to re-try talking to FS.  However, it
_may_ make sense for gnunet-publish to check if at least ARM is running,
and if not give up.  That's now easy to add via a call to

> Another alternative solution might be to give the user feedback like
> "WARNUNG GNUnet not running, cannot stop the peer". At the GNUnet
> workshop at Dresden/Datenspuren we head different UX feedback from
> people telling us that they were confused by "gnunet -e" and other CLI
> tools hanging. Giving them some feedback would immediately help with the
> advantage of not complicating the program logic :-)

Well, gnunet-arm -e should be fixed now, same for gnunet-gns. For other
tools, well, more work to be done ;-).  But as my example above
hopefully explains, we should generally probably test for ARM and not
for the specific service, at least if the service is usually started or
autostarted by ARM.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]