On 15.04.2017 03:17, Steve Litt wrote:

> Sounds like a good idea, but it's not, for the following reasons:
>

> 1) There will be endless arguments about HOW each and every daemon will
>    let its init system know "I'm now ready for business". The number of
>    different ways will make the number of incompatible Unixes of 1985
>    seem trivial to reconcile.

Exactly the reason why I'd put it an separate library - so it can be
easily replaced (even on binary level), w/o ever having to touch the
application itself. It will be the operator's choice, which one shall
be used.

The whole problem arised w/ upstreams wanting such an mechanism,
and nobody there who gagged up Lennart quick enough ...

So, what do we make out of that now ?
a) patch behind all the upstreams all that thoughless upstreams
for all eternity
b) maintain an dummy drop-in replacement (and keep up w/ everyting that
the Lennartists come up) for all eternity
c) provide a simple and stable API for exactly the root problem,
(and convince upstreams to use that instead of Lennartware) and
everybody can go its own way in piece.

> 1.5) The resource daemon's opinion of being "ready for business" might
>      be erroneous, or not reflect how the user daemon will use the
>      resource daemon.

Such things must be defined (on per service level) anyways - we'll
never get around that. All we can do is try to standardize certain
scenarios. For start, I'd define "READY" as fully operational.
If some daemon provides several services, which be up/down independently
(which I'd consider bad design), we could introduce sub-services
(eg. apache might serve http as well as ftp) - would just add another
const char* parameter.

> 2) The connected and powerful will unilaterally declare one method of
>    "phoning home" is the one true way, thereby driving compatability
>    wedges between various software, and facilitating the defacto
>    banning of some daemons from a distro.

That something we do not want. Actually the (de)potterization is one
aspect of that.

> 3) If the "one true way" is complex, for instance, if it has to
>    intimately mesh with dbus (saaaay whaaaaat?), small daemon projects
>    will be ostricized out of the community.

There doesn't need to be "one true way". It's only for a specific range
of scenario: let the daemon just shout out it's overall status (what's
required for startup ordering, and similar stuff, eg. some *trivial*
monitoring) to anybody who's interested in it - the exact definition
of that "anybody" would be confined to the specific implementation of
the library - the application has no idea about that, and shouldn't
even care whether somebody's listening.

So, again, in the trivial case that would just be an dummy.
If the library also maintains pidfiles (which I'd recommend, so we now
have that stuff confined in one place), the lib of course has to
implement that. But whether anybody actually reacts on the service
notifies should be completely optional.

As an application developer, I can just call that library, and dont have
to care what happens then (okay, I'll have to consider that it might a
few cycles in there).

> 4) The problem this backward communication purports to solve was solved
>    around the time the Western Roman Empire was conquored by the
>    Barbarians.

You mean, back then when the fascists just killed everybody who didn't
submit to their rule and destroyed freedom (we still suffer from the
roman law) ? ...

>    Regardless of your init system, run your daemons from
>    daemontools, and have your daemontools run scripts refuse to start
>    unless a test of the needed resource indicates it's working.
>    Whatever init system you're using, it's easy to get Daemontools, or
>    preferably Daemontools-Encore, running.[1]

How exactly does it get that notification from the application ?
Or does it go the other way round, having - per application - monitoring
programs, that try to figure out whether the service is up and signals
that to the rest ?

Again: application developers want an interface for sending such
notifies to the init system / service monitor. Whether you, or me, or
anybody else, is actually using that, isn't in their scope - they just
want that interface, therefore they're using the only thing they know,
which happens to be Lenntart's proprietary one. So, let's just give them
what they want, in a way that doesn't cause us any pain.

> A word about the source of this thread: A guy, whom I /dev/nulled over a
> year ago for making very disturbing political posts in response to
> technical discussions, magically woke up a few days ago and started
> resurrecting all sorts of dead threads.

You're not talking about me, don't you ?
(you wouldn't reply my mails then, right ?)

> My /dev/null log tells me he's
> sent 20 or 30 emails. I don't begin to know what causes this person to
> act this way, but he's not a friend of our community, and we might want
> to think twice about responding to him, even in the few cases where he
> has a good idea.

On which list is that happening ?

>     2) djb created svscanboot, and although this guy holding forth is
>        very smart (IMHO in a Poettering sort of way), if you're going
>        to criticize djb on technical grounds, your name had better be
>        Einstein or Hawking.

Well, djb is a bit ... special.

While it's design is incredibly small and elegant, it's releases aren't
complete packages - more a toolbox to build something on your own.
(once upon a time, a client explicitly requested this, so I had to
packege it for *ggrrr* Suse)
Most operators (not even to speak of end users) don't want to go that
route. Therefore, it's up to us - dist folks and integrators - to
provide ready-to-use packages ontop of those toolboxes.

Surf+friends fit into the same category (looks like the suckless folks
are also fans of plan9)

>     3) Differently named copies of svscanboot, each with its own
>        directories, can implement some degree of startup order in
>        daemontools, even though daemontools is widely regarded as
>        having indeterminate start order.

Doesn't seem like something the average operator wants. Haven't had a
closer look into it for ages, but I guess, that we could make it useful
for a wider audience (on dist level).

>     4) If one were to run into one of those edge cases where a
>        daemontools system has bugs if started with svscanboot, they
>        might be fixable by changing the svscanboot shellscript, and
>        that would be infinitely preferable than all sorts of init-foo.

Apropos shellscript: anybody ever thought of rewriting some parts in
C ? Might be interesting to squeeze out a bit more performance for
embedded systems.


--mtx