Indeed, the mysql-8.0 pre-install script does in fact attempt to
shutdown an already loaded server, although there are some conditions
where it cannot do so, and opts to leave this to the administrator:
https://git.launchpad.net/~usd-import-
team/ubuntu/+source/mysql-8.0/tree/debian/mysql-
server-8.0.preinst?h=ubuntu/eoan-devel
However, there aren't error messages in your logs matching those
conditions, so presumably it failed to restart due to some unpredicted
error.
Googling on the error message you reported returns a lot of hits, but
unfortunately the underlying issues tend to be fairly diverse. IOW this
is kind of a general error that can occur for a variety of reasons. The
most common workaround is, as Rafael already mentioned, to kill any
stray mysql processes. serverfault lists a few different techniques for
doing this workaround, though it doesn't discuss causes:
https://serverfault.com/questions/477448/mysql-keeps-crashing-
innodb-unable-to-lock-ibdata1-error-11
This link provides a nice summary of some of the various causes and workarounds:
https://bobcares.com/blog/innodb-unable-to-lock-ibdata1-error-11/
Looking through the logs and files apport collected, most of those do
not appear to apply here, however #6 AppArmor configuration is a
possibility, since I notice this in your kernel log:
[ 5.751778] audit: type=1107 audit(1573173793.070:76): pid=1084
uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
operation="dbus_method_call" bus="system"
path="/org/freedesktop/systemd1"
interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
mask="send" name="org.freedesktop.systemd1" pid=1336
label="/usr/sbin/mysqld" peer_pid=1 peer_label="unconfined"
It's unclear to me why apparmor denied the dbus call for mysqld, but it
sounds like apparmor issues can indeed lead to error 11, so seems
plausible.
Looking at the /var/log/mysql.error.log, it looks like there was an error
trying to update the user table, and an error about setting up the mysqlx
plugin:
2019-11-08T00:17:19.663864Z 6 [ERROR] [MY-000061] [Server] 1396 Operation
ALTER USER failed for 'root'@'localhost'.
2019-11-08T00:17:19.664126Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld:
ready for connections. Version: '8.0.17-0ubuntu2' socket:
'/tmp/tmp.MJ77SSpw6n/mysqld.sock' port: 3306 (Ubuntu).
2019-11-08T00:17:19.797164Z 0 [ERROR] [MY-011300] [Server] Plugin mysqlx
reported: 'Setup of socket: '/var/run/mysqld/mysqlx.sock' failed, can't create
lock file /var/run/mysqld/mysqlx.sock.lock'
2019-11-08T00:17:19.797258Z 0 [System] [MY-011323] [Server] X Plugin ready for
connections. Bind-address: '::' port: 33060
...
2019-11-08T00:40:40.460318Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld
(mysqld 8.0.17-0ubuntu2) starting as process 9465
2019-11-08T00:40:40.479422Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock
./ibdata1 error: 11
So, mysqlx appears to have failed at creating its lock file, and then 23
minutes later another mysql process starts up and runs into locking
errors.
Unfortunately that's as much as I can glean from the logs: It might be
an apparmor config issue, or it might be something to do with mysqlx.
But I agree with Rafael that to make progress sorting this, we'd really
need to see steps to reproduce this issue detailed.
** Summary changed:
- Unable to lock ./ibdata1 error: 11 (Resource temporarily unavailable)
+ Unable to lock ./ibdata1 error: 11 (Resource temporarily unavailable) when
upgrading from 19.04 to 19.10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851741
Title:
Unable to lock ./ibdata1 error: 11 (Resource temporarily unavailable)
when upgrading from 19.04 to 19.10
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1851741/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
