On 2017-04-14 20:16, Simon Hobson 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". The latter would then allow other processes that depend on a working database to continue.
> At present, IIRC the script starts the MySQL process, then loops round waiting for <something> to appear - at which point it assumes MySQL is ready for action and prints OK on the console.
>
>
> That way, there's a standard way for processes to communicate their status, and a simple and standard way for dependent processes to determine if something they need is ready yet.

I still think this isn't a problem the service manager should attempt to
solve. This is a situation where the database is temporary unavailable,
for which there are many possible reasons. The services which relay on
the database should be able to handle such a situation gracefully, or
they are just not yet stable enough.
I would expect a service which has to handle a task for which it needs
the database to return an error in this situation, but to continue
working. Once the database is available, and a new task arrives which
requires the database, the service should work as expected. If such a
service needs to do some initialization using the database, it can just
re-queue that until the first successful database connection. This way,
there isn't even a need to start the database first, the service would
be rock solid, and there wouldn't be any need for the service manager to
handling such edge cases. Just keep it simple.