This is actually related to a GNS-ish bug, which is that right now pretty much none of our APIs offer a nice way for us to decide between (1) "service may have crashed, keep trying" and (2) "service not running period, give up".
(1) is what is currently always done, in part because I'm not sure what the best way to _sanely_ tell the two cases apart is. We have this problem with gnunet-gns (waits if GNS service is down) during NSS integration, as well as with gnunet-arm -e, but overall this affects all tools: they deal nicely with crashing services, but badly when the services are not running at all. Beyond the issue of distinguishing the two cases, there is the question of how to nicely deal with the situation _without_ complicating the logic in all of our programs. 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. The is a slightly awkward heuristic, as after launching ARM it may still take a few cycles for the listen socket to appear. We probably should also modify "gnunet-arm -s" to not terminate until the listen socket appears, as otherwise the above change would break some tests. WDYT? On 9/25/19 4:02 PM, xrs wrote: > Hi all, > > I stumple upon a problem that always got into my way when using > gnunet-arm: If the services are not running and I execute gnunet-arm -e > it hangs. How about ending it normally with some exit code >0? > > cheers, > xrs > > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
