systemdで困ったときのトラブルシュート

最近涼しくなってきて非常に過ごしやすくなってきましたね。
天高く馬肥ゆる秋、といいますが僕は夏から絶賛増量中です。　ダイエットするぞするぞ…！

さて、今回はsystemdについての記事です。
サーバーはある意味、秋の天気と似ていますよね。
安定していたと思ったサーバーでも急に問題やら障害を起こしたり、ということがたびたびあります。
インフラエンジニアなら日常のメンテナンスで日々サーバーの状態を是正していくのが基本ですが、思わぬ落とし穴に引っかかってサーバーダウン、そのままダウンタイムがずるずると伸びる…なんて可能性もあります。

そんな時に個人的に助けられたコマンドと障害対応パターンを今回はご紹介します。
サーバーを落としてしまった場合でも焦らず、落ち着いて対応しましょう！

救われたコマンド

• /etc/systemd/system/
• /usr/lib/systemd/system

のどちらかの配下に置かれるため、探すのに一苦労だったりします。
そういった場合に役立つコマンドです。

とくに障害が起きてテンパってしまうと人間何をやらかすかわかりませんからね…。
できる限りその場しのぎでコマンド入力をするのは避けるようにしたいところです。

この systemctl cat は副作用なしで安全に、スピーディーにUnitファイルを確認することができます。

やらかした経緯とトラブルシュートの考え方

やらかした経緯

前任者が構築した開発用Webサーバーを最適化をしているときの話です。

MySQLのコンフィグ( my.cnf )を書き換え、 systemctl restart mysql でMySQLを再起動しようとしたとき、なぜか起動に失敗するんですよね…。
コンフィグの記述も間違いはないのに…。
コンフィグを書き換え前のものに切り戻しして再度MySQLを再起動…。　これも失敗します。

そういう場合はsystemdの各Unitの起動シーケンスのログを確認しますよね。
journalctl -xe でチェックしましたが、MySQL再起動時の部分では原因となる部分のログが見当たりませんでした。
確かにMySQLは起動を試みていますが、その後すぐ Status (1) Exited となっており、何が原因で落ちているのか不明でした。

次に確認するポイントはミドルウェア自体が書き出すログです。
MySQLのコンフィグ上で /var/log/mysql/ 内部に書き込むように設定されていたため、そちらを参照します。
ところが、ログファイルである、 error.log の中身は空っぽで何も確認できませんでした。

トラブルシュートの考え方

結論ですが、Unitファイルの中にある、ExecStartの部分をそのままシェルで実行してみる、というアクションが正解でした。
Unitファイルを素早く確認するため、前述の systemctl cat mysqld を利用し、Unitファイル内のExecStartを探しました。
Unitファイル中のExecStartと記述される部分はサービスの起動コマンドです。
『Systemd上でエラーログが確認できない状態でも、シェルになら何か返されるかも？』というあてずっぽうな考え方でしたが、実際に実行すると、シェルにエラーログが返されました。

原因はMySQLのログに対する権限不足で起動に失敗していた…　というしょうもない理由です。
おそらく前任者が何らかのタイミングで所有ユーザーとパーミッションの設定をミスしていたのでしょう。
error.logに何も書き込まれない理由もこれでうなずけます。

トラブルシュートの考え方、それはログや出力をひたすら追い、理解し、試すことにあると個人的には思っています。
もちろん、サーバーが落ちた・うまくパフォーマンスを生かしきれない・サーバーの負荷が大きい、といった事象も同じですよね。
当たり前のことですが、基本に忠実に対応していきましょう。

おわりに

環境を再現してSSを撮りながらブログを書きたかったんですが、なぜか再現ができず…。
最後まで謎に包まれたトラブルシューティングでした。

もっとも、本番環境ではなく、社内の開発環境でよかったです。
こんなしょうもないミス、本番環境でやるのはインフラエンジニアとして許されませんからね。😂😂😂😂

とはいえ、今まで経験したことがない事象を解決できたのはまたとない機会と感じました。
他人が構築したサーバーについては今まで以上に慎重に観察しながら触っていこうと思います。