On Fri, 14 Apr 2017 21:16:18 +0100
Simon Hobson <li...@thehobsons.co.uk> wrote:
> "Enrico Weigelt, metux IT consult" <enrico.weig...@gr13.net> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
