> I've for now pushed a fix where the detection that ARM is running > isn't done in PROGRAM_run() or SERVICE_run() but specifically by the > programs where we know that they need it, so in
$ gnunet-arm -e Sep 28 21:38:48-560488 gnunet-arm-15572 WARNUNG GNUnet not running, cannot stop the peer Seems to work. Thank you! On Sat, 28 Sep 2019 01:02:30 +0200 Christian Grothoff <[email protected]> wrote: > On 9/27/19 2:25 PM, Schanzenbach, Martin wrote: > > Right now, my best idea is to modify GNUNET_PROGRAM_run() to detect > > "is ARM running" by asking it which services are running, and if we > > fail to detect the ARM listen socket, we give up hard. > > Furthermore, we could pass information to GNUNET_PROGRAM_run() > > which subset of services ARM must support (via autostart or have > > launched), and again give up if the required service(s) are not in > > the set. 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? 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 :-) saludos, xrs
pgpxprW9hEyLv.pgp
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
