Mengapa mariadb terus mati? Bagaimana saya menghentikannya?

25

Saya menjalankan MariaDB 10.0.23-0 di Ubuntu 15.10 sebagai server LAMP. Menjalankan sudo /etc/init.d/mysql starthasil dalam:

Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

Output dari systemctl status mariadb.serviceadalah:

● mariadb.service - server database MariaDB
   Dimuat: dimuat (/lib/systemd/system/mariadb.service; diaktifkan; preset vendor: diaktifkan)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Aktif: gagal (Hasil: batas waktu) sejak Sab 2016-03-26 22:52:42 EDT; 26s lalu
  Proses: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (kode = keluar, status = 0 / SUKSES)
  Proses: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (kode = keluar, status = 0 / SUKSES)
 PID Utama: 8707 (kode = keluar, status = 0 / SUKSES)

Mar 26 22:52:39 boggan systemd [1]: mariadb.service: Mulai waktu operasi habis. Mengakhiri.
26 Maret 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Catatan] / usr / sbin / mysqld: Shutdown normal
26 Mar 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Catatan] Penjadwal Acara: Membersihkan antrian. 0 acara
26 Maret 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Catatan] InnoDB: FTS mengoptimalkan keluarnya utas.
26 Maret 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Catatan] InnoDB: Mulai shutdown ...
26 Maret 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Catatan] InnoDB: Shutdown selesai; nomor urut log 3336953
26 Maret 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Catatan] / usr / sbin / mysqld: Shutdown complete
26 Mar 22:52:42 boggan systemd [1]: Gagal memulai server database MariaDB.
26 Mar 22:52:42 boggan systemd [1]: mariadb.service: Unit masuk ke kondisi gagal
26 Mar 22:52:42 boggan systemd [1]: mariadb.service: Gagal dengan hasil 'timeout'`

Baris pertama systemdada semacam "well duh". Saya tahu waktunya habis. Yang kedua systemd, setelah mysqldbaris agak membingungkan, karena memang mulai. Aplikasi (OwnCloud, khususnya) yang bergantung pada basis data berfungsi normal ... untuk menit-dan-perubahan yang dijalankan MariaDB.

Pertanyaan lain yang disarankan digunakan time /etc/init.d/mysql startuntuk menentukan berapa lama. Saya menjalankannya berulang kali untuk mengkonfirmasi waktu - beberapa detik di setiap sisi 90-an setiap kali.

Penelitian lain membawa saya untuk memeriksa hak akses file, yang baik-baik saja ... selain itu, tidak start up, sementara. Saya telah menyodok dan mendorong kemampuan saya (diakui terbatas dalam hal Linux), dan saya belum membuat kemajuan.

Jadi, pertanyaannya adalah ... Bagaimana cara mendapatkan layanan MariaDB agar tetap terjaga?

Sebagai kerutan tambahan, setelah menulis pertanyaan ini, saya meninggalkan mesin dan berjalan. Saya kembali ke sana seminggu kemudian (saya tidak menyentuhnya di antara). Menggunakan perintah yang sama persis sudo /etc/init.d/mysql start,, berhasil. Daemon mysql mulai dan berlari; kembali dengan [ ok ]laporan. Saya memulai ulang demi eksperimen, dan saya kembali ke tempat saya mulai.

Dalam hal ini penting, output dari journalctl -xeadalah:

02 Apr 23:51:44 sistem boggan [1]: Berhenti Membaca file yang diperlukan sebelumnya.
- Subjek: Unit ureadahead.service telah selesai dimatikan
- Didefinisikan-oleh: systemd
- Dukungan: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Unit ureadahead.service telah selesai dimatikan.
02 Apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Catatan] InnoDB: DDL Online: Mulai
02 Apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Catatan] InnoDB: DDL Online: Mulai membaca indeks berkerumun tabel dan membuat file sementara
02 Apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Catatan] InnoDB: DDL Online: Akhir membaca indeks berkerumun tabel dan membuat file-file sementara
02 Apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Catatan] InnoDB: Online DDL: Lengkap
02 Apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Catatan] InnoDB: Online DDL: Lengkap
02 Apr 23:52:06 boggan dbus [713]: [system] Gagal mengaktifkan layanan 'org.bluez': timed out
02 Apr 23:52:37 boggan systemd [1]: mariadb.service: Mulai waktu operasi habis. Mengakhiri.
02 Apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Catatan] / usr / sbin / mysqld: Shutdown normal
02 Apr 23:52:37 kernel boggan: audit: type = 1400 audit (1459655557.935: 31): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / beri tahu "pid = 2645 comm =" mysqld "asked_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:37 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ jalankan / systemd / beri tahu" pid = 2645 comm = " mysqld "asked_mask =" w "ditolak_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Catatan] Penjadwal Acara: Membersihkan antrian. 0 acara
02 Apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Catatan] InnoDB: FTS mengoptimalkan keluarnya utas.
02 Apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Catatan] InnoDB: Mulai shutdown ...
02 Apr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Catatan] InnoDB: Shutdown selesai; nomor urut log 3360838
02 Apr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Catatan] / usr / sbin / mysqld: Shutdown complete
02 Apr 23:52:39 kernel boggan: audit: type = 1400 audit (1459655559.419: 32): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / beri tahu "pid = 2877 comm =" mysqld "asked_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:39 audit boggan [2877]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ jalankan / systemd / beri tahu" pid = 2877 comm = " mysqld "asked_mask =" w "ditolak_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:39 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ jalankan / systemd / beri tahu" pid = 2645 comm = " mysqld "asked_mask =" w "ditolak_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:39 kernel boggan: audit: type = 1400 audit (1459655559.419: 33): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / beri tahu "pid = 2645 comm =" mysqld "asked_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 Apr 23:52:39 sistem boggan [1]: Gagal memulai server database MariaDB.
- Subjek: Unit mariadb.service telah gagal
- Didefinisikan-oleh: systemd
- Dukungan: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Unit mariadb.service telah gagal.
- 
- Hasilnya gagal.
02 Apr 23:52:39 sistem boggan [1]: mariadb.service: Unit masuk ke kondisi gagal.
02 Apr 23:52:39 boggan systemd [1]: mariadb.service: Gagal dengan hasil 'timeout'.

— TJL
sumber

2

The journalctl -xeoutput dipotong, dapat Anda memperbarui ini? Lihat lebih dekat pada apparmor="DENIED"pesan - pesannya (jika apparmor diaktifkan pada OS Anda) karena ini bisa menjadi masalah selama mariadb dimulai.

— tlo

@ juga saya akan ... itu hanya harus menunggu sampai malam ini. Saya tidak memiliki akses ke mesin dari tempat saya berada. Bagaimanapun, saya tidak bisa berfungsi ketika saya duduk di situ, jadi mengapa repot-repot mengaturnya untuk akses jarak jauh. Saya pasti akan melihat ke apparmor juga. Jika diaktifkan, diaktifkan secara default. Saya belum mengubah apa pun yang dipasang oleh sistem, hanya menambahkan barang LAMP.

— TJL

@tlo Output yang diperbarui, dan menambahkan sedikit kerutan pada deskripsi. Alih-alih menggedornya, saya akan pergi selama satu atau dua jam, dan lihat apa yang terjadi ...

— TJL

1

@ juga Terima kasih atas bantuannya. apparmor adalah pelakunya.

— TJL

28

Saya memiliki masalah yang sama setelah memutakhirkan dari mysql ke mariadb. Yang aneh adalah bahwa layanan mariadb mulai gagal pada batas waktu (baik pada boot sistem atau secara manual) sedangkan layanan mysql mulai berhasil.

Penjelasan yang diberikan oleh TJL benar tetapi koreksi tidak berhasil untuk saya.

$ sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

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

Jadi saya menonaktifkan profil (dengan aa-disable yang tampaknya setara dengan solusi plutocrat )

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

Saya menonaktifkan mysqld-akonadi dan mysqld-digikam juga.

Reload apparmor tidak cukup, jadi saya harus reboot dan mariadb mulai dengan baik.

— ChrisAga
sumber

Mengkonfirmasi itu tidak dapat menemukan cara untuk membuatnya berfungsi tanpa me-reboot.

— Meetai.com

Jawaban ini berhasil untuk saya di Kubuntu 18.04.2 LTS. complaindan ... apparmor reload( jawab TJL ) memang tidak cukup.

— Marten Koetsier

25

apparmor adalah pelakunya. Terlepas dari isi /etc/apparmor.d/usr.sbin.mysqldsebagai komentar dan mengklaim bahwa itu ada di sana sehingga aparatur tidak akan tersedak MariaDB, itulah yang sebenarnya terjadi.

AppArmor dan MySQL di blog Oracle menyediakan apa yang saya butuhkan untuk mencari tahu apa yang sedang terjadi.

sudo aa-statusmenunjukkan kepada Anda apa yang dilakukan aparatur; apa yang sebenarnya memiliki kebijakan yang ditegakkan, versus apa yang baru saja diatur untuk mengeluh.

sudo apt-get install apparmor-utils menambahkan beberapa perintah yang membuat profil apparmor lebih mudah untuk ditangani, seperti ...

sudo aa-complain /usr/sbin/mysqldmengubah profil dari "menegakkan" menjadi mengeluh. ( aa-enforcemengembalikannya.)

Setelah selesai, sudo service apparmor reloadrestart aparatur, dan voila ... sudo /etc/init.d/mysql startberfungsi, dan server tetap aktif.

— TJL
sumber

1

Sial, Bung; yang sebenarnya berhasil. Saya agak panik karena ini memengaruhi server produksi kami hingga beberapa jam. Saya bukan ahli sama seperti Anda dan saya mencari di seluruh web untuk berbagai kesalahan dalam file /var/log/mysql/error.log. Terima kasih banyak untuk ini!

— Muqito

1

Sama untuk ku. Saya memutakhirkan dari Ubuntu 14.04 hingga 16.04 dan kehilangan kemampuan untuk menjalankan MySQL. Sekarang berhasil! Terima kasih banyak untuk merinci ini: D. Saya sudah mencari berminggu-minggu!

— Sawtaytoes

Tidak cukup melakukannya untuk saya, tapi terima kasih atas tipnya apparmor-utils. Tiga tahun kemudian saya mendapatkannya ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.

— YetiCGN

14

Saya harus sepenuhnya menonaktifkan mysql di apparmor. Seorang pengeluh tidak akan melakukan apa pun untukku. Jadi ...

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

Kemudian reboot

— orang kaya
sumber

Terima kasih! Ini adalah satu-satunya solusi untuk masalah saya! Saya juga meningkatkan dari mysql ke mariadb

— Thomas Gatt

ini juga yang berhasil bagi saya, terima kasih banyak

— Eman

3

Solusi sederhana adalah menghapus profil AppArmor yang tidak dikenal:

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

Berhasil!

— Loc Luong
sumber

Ini sebenarnya yang perlu saya lakukan untuk membuat semuanya berjalan, jadi terima kasih. Jawaban yang diterima di atas akan memberi saya ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profileapa yang benar, mengingat file hanya terdiri dari komentar. Mungkin dalam versi yang lebih baru dari AppArmor mereka mengaturnya untuk gagal dengan file-file itu, sementara itu bekerja pada 2016.

— YetiCGN

Ini adalah jawaban yang benar (setidaknya tahun 2019). Apa yang terjadi adalah setelah deinstalasi MySql, profil AppArmor untuk /usr/sbin/mysqldmasih dimuat dalam kernel. Menjalankan aa-remove-unknown(atau me-reboot) memecahkan ini.

— zwets