I've implemented the extended gnunet-arm output in 6aa35f62a8005 and
d07beeb5398.
We now get the following as output, and the API gives out the the
structured data, instead of just a formatted string:
nat (binary='gnunet-service-nat', status=stopped)
set (binary='gnunet-service-set',
I've implemented the extended gnunet-arm output in 6aa35f62a8005.
We now get the following as output, and the API gives out the the
structured data, instead of just a formatted string:
nat (binary='gnunet-service-nat', status=stopped)
set (binary='gnunet-service-set', status=started)
core
On 9/24/19 11:14 AM, Florian Dold wrote:
> Hi *,
>
> I ran into two usability issues with GNUnet's arm:
>
> When a service couldn't be executed at all because the binary doesn't
> exist, arm logs a message at the *info* log level. This means the
> message usually won't be seen *anywhere*, since
Hi *,
I ran into two usability issues with GNUnet's arm:
When a service couldn't be executed at all because the binary doesn't
exist, arm logs a message at the *info* log level. This means the
message usually won't be seen *anywhere*, since the info log level is
too verbose and thus supressed.
