[debian-mysql] Bug#739846: Bug#739846: invoke-rc.d: initscript mysql, action "start" failed.

[Bob Proulx]

Robie Basak wrote:
> What if /etc/mysql/debian-start fails? Should we be checking the result
> code of this and exiting with the same status? Or should we be ignoring
> the result of /etc/mysql/debian-start (as I think we are now) and
> returning 0 in all cases, as the daemon itself has started?

Note that the /etc/init.d/mysql script uses "set -e" and therefore if
/etc/mysql/debian-start fails returning a non-zero exit status then
the /etc/init.d/mysql script will exit non-zero at that point.
Therefore the case you are asking about is already handled.

Putting my programmer role hat on I must first say that I would always
check and handle errors as soon as possible and practical.  However
using "set -e" has many subtle problems and should be avoided.  There
has been discussion about this already see Bug#621020 for example.  I
myself would never use "set -e" in an init script.

Also for the mysql start the upstream startup is the mysqld_safe
script.  Debian launches that in the background asynchronously.
Therefore that part of the init shouldn't ever be possible to fail,
unless the /usr/bin/mysqld_safe is missing or corrupt for example, or
if the system is out of process slots and the fork fails.  Since being
run asynchronously in the background the main part of the startup
can't really be checked at that point.  Those are sanity checked prior
to launching.

> Although if we fail when /etc/mysql/debian-start fails, the daemon would
> already have been started even though we're returning failure which
> could be confusing.

Yes on being confusing.  And that has been possible already if the
debian-start fails currently.  But hopefully if it were to fail it
would emit a suitable error message.

However currently the default action of that script also launches
actions asynchronously in the background.  The default for that script
unless it is locally modified is that it shouldn't be possible to fail
either.  Unless there is catastrophic system resource use causing fork
et al to fail.  System events causing fork to fail are very hard to
handle gracefully.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20150630/d1f21a27/attachment.sig>