Dear Developers, I just added a new configure option --disable-autostart to disable auto startup of services by ARM. If this option is not given, auto startup of services by ARM is enabled; this is the behavior before.
The rationale for this is that during large scale experiments we only test some subsystems of GNUnet and hence we only need to enable those respective services to be run for each peer. The problem is not with the presence of these unnecessary services -- ARM handles them efficiently and only starts them when a request for these service arrives instead of starting them all together. For this, ARM allocates the listening sockets for the services and whenever a connection is made to these sockets it starts the services and passes the listening sockets to them. The problem happens with this behavior while starting a lot of peers on systems with network file systems. When the services are configured to use UNIX domain sockets (which is mostly the case for all services on a UNIX based system), ARM tries to first allocate the domain sockets on the network file systems for these services. As we start a lot of peers, lot of ARM processes try to allocate these sockets. As a result, the network file system gets quickly saturated and the bind calls get delayed, resulting in a delayed peer startup times. This is to be addressed with the new --disable-autostart configure option. For this all services should use the line "AUTOSTART = @AUTOSTART@" instead of "AUTOSTART = YES" The option, if used, will then replace "@AUTOSTART@" with "NO" in the default configurations of the services. Should you as a service developer think your service should not be started by default at all, you may set "AUTOSTART" to "NO" in the default configuration. Otherwise, I request you to always use "AUTOSTART = @AUTOSTART@". One may now suggest that instead of having this option, the experiments can use a configuration which overrides each services' "AUTOSTART". But with a new service showing up every fortnight, it is cumbersome and error prone to update experiment's configurations. Regards, Sree Harsha _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
