Comment 4 for bug 1863318

Hi,

Thanks for the tip!

This logic has changed significantly in Ubuntu 18+ to use new MySQL
functionality to make the upgrade process more robust (using a method of
starting the server that doesn't continue until it's ready for
connections). 20.04 has MySQL 8.0, which has deprecated mysql_upgrade
(upgrades are handled automatically by the server).

Any waiting period would be an unreliable fix (some people would need
longer wait still, and for everyone else it becomes an annoying delay),
and I'm not sure it would be doable to backport major changes in the
maintainer scripts to Ubuntu 16.

--

Lars

On 20/02/2020 14:49, Hans Rakers wrote:
> I just ran into this same issue with 5.7.29-0ubuntu0.16.04.1. It is
> caused by a race condition.
>
> It is a rather large MySQL database, so stopping & starting up the
> daemon takes some time. Tried 'apt-get -f install' multiple times to no
> avail.
>
> After going over the code in /var/lib/dpkg/info/mysql-
> server-5.7.postinst, i managed to "fix" it by adding a 'sleep 5' at line
> 317. Sleep 3 didn't cut it, it had to be sleep 5 :D
>
> Like so:
>
> if ! test_sysmaint_access; then
> invoke stop
> set_mysql_pw "debian-sys-maint" "$pass"
> invoke start
> echo "sleeping 5 secs"
> sleep 5
> fi
> # mysql_upgrade returns exit status 2 if the database is already upgraded
> # (LP: #1566406) so ignore its exit status if it is 2.
> result=0
> mysql_upgrade --defaults-file=/etc/mysql/debian.cnf || result=$?
>
> The way to finally get rid of these issues is to add something in this
> script to check if the instance is ready for connections before starting
> mysql_upgrade.
>