Re: [GNUnet-developers] arm service status

[Florian Dold]

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', status=started)
core (binary='gnunet-service-core', status=failed,
      exit_status=6, restart_delay='10 s')

The stopped services are omitted unless you run gnunet-arm with the
-a/--all flag.

Maybe the "service life-cycle" / state machine should be reviewed a bit.
 We now have these states:

1. stopped (=successfully manually stopped or never started)
2. started
3. stopping (=stop requested, either directly or through ARM shutdown,
but service process still lives)
4. failed (and waiting to be restarted)
5. finished (= exited with exit status code 0)

It's now also trivial to add more status information (e.g. number of
retries, when the service was started, the full command line), should
that ever be required.

The monitoring API still uses the old (IMHO insufficient) states.  Maybe
we should merge those two by using the states I've listed above.
However, the monitoring status has the additional "monitoring started"
status, so that's a big ugly.

Note that with the GNUnet process management wrappers, it seems like we
can't distinguish between a process that exited with an error status
code and a process that couldn't be started in the first place (since
the binary doesn't exist).  But that's not really that bad.

- Florian

On 9/24/19 11:22 AM, Christian Grothoff wrote:
> 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 the info log level is
>> too verbose and thus supressed.  I'd consider a service that can't start
>> because of a missing binary a pretty severe error!
> 
> Sure, please fix ;-).
> 
>> Also, "gnunet-arm -I" does not tell you about failed services at all.
>> Is there some fundamental reason why arm can't do this, or is it just
>> not implemented yet?  It currently lists "Running services", there could
>> simply be an additional "Failed services" that lists the last exit
>> status code and the time when the service will be restarted.
> 
> Makes sense, should be relatively easy to add.
> 
>> (This sounds easy enough that I would just give it a shot myself, just
>> wanted to confirm first that there's no complication I didn't know about.)
> 
> I'd indeed not expect any complications from adding this.
> 
> Happy hacking!
> 
> Christian
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>

signature.asc
Description: OpenPGP digital signature