Почему Мариадб продолжает умирать? Как мне это остановить?

Я использую MariaDB 10.0.23-0 на Ubuntu 15.10 в качестве сервера 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-03-26 22:52:42 ПО ВОСТОЧНОМУ ВРЕМЕНИ; 26 лет назад
  Процесс: 8707 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER (код = выход, статус = 0 / УСПЕХ)
  Процесс: 8706 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (код = выход, статус = 0 / УСПЕХ)
 Основной PID: 8707 (код = выход, статус = 0 / УСПЕХ)

26 марта 22:52:39 boggan systemd[1]: mariadb.service: истекло время ожидания начала операции. Нагрузочный.
26 марта 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Примечание] /usr/sbin/mysqld: обычное отключение
26 марта 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Примечание] Планировщик событий: очистка очереди. 0 событий
26 марта 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140104920164096 [Примечание] InnoDB: FTS оптимизирует выход из потока.
26 марта 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [Примечание] InnoDB: начало выключения...
26 марта 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [Примечание] InnoDB: завершение работы завершено; порядковый номер журнала 3336953
26 марта 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [Примечание] /usr/sbin/mysqld: завершение работы завершено
26 марта 22:52:42 boggan systemd[1]: Не удалось запустить сервер базы данных MariaDB.
26 марта 22:52:42 boggan systemd[1]: mariadb.service: устройство вошло в сбойное состояние.
26 марта 22:52:42 boggan systemd[1]: mariadb.service: не удалось с результатом 'timeout'

Первый systemd линия есть своего рода "хорошо дух". Я знаю, что время истекло. Второй systemd, после mysqld Линии немного загадочные, потому что они действительно начинаются. Приложение (в частности, OwnCloud), которое зависит от базы данных, работает нормально... в течение минуты и изменения, которое выполняет MariaDB.

Другой вопрос предложил использовать time /etc/init.d/mysql start чтобы определить, сколько времени это заняло. Я запускал его несколько раз, чтобы подтвердить время - это несколько секунд по обе стороны от 90-х каждый раз.

Другие исследования заставляют меня проверять права доступа к файлам, и это нормально... кроме того, он временно запускается. Я ткнул и подтолкнул в меру своих (по общему признанию, ограниченных, когда дело доходит до Linux) способностей, и я не добился никакого прогресса.

Итак, вопрос в том... Как мне заставить сервис MariaDB оставаться на ногах?

Как дополнительная складка, после написания этого вопроса я оставил машину включенной и работающей. Я вернулся к нему через неделю (я не трогал его между). Используя точно такую ​​же команду, sudo /etc/init.d/mysql start, Был успешен. Демон mysql запустился и побежал; он вернулся с [ ok ] отчет. Ради эксперимента я перезагрузился и вернулся к тому, с чего начал.

В случае, если это имеет значение, выход journalctl -xe является:

Апр 02 23:51:44 boggan systemd[1]: остановлен. Заранее прочитайте необходимые файлы. - Тема: модуль ureadahead.service завершил работу - Определено: По: systemd - Поддержка: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Модуль ureadahead.service завершен Выключение. Апр 02 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [Примечание] InnoDB: Онлайн DDL: начало 02 апреля 23:51:55 boggan mysqld [2645]: 2016-04- 02 23:51:55 140386161068800 [Примечание] InnoDB: онлайн DDL: начать чтение кластеризованного индекса таблицы и создать временные файлы 02 апреля 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Примечание] InnoDB: онлайн DDL: конец чтения кластерного индекса таблицы и создание временных файлов 2 апреля 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Примечание] InnoDB: онлайн DDL: Завершено 02 апреля 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Примечание] InnoDB: Онлайн DDL: Завершено 02 апреля 23:52:06 boggan dbus[713]: [ система] Не удалось активировать службу 'org.bluez': истекло время ожидания 02 апреля 23:52:37 boggan systemd[1]: mariadb.service: истекло время ожидания начала операции. Нагрузочный. Апр 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [Примечание] /usr/sbin/mysqld: нормальное завершение работы 02 апреля 23:52:37 ядро ​​boggan: аудит: тип = 1400 аудит (1459655557.935:31): apparmor="DENIED" операция = "sendmsg" профиль ="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2645 comm="mysqld" required_mask="w" denied_mask="w" fsuid=122 ouid=0 апр. 02 23:52:37 аудит boggan [2645]: операция AVC apparmor="DENIED"="sendmsg" profile="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2645 comm="mysqld" required_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0 апр. 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23: 52:37 140386097400576 [Примечание] Планировщик событий: очистка очереди. 0 событий апр. 02 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140385225500416 [Примечание] InnoDB: FTS оптимизирует выход из потока. 02 апреля, 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Примечание] InnoDB: запуск выключения... 02 апреля 23:52:39 boggan mysqld[2645]: 2016-04-02 23:52:39 140386097400576 [Примечание] InnoDB: завершение работы завершено; порядковый номер журнала 3360838 02 апреля, 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Примечание] /usr/sbin/mysqld: завершение работы 02 апреля, 23:52:39 ядро ​​boggan: аудит: тип = 1400 аудит (1459655559.419:32): apparmor="DENIED" операция = "sendmsg" профиль = "/ usr / sbin / mysqld" имя ="/run/systemd/notify" pid=2877 comm="mysqld" request_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 апр. 02 23:52:39 boggan аудит [2877]: AVC apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2877 comm="mysqld" required_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 апр. 02 23:52:39 boggan аудит [2645]: AVC apparmor= Операция "ОТКАЗ" = "sendmsg" profile ="/usr/sbin/mysqld" name="/run/systemd/notify" pid=2645 comm="mysqld" required_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 апреля 02 23:52:39 boggan kernel: аудит: тип = 1400 аудит (1459655559.419: 33): apparmor = операция "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify "pid = 2645 comm =" mysqld "required_ma sk = "w" denied_mask = "w" fsuid = 122 ouid = 0 апр. 02 23:52:39 boggan systemd [1]: не удалось запустить сервер базы данных MariaDB. - Тема: сбой службы mariadb.service - Определено: по: systemd - Поддержка: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Ошибка блока mariadb.service. - Результат не удался. Апр 02 23:52:39 boggan systemd[1]: mariadb.service: Устройство вошло в состояние отказа. Апр 02 23:52:39 boggan systemd[1]: mariadb.service: Не удалось с результатом 'timeout'. 

4 ответа

Решение

apparmor был виновником. Несмотря на содержание /etc/apparmor.d/usr.sbin.mysqld быть просто комментариями и утверждать, что это было там, чтобы apparmor не подавился MariaDB, это именно то, что происходило.

AppArmor и MySQL в блоге Oracle предоставили то, что мне нужно, чтобы понять, что происходит.

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, который, кажется, эквивалентен решению плутократа)

$ sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.

Я также отключил mysqld-akonadi и mysqld-digikam.

Перезарядки аппармора было недостаточно, поэтому мне пришлось перезагрузиться, и mariadb запустилась на отлично.

Мне пришлось полностью отключить MySQL в Apparmor. Жалоба ничего не сделает для меня. Так...

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

Затем перезагрузите

Простое решение - удалить неизвестные профили AppArmor

root@dev:/server# aa-remove-unknown Удаление '/snap/core/6350/usr/lib/snapd/snap-confine' Удаление '/usr/sbin/mysqld'

Оно работает!

Другие вопросы по тегам