Hi,

sorry for picking up on this edge while the thread's general
discussion has advanced further.

The "status" command matters to me; that is why I would like
to address its handling in a more detailed manner.

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:

* Simple semantics are good for implementing simple scripts.
* Simple scripts that have means to implement difficult setups
make such environments favorable for engineers, auditors and
economists alike.

I do understand SystemD's approach as one of trying to enforce an API
into all that is capable of providing "service". The goal is that such
software is required to, by design, provide a mechanism to report on
something called a "status", and that "status" is one of (I use an own
unofficial terminology here):

  * 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?

Before engaging further into a discussion, I want to determine
if my assumptions are right or wrong.

Kind regards,
T.