Чому мариадб продовжує вмирати? Як це зупинити?

Я запускаю 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
           └─ переміщено-з-my.cnf-settings.conf
   Активний: не вдалося (Результат: таймаут) з сб. 2016-03-26 22:52:42 EDT; 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, було успішним. Демон-мискл почався і біг; він повернувся з [ 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: кінець читання кластерного індексу таблиці та створення тимчасових файлів
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 ядро: аудит: type = 1400 аудит (1459655557.935: 31): apparmor = "DENIED" операція = "sendmsg" профіль = "/ usr / sbin / mysqld" name = "/ run / systemd / сповістити "pid = 2645 comm =" mysqld "просити_mask =" w "відмовлено_mask =" w "fsuid = 122 ouid = 0
02 квітня 23:52:37 boggan audit [2645]: AVC apparmor = "DENIED" Operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "upit_mask =" w "відмовлено_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 kernel: audit: type = 1400 audit (1459655559.419: 32): apparmor = "DENIED" Operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / сповістити "pid = 2877 comm =" mysqld "просити_mask =" w "відмовлено_mask =" w "fsuid = 122 ouid = 0
02 квітня 23:52:39 boggan audit [2877]: AVC apparmor = "DENIED" Operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2877 comm = " mysqld "upit_mask =" w "відмовлено_mask =" w "fsuid = 122 ouid = 0
02 квітня 23:52:39 boggan audit [2645]: AVC apparmor = "DENIED" Operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "upit_mask =" w "відмовлено_mask =" w "fsuid = 122 ouid = 0
02 квітня 23:52:39 boggan kernel: audit: type = 1400 audit (1459655559.419: 33): apparmor = "DENIED" Operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify "pid = 2645 comm =" mysqld "upit_mask =" w "відмовлено_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'.

У мене був такий самий випуск після переходу з 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-disabled, який здається еквівалентним рішенням плутократа )

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

Я також відключив mysqld-akonadi та mysqld-digikam.

Перезавантаження програми apparmor було недостатньо, тому мені довелося перезавантажитись, і мариадб почався ідеально.

Винуватець був аппармом. Незважаючи на те, що вміст /etc/apparmor.d/usr.sbin.mysqldє не що інше, як коментарі та стверджуючи, що воно було там, щоб аппарм не задихнувся від MariaDB, саме так і відбувається.

AppArmor та MySQL в блозі Oracle надали те, що мені потрібно, щоб зрозуміти, що відбувається.

sudo aa-statusпоказує вам, що робить апермор; що насправді має насильницьку політику, порівняно з тим, що тільки встановлено для скарги.

sudo apt-get install apparmor-utils додає кілька команд, які полегшують роботу профілів apparmor, наприклад ...

sudo aa-complain /usr/sbin/mysqldперетворює профіль із "примусового", щоб скаржитися. ( aa-enforceповертає його назад.)

Як тільки це буде зроблено, sudo service apparmor reloadперезапускається apparmor і voila ... sudo /etc/init.d/mysql startпрацює, і сервер залишається в режимі роботи.

Мені довелося повністю відключити mysql в apparmor. Аа-скарга нічого не зробить для мене. Так ...

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

Потім перезавантажте

Просте рішення - видалити невідомі профілі AppArmor:

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

Це працює!