On Fri, 14 Apr 2017 21:16:18 +0100
Simon Hobson <linux@???> wrote:

> "Enrico Weigelt, metux IT consult" <enrico.weigelt@???> wrote:
>
> >> For those of us who put consistency above boot speed, simply
> >> changing the init script so MySQL doesn't flag as "started" until
> >> the daemon is up and ready to accept requests would fix it;
> >
> > But then you'll have kind of daemon who watches mysql until it's
> > really ready and then signals back to the service monitor, so it
> > can proceed with the other services. In the long run, sounds like a
> > maintenance hell to me.
>
> Which is why I said I can see some value in a simple
> communication/notification system. Ideally you'd have MySQL itself
> make status calls along the lines of "I'm starting but not ready" and
> hopefully end with "I'm now ready for business".

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.

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.

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.

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.

4) The problem this backward communication purports to solve was solved
around the time the Western Roman Empire was conquored by the
Barbarians. 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]

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. 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.

[1] To run daemontools-encore, download the lastest tarball, untar it,
    modify its conf-* files to reflect correct directories and compile
    commands (usually unnecessary if you're using gcc on Linux), make,
    become root, make install, make the repository for daemontools
    daemons (I used /etc/daemontools/service), make the symlink
    directory (I used /var/daemontools/service), then edit the
    svscanboot file to reflect the actual directories that are being
    used, run svscanboot, and then make run files under the repository
    and symlink them to the symlink directory to install daemons. This
    way, no matter what init system you're using, you have a complete
    supervisor for daemons you believe need to be supervised. And pay
    no attention to the guy on Debian-User who tells you not to use the
    svscanboot file to instantiate your daemontools system.[2]

[2] Recently a guy posted on Debian-User that you shouldn't use the
    svscanboot shellscript to start up daemontools. He states a few
    edge-case situations where svscanboot has bugs, most of which have
    nothing to do with Linux or normal Intel/AMD hardware. He links to
    a few people who have run daemontools by doing various init-foo
    instead of just spawning svscanboot. He just loves to hear himself
    hold forth on all things technical, but what he forgets to tell
    his audience is:

    1) svscanboot is by far the simplest way to run daemontools.

    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.

    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.

    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.

SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques