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

25

Я использую 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: Online DDL: начать чтение кластерного индекса таблицы и создать временные файлы
Апр 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Примечание] InnoDB: Online 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: выполнено
Апр 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 = "ОТКАЗ" операция = профиль "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 Богганский аудит [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 = "ОТКЛОНЕНО" операция = "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 аудит [2877]: AVC apparmor = "DENIED" операция = "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 = "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:39 boggan kernel: audit: type = 1400 аудит (1459655559.419: 33): 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: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'.
15.10 mysql timeout mariadb TJL
источник
2
journalctl -xeВыход усекается, вы можете обновить это? apparmor="DENIED"Внимательно посмотрите на сообщения (если apparmor активирован в вашей ОС), так как это может быть проблемой при запуске mariadb.
до
@ Я буду ... просто подождать до вечера. У меня нет доступа к машине, где я нахожусь. В конце концов, я не мог заставить его работать, когда сидел за ним, так зачем пытаться настроить его для удаленного доступа. Я определенно посмотрю на apparmor тоже. Если он был активирован, он был активирован по умолчанию. Я ничего не менял, установленный системой, просто добавил LAMP.
TJL
@tlo Обновил вывод и добавил немного морщинки в описание. Вместо того, чтобы стучать по нему, я уйду на час или два и посмотрю, что произойдет ...
TJL
1
@tlo Спасибо за помощь. apparmor был виновником.
TJL

Ответы:

28

У меня возникла та же проблема после обновления с 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 запустилась на отлично.

ChrisAga
источник
Подтверждение того, что не удалось найти способ заставить его работать без перезагрузки.
Meetai.com
Этот ответ работал для меня на Kubuntu 18.04.2 LTS. complainи ... apparmor reload( ответ TJL ) действительно было недостаточно.
Мартен Коецер
25

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работает, и сервер остается в рабочем состоянии .

TJL
источник
1
Святой дерьмо чувак; это действительно сработало. У меня была небольшая паника, так как это затронуло наш производственный сервер, оставив его на пару часов. Я не такой эксперт, как вы, и я искал в Интернете различные ошибки в файле /var/log/mysql/error.log. Спасибо вам за это!
Мукито
1
Мне то же. Я обновил Ubuntu 14.04 до 16.04 и потерял способность запускать MySQL. Теперь это работает! Большое спасибо за детализацию этого: D. Я искал недели!
Sawtaytoes
Не совсем так для меня, но спасибо за совет apparmor-utils. Через три года я получаю ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.
YetiCGN
14

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

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

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

плутократ
источник
Спасибо! Это было единственное решение моей проблемы! Я также перешел с mysql на mariadb
Томас Гатт
это было то, что работало и для меня, большое спасибо
Эман
3

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

aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'

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

Лок Луонг
источник
Это было на самом деле то, что мне нужно было сделать, чтобы все заработало, так что спасибо. Принятый ответ выше даст мне, ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profileкак это точно, учитывая, что файл состоит только из комментариев. Возможно, в более новой версии AppArmor они установили сбой при работе с этими файлами, пока он работал в 2016 году.
YetiCGN
Это правильный ответ (по крайней мере, в 2019 году). Что происходит, так это то, что после деинсталляции MySql профиль AppArmor для /usr/sbin/mysqldпо-прежнему загружается в ядро. Запуск aa-remove-unknown(или перезагрузка) решает эту проблему.
zwets