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

[Christian Grothoff]

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
GNUNET_CLIENT_test().

> 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.

signature.asc
Description: OpenPGP digital signature