logo标签列表

为什么Mariadb一直崩溃？我该如何停止它？

15.10mysqltimeoutmariadb
我在Ubuntu 15.10上运行MariaDB 10.0.23-0作为LAMP服务器。运行sudo /etc/init.d/mysql start会出现以下结果： mariadb.service的工作失败，因为超时时间已经超过。请参考"systemctl status mariadb.service"和"journalctl -xe"获取详细信息。 systemctl status mariadb.service的输出为：
● mariadb.service - MariaDB数据库服务器 已加载：已加载（/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled） Drop-In：/etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf 活动状态：失败（结果：超时）自2016年3月26日22:52:42 EDT以来；26秒前 进程：8707 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER (code=exited, status=0/SUCCESS) 进程：8706 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS) 主PID：8707（code=exited, status=0/SUCCESS）
Mar 26 22:52:39 boggan systemd[1]: mariadb.service：启动操作超时。终止。 Mar 26 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Note] /usr/sbin/mysqld：正常关闭 Mar 26 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Note] 事件调度程序：清除队列。0个事件 Mar 26 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140104920164096 [Note] InnoDB：FTS优化线程退出。 Mar 26 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Note] InnoDB：开始关闭... Mar 26 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [Note] InnoDB：关闭完成；日志序列号3336953 Mar 26 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [Note] /usr/sbin/mysqld：关闭完成 Mar 26 22:52:42 boggan systemd[1]: 无法启动MariaDB数据库服务器。 Mar 26 22:52:42 boggan systemd[1]: mariadb.service：进入失败状态。 Mar 26 22:52:42 boggan systemd[1]: mariadb.service：以结果“超时”失败。
第一行的systemd有点“当然会超时”。我知道它超时了。第二个systemd在mysqld之后的那几行有点令人困惑，因为它实际上是启动了的。一个依赖于数据库的应用程序（具体来说是OwnCloud）正常工作...只能持续一分钟左右，然后MariaDB就会停止。 另一个问题建议使用time /etc/init.d/mysql start来确定启动时间。我多次运行它以确认时间，每次大约在90秒左右。
其他研究让我检查文件权限，权限都没问题...而且它确实会临时启动。我已经尽力去调试了（尽管对Linux的了解有限），但没有取得任何进展。
所以，问题是...如何让MariaDB服务保持运行？

作为额外的细节，写完这个问题后，我让机器保持开启状态并运行。一个星期后我回来（期间没有碰它）。使用完全相同的命令sudo /etc/init.d/mysql start成功了。MySQL守护进程已启动并运行；它返回了一个[ ok ]的报告。为了实验的目的，我重新启动了系统，结果回到了原点。

如果有关系的话，journalctl -xe的输出如下：

Apr 02 23:51:44 boggan systemd[1]: 已停止提前读取所需文件。 -- 主题：单元ureadahead.service已完成关闭 -- 定义者：systemd -- 支持：http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- 单元ureadahead.service已完成关闭。 Apr 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：开始 Apr 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：开始读取表的聚集索引并创建临时文件 Apr 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：结束读取表的聚集索引并创建临时文件 Apr 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：已完成 Apr 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：已完成 Apr 02 23:52:06 boggan dbus[713]: [system] 无法激活服务'org.bluez'：超时 Apr 02 23:52:37 boggan systemd[1]: mariadb.service：启动操作超时。终止。 Apr 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] /usr/sbin/mysqld：正常关闭 Apr 02 23:52:37 boggan kernel: audit：type=1400 audit(1459655557.935:31)：apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2645 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0 Apr 02 23:52:37 boggan audit[2645]: AVC apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2645 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0 Apr 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] 事件调度程序：清除队列。0个事件 Apr 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140385225500416 [注意] InnoDB：FTS优化线程退出。 Apr 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] InnoDB：开始关闭... Apr 02 23:52:39 boggan mysqld[2645]: 2016-04-02 23:52:39 140386097400576 [注意] InnoDB：关闭完成；日志序列号3360838 Apr 02 23:52:39 boggan mysqld[2645]: 2016-04-02 23:52:39 140386097400576 [注意] /usr/sbin/mysqld：关闭完成 Apr 02 23:52:39 boggan kernel: audit：type=1400 audit(1459655559.419:32)：apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2877 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0 Apr 02
2journalctl -xe 的输出被截断了，你能更新一下吗？如果你的操作系统上启用了 apparmor，请仔细查看 apparmor="DENIED" 的消息，因为这可能是 mariadb 启动过程中的一个问题。 - tlo
@tlo 我会的... 只能等到今晚了。我无法在我所在的地方访问那台机器。毕竟，当我坐在机器前时，我无法使其正常运行，那为什么要费心设置远程访问呢。我一定也会研究一下 apparmor。如果它被激活了，那应该是默认激活的。我没有更改系统安装的任何内容，只是添加了 LAMP 的东西。 - T.J.L.
@tlo 更新了输出，并在描述中增加了一点变化。我不打算继续纠结于此，打算离开一两个小时，看看会发生什么... - T.J.L.
1@tlo 感谢你的帮助。apparmor是罪魁祸首。 - T.J.L.
4个回答
我在从mysql升级到mariadb后遇到了相同的问题。 奇怪的是，无论是在系统启动还是手动操作时，mariadb服务都因超时而启动失败，而mysql服务则成功启动。
T.J.L.提供的解释是正确的，但对我来说修正方法并没有起作用。
$ sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

所以我禁用了个人资料（使用aa-disable，这似乎相当于富豪的解决方案）
$ sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.

我也禁用了mysqld-akonadi和mysqld-digikam。
重新加载apparmor不够，所以我不得不重启，mariadb启动得非常顺利。
确认无法找到不重启的方法使其正常工作。 - Meetai.com
这个答案在我使用的Kubuntu 18.04.2 LTS上有效。complain和... apparmor reload（回答者T.J.L.）确实不够。 - Marten Koetsier
apparmor是罪魁祸首。尽管/etc/apparmor.d/usr.sbin.mysqld的内容只有注释，并声称它存在是为了防止apparmor对MariaDB产生影响，但事实上却正是这种情况发生了。
在Oracle博客上找到了AppArmor和MySQL提供的信息，帮助我弄清楚了问题的原因。 sudo aa-status可以显示apparmor正在执行的操作，以及哪些策略被强制执行，哪些只是设置为投诉。
通过sudo apt-get install apparmor-utils安装一些命令，使得处理apparmor配置文件更加方便，例如... sudo aa-complain /usr/sbin/mysqld将配置文件从"enforce"模式切换到投诉模式（aa-enforce则切换回来）。
完成以上步骤后，sudo service apparmor reload重新启动apparmor，然后就可以使用sudo /etc/init.d/mysql start启动服务器并保持运行状态了。
1我也一样。我从Ubuntu 14.04升级到16.04，失去了运行MySQL的能力。现在它可以工作了！非常感谢你详细说明这个问题:D。我已经找了好几个星期了！ - Sawtaytoes
虽然对我来说不太满意，但还是谢谢你提供的apparmor-utils提示。三年后，我遇到了一个错误：ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile。 - YetiCGN
对我来说也没用 - 当我尝试执行aa-complain命令时，我得到了ERROR: /etc/apparmor.d/usr.sbin.mysqld doesn't contain a valid profile for /usr/sbin/mysqld (syntax error?)的错误。这是在一个之前从未安装过mysql或mariadb的系统上进行的干净安装 - 它怎么会变得如此复杂呢？ - Andy
我不得不完全禁用apparmor中的mysql。aa-complain对我来说没有任何作用。所以...
ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

然后重新启动
谢谢！这是我问题的唯一解决方案！我还从mysql升级到了mariadb。 - Thomas Gatt
这也是对我有效的方法，非常感谢。 - Eman
一个简单的解决方案是删除任何未知的AppArmor配置文件。
aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'

它有效！

2这实际上是我需要做的事情，以使事情正常运行，所以谢谢。上面接受的答案会给我返回“ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile”，因为这完全是正确的，因为该文件只包含注释。也许在较新版本的AppArmor中，他们设置了对这些文件的失败处理，而在2016年它仍然有效。 - YetiCGN
2这是正确的答案（至少在2019年）。问题出在卸载 MySql 后，/usr/sbin/mysqld 的 AppArmor 配置文件仍然加载在内核中。运行 aa-remove-unknown 命令（或重新启动）可以解决这个问题。 - zwets
这是真正的解决方案。其他答案对我无效。 - Tofandel
这样做可以解决AppArmor错误，但数据库仍无法启动 - systemctl status mariadb.service 和 journalctl -xe 只显示服务已退出，但没有错误详情。最终我找到了一个名为 /var/log/mysql/error.log 的日志文件，其中有一行写着 InnoDB: Invalid flags 0x4800 in ./ibdata1。卸载和重新安装没有帮助，但最终起作用的是卸载、删除 /var/lib/mysql 目录，重启并重新安装。 - Andy
1我和Andy遇到了同样的问题，但是我找到了更加优雅的解决方法。我使用了aa-remove-unknown命令，将App Armour错误转化为不明确的错误。然后，我卸载了mariadb包，使用命令sudo apt remove mariadb-server mariadb-client。接着，我没有删除/var/lib/mysql目录，而是使用命令sudo apt remove mysql-common --purge，然后重新安装了mariadl-server和mariadb-client。无需重启系统，sudo systemctl start mariadb.service命令就可以正常工作了。除了App Armour之外，我的问题还在于在安装MariaDB之前，我曾经在系统上安装过MySQL。 - Matjaz