web-dev-qa-db-ja.com

なぜmariadbは死に続けるのですか?どうすれば止められますか?

Ubuntu 15.10でLAMPサーバーとしてMariaDB 10.0.23-0を実行しています。 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;有効、ベンダープリセット:有効)
ドロップイン:/ etc/systemd/system/mariadb.service.d 
└─migrated-from-my.cnf-settings.conf
アクティブ:失敗(結果:タイムアウト)2016年3月26日土22 :52:42 EDT; 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(code = exited、status = 0/SUCCESS)
 
 Mar 26 22:52:39 boggan systemd [1]:mariadb.service:開始操作がタイムアウトしました。終了。
 Mar 26 22:52:39 boggan mysqld [8707]:2016-03-26 22:52:39 140105856617216 [注]/usr/sbin/mysqld:通常シャットダウン
 Mar 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:シャットダウンの開始... 
 Mar 26 22:52:42 boggan mysqld [8707]:2016- 03-26 22:52:42 140105856617216 [注] InnoDB:シャットダウンが完了しました。ログシーケンス番号3336953 
 Mar 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:結果 'timeout'` 
で失敗しました

そこの最初のsystemd行は、一種の「まあまあ」です。私はそれがタイムアウトしたことを知っています。 systemd行の後の2番目のmysqldは、実際にはdoesdoes(---)であるため、少し不可解です。データベースに依存するアプリケーション(具体的には、OwnCloud)は正常に動作します... MariaDBが稼働しているわずかな変更に対して。

別の質問time /etc/init.d/mysql startを使用して、所要時間を決定することを提案しました。時間を確認するために繰り返し実行しました。毎回90年代のどちらかの側で数秒です。

他の研究では、ファイルのアクセス許可を確認することになりましたが、それは問題ありません...さらに、一時的にdoes起動します。私は自分の(Linuxに関しては確かに制限されている)能力を最大限に活用し、突進しましたが、まだ前進していません。

だから、質問は...MariaDBサービスを稼働させるにはどうすればよいですか?

追加のしわとして、この質問を書いた後、マシンを稼働させたままにしました。 1週間後に戻ってきました(その間は触れませんでした)。まったく同じコマンドSudo /etc/init.d/mysql startを使用すると成功しました。 mysqlデーモンが起動して実行されました。 [ ok ]レポートが返されました。実験のためにリブートしましたが、最初に戻ったところです。

重要な場合、journalctl -xeの出力は次のとおりです。

 4月2日23:51:44 boggan systemd [1]:事前に必要なファイルの読み取りを停止しました。 -By:systemd 
-サポート:http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-ユニットureadahead.serviceが終了しました
 Apr 02 23:51:55 boggan mysqld [2645]:2016-04-02 23:51:55 140386161068800 [注] InnoDB:オンラインDDL:Start 
 Apr 02 23: 51:55 boggan mysqld [2645]:2016-04-02 23:51:55 140386161068800 [注] InnoDB:オンラインDDL:テーブルのクラスター化インデックスの読み取りを開始し、一時ファイルを作成します
 Apr 02 23:51: 55 boggan mysqld [2645]:2016-04-02 23:51:55 140386161068800 [注] InnoDB:オンラインDDL:テーブルのクラスター化インデックスの読み取り終了と一時ファイルの作成
 Apr 02 23:51:55 boggan mysqld [2645]:2016-04-02 23:51:55 140386161068800 [注] InnoDB:オンラインDDL:完了
 Apr 02 23:51:55 boggan mysqld [2645]:2016-04-02 23 :51:55 140386161068 800 [注] InnoDB:オンラインDDL:完了
 Apr 02 23:52:06 boggan dbus [713]:[システム]サービス 'org.bluez'の有効化に失敗しました:タイムアウト
 Apr 02 23:52:37 boggan systemd [1]:mariadb.service:開始操作がタイムアウトしました。終了。
 Apr 02 23:52:37 boggan mysqld [2645]:2016-04-02 23:52:37 140386097400576 [注]/usr/sbin/mysqld:通常のシャットダウン
 Apr 02 23:52:37 boggan kernel:audit:type = 1400 audit(1459655557.935:31):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 
 Apr 02 23:52:37 boggan audit [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 
 Apr 02 23:52:37 boggan mysqld [2645]:2016-04-02 23:52:37 140386097400576 [注]イベントスケジューラ:キューを削除します。 0イベント
 Apr 02 23:52:37 boggan mysqld [2645]:2016-04-02 23:52:37 140385225500416 [注] InnoDB:FTS最適化スレッド終了。
 Apr 02 23: 52:37 boggan mysqld [2645]:2016-04-02 23:52:37 140386097400576 [注] InnoDB:シャットダウンを開始しています... 
 Apr 02 23:52:39 boggan mysqld [2645]:2016- 04-02 23:52:39 140386097400576 [注] InnoDB:シャットダウンが完了しました。ログシーケンス番号3360838 
 Apr 02 23:52:39 boggan mysqld [2645]:2016-04-02 23:52:39 140386097400576 [注]/usr/sbin/mysqld:シャットダウン完了
 4月02日23:52:39 bogganカーネル:監査:type = 1400 audit(1459655559.419:32):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 
 Apr 02 23:52:39 boggan audit [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 
 Apr 02 23:52:39 boggan audit [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 
 Apr 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" requested_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 
 Apr 02 23:52:39 boggan systemd [1]:MariaDBデータベースサーバーの起動に失敗しました。
-件名:ユニットmariadb.serviceが失敗しました
-定義元:systemd 
-サポート:http://lists.freedesktop.org/mailman/listinfo/systemd -devel 
-
-unit mariadb.service has failed。
-
-結果は失敗しました。
 Apr 02 23 :52:39 boggan systemd [1]:mariadb.service:ユニットが障害状態になりました。
 Apr 02 23:52:39 boggan systemd [1]:mariadb.service:結果 'timeout'で失敗しました。
25
T.J.L.

防具が犯人でした。 /etc/apparmor.d/usr.sbin.mysqldの内容はコメントにすぎず、甲armがMariaDBに詰まらないようにそこにあると主張しているにもかかわらず、まさにそれが起こっていました。

AppArmorおよびMySQL Oracleブログで、何が起こっているのかを理解するために必要なものが提供されました。

Sudo aa-statusは、apparmorが何をしているかを示します。実際に強制されたポリシーを持っているものと、単に文句を言うように設定されているもの。

Sudo apt-get install apparmor-utilsは、次のような、装甲プロファイルを扱いやすくするいくつかのコマンドを追加します...

Sudo aa-complain /usr/sbin/mysqldは、プロファイルを「強制」から不満に変えます。 (aa-enforceは元に戻します。)

それが完了すると、Sudo service apparmor reloadはapparmorを再起動し、出来上がります... Sudo /etc/init.d/mysql startは動作し、サーバーは稼働し続けます。

24
T.J.L.

Mysqlからmariadbにアップグレードした後も、まったく同じ問題が発生しました。奇妙なことは、サービスのmysqlの起動が成功したのに対し、サービスのmariadbの起動がタイムアウトで(システムの起動時または手動で)失敗したことです。

T.J.L。による説明は正しいが、修正は私にとってはうまくいかなかった。

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

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

だから私はプロファイルを無効にしました(plutocratのソリューションと同等と思われるaa-disableで)

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

Mysqld-akonadiとmysqld-digikamも無効にしました。

装甲のリロードでは十分ではなかったので、rebootを実行する必要があり、mariadbは完全に正常に起動しました。

27
ChrisAga

Apparmorでmysqlを完全に無効にする必要がありました。 aa-complainは私には何もしません。そう ...

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

その後、再起動します

14
plutocrat

簡単な解決策は、不明なAppArmorプロファイルを削除することです。

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

できます!

1
Loc Luong

3年後、あなたのソリューションはまだ有効です!ありがとう!

0
Andrea