为什么mariadb会继续死亡？ 我怎么阻止它？
我在Ubuntu 15.10上运行MariaDB 10.0.23-0作为LAMP服务器。 运行sudo /etc/init.d/mysql start导致：
Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
systemctl status mariadb.service的输出是：
●mariadb.service - MariaDB数据库服务器
已加载：已加载（/lib/systemd/system/mariadb.service;已启用;供应商预设：已启用）
Drop-In：/etc/systemd/system/mariadb.service.d
└─migrated从 - my.cnf中，settings.conf
活跃：自2016年6月21日星期六22:52:42以来失败（结果：超时）; 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（代码=退出，状态= 0 /成功）
3月26日22:52:39 boggan systemd [1]：mariadb.service：开始操作超时。 终止。
3月26日22:52:39 boggan mysqld [8707]：2016-03-26 22:52:39 140105856617216 [注意] / usr / sbin / mysqld：正常关机
3月26日22:52:39 boggan mysqld [8707]：2016-03-26 22:52:39 140105856617216 [注意]事件调度程序：清除队列。 0个事件
3月26日22:52:39 boggan mysqld [8707]：2016-03-26 22:52:39 140104920164096 [注意] InnoDB：FTS优化线程退出。
3月26日22:52:39 boggan mysqld [8707]：2016-03-26 22:52:39 140105856617216 [注意] InnoDB：开始关机...
3月26日22:52:42 boggan mysqld [8707]：2016-03-26 22:52:42 140105856617216 [注意] InnoDB：关闭完成; 日志序列号3336953
3月26日22:52:42 boggan mysqld [8707]：2016-03-26 22:52:42 140105856617216 [注意] / usr / sbin / mysqld：关机完成
3月26日22:52:42 boggan systemd [1]：无法启动MariaDB数据库服务器。
3月26日22:52:42 boggan systemd [1]：mariadb.service：单位进入失败状态。
3月26日22:52:42 boggan systemd [1]：mariadb.service：结果'超时'失败
第一个systemd线有一种“井”。 我知道它超时了。 第二个systemd ，在mysqld之后有点神秘，因为它确实开始了。 依赖于数据库的应用程序（特别是OwnCloud）正常工作…对于MariaDB启动的分钟和更改。
建议使用time /etc/init.d/mysql start 另一个问题 time /etc/init.d/mysql start确定它需要多长时间。 我反复跑来确认时间 – 每次90秒左右几秒钟。
其他研究让我检查文件权限，这很好……此外，它确实启动，暂时。 我已经戳了戳并且向我最好的（在Linux方面确实有限）能力，我没有取得任何进展。
所以，问题是…… 我如何让MariaDB服务保持稳定？
作为一个额外的皱纹，在写完这个问题之后，我让机器运转起来。 一周后我回来了（我之间没有碰过）。 使用完全相同的命令， sudo /etc/init.d/mysql start ，成功了。 mysql守护进程启动并运行; 它带回了一个[ ok ]报告。 我重新启动了实验，我回到了我开始的地方。
如果重要， journalctl -xe的输出是：
4月02日23:51:44 boggan systemd [1]：已停止提前读取所需文件。 - 主题：单位ureadahead.service已完成关闭 - 定义者：systemd - 支持：http：//lists.freedesktop.org/mailman/listinfo/systemd-devel - - 单位ureadahead.service已完成关闭。 4月02日23:51:55 boggan mysqld [2645]：2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：开始 4月02日23:51:55 boggan mysqld [2645]：2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：开始读取表的聚簇索引并创建临时文件 4月02日23:51:55 boggan mysqld [2645]：2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：结束读取表的聚簇索引并创建临时文件 4月02日23:51:55 boggan mysqld [2645]：2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：已完成 4月02日23:51:55 boggan mysqld [2645]：2016-04-02 23:51:55 140386161068800 [注意] InnoDB：在线DDL：已完成 4月02日23:52:06 boggan dbus [713]：[system]无法激活服务'org.bluez'：超时 4月02日23:52:37 boggan systemd [1]：mariadb.service：开始操作超时。 终止。 4月02日23:52:37 boggan mysqld [2645]：2016-04-02 23:52:37 140386097400576 [注意] / usr / sbin / mysqld：正常关机 4月02日23:52:37 boggan kernel：audit：type = 1400 audit（1459655557.935：31）：apparmor =“DENIED”operation =“sendmsg”profile =“/ usr / sbin / mysqld”name =“/ run / systemd /通知“pid = 2645 comm =”mysqld“requested_mask =”w“denied_mask =”w“fsuid = 122 ouid = 0 4月2日23:52:37 boggan审计[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 4月02日23:52:37 boggan mysqld [2645]：2016-04-02 23:52:37 140386097400576 [注意]事件调度程序：清除队列。 0个事件 4月02日23:52:37 boggan mysqld [2645]：2016-04-02 23:52:37 140385225500416 [注意] InnoDB：FTS优化线程退出。 4月02日23:52:37 boggan mysqld [2645]：2016-04-02 23:52:37 140386097400576 [注意] InnoDB：开始关机... 4月02日23:52:39 boggan mysqld [2645]：2016-04-02 23:52:39 140386097400576 [注意] InnoDB：关机完成; 日志序列号3360838 4月02日23:52:39 boggan mysqld [2645]：2016-04-02 23:52:39 140386097400576 [注意] / usr / sbin / mysqld：关机完成 4月02日23:52:39 boggan kernel：audit：type = 1400 audit（1459655559.419：32）：apparmor =“DENIED”operation =“sendmsg”profile =“/ usr / sbin / mysqld”name =“/ run / systemd /通知“pid = 2877 comm =”mysqld“requested_mask =”w“denied_mask =”w“fsuid = 122 ouid = 0 4月02日23:52:39 boggan审计[2877]：AVC 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 4月2日23:52:39 boggan审计[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 4月02日23:52:39 boggan kernel：audit：type = 1400 audit（1459655559.419：33）：apparmor =“DENIED”operation =“sendmsg”profile =“/ usr / sbin / mysqld”name =“/ run / systemd /通知“pid = 2645 comm =”mysqld“requested_mask =”w“denied_mask =”w“fsuid = 122 ouid = 0 4月02日23:52:39 boggan systemd [1]：无法启动MariaDB数据库服务器。 - 主题：单位mariadb.service失败 - 定义者：systemd - 支持：http：//lists.freedesktop.org/mailman/listinfo/systemd-devel - - 单位mariadb.service失败了。 - - 结果失败了。 4月02日23:52:39 boggan systemd [1]：mariadb.service：单位进入失败状态。 4月02日23:52:39 boggan systemd [1]：mariadb.service：结果'超时'失败。
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将配置文件从“强制执行”变为抱怨。 （ aa-enforce将其转回。）
一旦完成， sudo service apparmor reload重新启动apparmor，瞧… sudo /etc/init.d/mysql start工作，服务器保持运行状态。
从mysql升级到mariadb之后我遇到了同样的问题。 奇怪的是服务mariadb启动失败超时（无论是在系统启动还是手动），而服务mysql启动成功。
TJL给出的解释是正确的，但修正对我不起作用。
$ 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，这似乎相当于plutocrat的解决方案）
$ sudo aa-disable /usr/sbin/mysqld Disabling /usr/sbin/mysqld.
我也禁用了mysqld-akonadi和mysqld-digikam。
apparmor重新加载是不够的，所以我不得不重启并且mariadb开始非常好。
我不得不在apparmor中完全禁用mysql。 抱怨不会对我做任何事情。 所以……
ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
然后重启