[MDEV-21312] MariaDB Server fails to start up on Debian Created: 2019-12-13 Updated: 2020-01-12 Resolved: 2020-01-12 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - TokuDB |
| Affects Version/s: | 10.3.20 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Blocker |
| Reporter: | aa chen | Assignee: | Unassigned |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | need_feedback | ||
| Environment: |
debian10，在开发板bananapi-m3中运行，armhf |
||
| Attachments: |
微信图片_20191214134044.jpg
微信图片_20191214134051.jpg
微信图片_20191214134057.jpg
微信图片_20191214134103.jpg
微信图片_20191214134116.jpg
微信图片_20191214134124.jpg
|
| Description |
|
mariadb.service - MariaDB 10.3.20 database server |
| Comments |
| Comment by Marko Mäkelä [ 2019-12-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I noticed the same on our CI system yesterday:
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-buster-amd64/builds/1441/steps/mtr/logs/stdio For what it is worth, I develop InnoDB on Debian GNU/Linux Sid (unstable), but I never install the packages; I run tests directly from the build directory. The message suggests that this could have something to do with the Galera cluster. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-12-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I am almost certain that this problem is specific to Galera 3 or WITH_WSREP=ON before MariaDB 10.4. The issue is not present in 10.4, where the Galera write-set replication (WSREP) changes were heavily refactored. I see that 10.3 is the first platform where these Debian builders are enabled. The problem could affect 10.1 and 10.2 as well, but I did not set fixVersion for those, because I am basically guessing until we have narrowed down the exact cause of the failure. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jan Lindström (Inactive) [ 2019-12-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
From logs I see
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-12-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
d'd, can you please include some relevant output of journalctl -xe? We would like to see what exact error is preventing the server from starting up. On our CI system, it sometimes fails due to TokuDB:
We seem to have some incorrect error handling there. Why do we attempt to start further storage engines after reporting a fatal signal? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-12-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I found an older example. This occurred in the 10.3 branch before the mariadb-10.3.20 release was tagged:
This time it crashed ‘properly’ without trying to start further storage engines, and without timeout. But, we still do not know whether TokuDB caused the same failure that was reported by d'd on ARM. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-12-14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
d'd, thank you for the screenshots. Unfortunately, I do not see any MariaDB server error log output among them. If the server crashes before writing any log, then that crash should be different from the TokuDB-related crash that we occasionally see on our CI system. That one will hopefully be addressed by disabling a check. d'd, what happens if you try to start up the server manually, by invoking /usr/sbin/mysqld? I tested the following steps with the default settings of the mariadb-server-10.3 package (version 10.3.20-1) on my Debian GNU/Linux AMD64 system:
and then in gdb, execute the following:
Note: if the server startup does not fail, you can initiate shutdown from another connection, or send SIGQUIT to the process, which is usually mapped to ctrl-\. Another option would be to run
In any case, please try to attach the output as text, not as screenshots. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2019-12-14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
d'd, note the line in your logs
there are some hints (e.g. here) that this relates to the old kernel, SELinux, and NoNewPrivileges line in the mariadb.service file. In that case you should be able to start mysqld directly, but not via systemd unless you upgrade your kernel or somehow fix the service file. |