tilt! <t...@linuxfoo.de> 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'). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
