tilt! <tilt@???> writes:
[...]
> Laurent Bercot wrote on 06/08/2015 at 14:21 CEST:
>> [...]
>> And "status". This is very service-dependent: since there is no
>> global API, no service manager, scripts will query the daemon's
>> status in a daemon-specific way. More vagueness again, because
>> "status" doesn't define exactly what you should say, and the lowest
>> common denominator is "is it alive?" but even for this basic check,
>> daemon-specific interfaces are used.
>> [...]
>
> From the discussion in this thread so far, I can determine at least
> the following two problems with "status":
>
> #1 There are not just plain, singular-per-service "daemons"
> involved (extreme, but valid examples include programs
> hosted inside application servers, even more extreme
> is a cumulative service called "networking" that might
> involve all sorts of stuff to be done), and
>
> #2 not all softwares that are providing "services" provide
> "specific interfaces" to query them even for a most
> basic information on them being "alive" or not.
>
> I personally am, however, a fan of simple semantics, and it is
> my understanding that UN*X has always done well when it provided
> simple semantics:
[systemd status]
> * The status is "off" (the service is not alive, and this
> is not due to the service having failed at a previous
> attempt to run it),
> * the status is "on" (the service is alive), or
> * the status is "failed" (the service is alive, and this
> is due to it having failed to start on a previous attempt
> to do so).
>
> My question is, did I understand that correctly?
Short reply because I have a bunch of grotty Java-code I need to deal
with: off/ on/ failed is an ill-defined notion someone pulled
out of his posterior while thinking about the issue 'in abstract' (eg,
does dpkg --remove mean 'off').