前書き
このチュートリアルでは、クラッシュまたはサーバーの再起動後に自動的に再起動するようにシステムサービスを構成する方法を示します。
この例ではMySQLを使用していますが、Nginx、Apache、または独自のアプリケーションなど、サーバーで実行されている他のサービスにこれらの原則を適用できます。
このチュートリアルでは、最も一般的な3つのinitシステムについて説明しているため、必ずディストリビューション用のinitシステムに従ってください。 (多くのディストリビューションは複数のオプションを提供するか、代替のinitシステムをインストールできます。)
-
System Vは古いinitシステムです:
-
Debian 6およびそれ以前
-
Ubuntu 9.04およびそれ以前
-
CentOS 5以前
-
-
Upstart:
-
Ubuntu 9.10からUbuntu 14.10(Ubuntu 14.04を含む)
-
CentOS 6
-
-
systemdは、ここで紹介されている最新のディストリビューションのinitシステムです。
-
Debian 7およびDebian 8
-
Ubuntu 15.04以降
-
CentOS 7
-
Part 2, the reference articleをチェックアウトすることもできます。
バックグラウンド
実行中のLinuxまたはUnixシステムでは、多数のバックグラウンドプロセスがいつでも実行されます。 これらのプロセス(servicesまたはdaemonsとも呼ばれます)は、オペレーティングシステムにネイティブであるか、アプリケーションの一部として実行される場合があります。
オペレーティングシステムサービスの例:
-
リモート接続を許可するsshdデーモン
-
印刷を制御するcupsdデーモン
アプリケーションデーモンの例:
-
httpd/apache2 is a web server service
-
mongodはデータベースデーモンです
これらのサービスは、ウェブサイト、メール、データベース、その他のアプリが常に稼働していることを確認するために継続的に実行されることになっています。
管理者として、Linuxサービスに次のことを求めています。
-
失敗することなく継続的に実行する
-
システムの再起動またはクラッシュ後に自動的に起動します
しかし、これらのサービスが停止し、ウェブサイトやアプリが利用できなくなることがあります。
再起動はさまざまな理由で発生する可能性があります。それは、計画的な再起動、パッチ更新の最後のステップ、予期しないシステム動作の結果などです。 クラッシュとは、プロセスが予期せず停止した場合、またはユーザーまたはアプリケーションの要求に応答しなくなった場合に発生することです。
この記事の目的は、クラッシュまたは再起動した後でも、サービスを再び稼働させることです。
継続的な監視とアラートに代わるものはありませんが、Linuxサービスは、initシステムとも呼ばれるサービス管理デーモンによる処理方法を変更することで、大部分が自己回復することができます。
これを行うための単一の方法はありません。それはすべて、特定のLinuxディストリビューションとそれに付属するサービス管理デーモンに依存します。 多くの一般的なオペレーティングシステムのデフォルトの初期化システムは、上記の概要に示されています。
[。注意]##
Part 2のrunlevelsについて詳しく説明しますが、この記事では、すべてのLinuxシステムに共通の4つの基本的なランレベルがあることを理解するのに役立ちます。
-
0-ランレベル0はシステムのシャットダウンを意味します
-
1-ランレベル1はシングルユーザー、レスキューモードを意味します
-
5-ランレベル5は、マルチユーザー、ネットワーク対応、グラフィカルモードを意味します
-
6-ランレベル6はシステムの再起動用です
一般に、ランレベル2、3、および4は、Linuxがマルチユーザー、ネットワーク対応、テキストモードで起動した状態を意味します。
サービスの自動開始を有効にすると、実際にはランレベルに追加されます。
目標
この2部構成のチュートリアルでは、システムの再起動またはクラッシュ時にLinuxサービスを自動的に開始するように構成する方法を説明します。
このシリーズの第1回では、3つの異なる初期化(初期化)モードでそれを行う方法について簡単に説明します。
-
System V init(クラシックinitとも呼ばれる)
-
新興企業
-
systemd
Part 2では、コマンドを実行した理由と、コマンドが舞台裏でどのように機能するかを説明します。 スタートアップスクリプト、重要なファイル、各initメソッドの構成パラメーターについて説明します。 パート2の多くの議論は理論的に思えるかもしれませんが、基本を理解するための有用な参考資料となります。
パート1では、自動再起動を設定する実際的な側面のみを取り上げます。
前提条件
このチュートリアルに従うには、それぞれに少なくとも1 GBのRAMを搭載した多数のDigitalOceanドロップレットを作成する(または独自のLinuxサーバーを作成する)必要があります。 ドロップレットの作成の詳細については説明しませんが、hereの詳細情報を見つけることができます。
例では異なる分布を使用します。
-
Debian 6 x64(この古いOSはSystem V initシステムのデモに必要です)
-
Ubuntu 14.04 x64(Upstartの場合)
-
CentOS 7 x64(systemd用)
-
各サーバーでsudoユーザーを設定する必要があります。 sudo特権がどのように機能するかを理解するには、このDigitalOceantutorial about enabling sudo accessを参照してください。
Part 2にも同じ設定を使用するため、このチュートリアルのパート1を実行した後は、ドロップレットを保持することをお勧めします。
You should not run any commands, queries, or configurations from this tutorial on a production Linux server.テストの一環としてサービスを中断する予定であり、ライブサーバーが一時的に中断することは望ましくありません。
System Vによるサービスの自動開始
ここで説明した最も古いinitシステムであるSystem V initで議論を始めましょう。
-
Debian 6およびそれ以前
-
Ubuntu 9.04およびそれ以前
-
CentOS 5以前
System Vでは、NginxやMySQLなど、インストールできるほとんどの標準アプリケーションは、デフォルトでstart after rebootになりますが、デフォルトではNOT start after a crashになります。 すでに/etc/init.d
に独自のinitスクリプトが付属しています。
カスタムアプリケーションの場合は、独自の初期化スクリプトを作成し、独自にサービスを自動的に開始できるようにする必要があります。
独自のinitスクリプトを作成することはこの記事の範囲外ですが、必要に応じて、既存のサンプルスクリプトを参照して独自のスクリプトを作成できます。 System Vは、initスクリプトにBashを使用します。
System Vの自動開始チェックリスト
このセクションは、サービスが自動的に開始するように設定されていることを確認するためのクイックリファレンスです。
構成チェックリスト
-
サービスの
/etc/init.d/service
に機能的なBashinitスクリプトがあることを確認してください -
update-rc.d
コマンドを使用してサービスを有効にします(またはCentOSシステムの場合はchkconfig
)。
sudo update-rc.d service enable
-
これにより、次のようなシンボリックリンクが
/etc/rc2.d
に作成されます(NOTはこれを手動で作成します)。
lrwxrwxrwx 1 root root 15 Jul 31 07:09 S02mysql -> ../init.d/service
ディレクトリ/etc/rc3.d
から/etc/rc5.d
へのリンクも表示されることに注意してください。 runlevelsについて説明するときに、これらの数値について詳しく学んでください。
-
/etc/inittab
ファイルの最後に、このサービスのrespawn
行を追加します。 一般的な例を次に示します。
/etc/inittab
id:2345:respawn:/bin/sh /path/to/application/startup
-
サービスを停止してから開始します。
sudo service service stop
sudo service service start
-
サーバーを再起動します。
sudo reboot
Test
これらが機能していることをテストするには、次のことができます。
-
サーバーを再起動し、サービスが起動していることを確認します
-
プロセス番号を検索:
ps -ef | grep service
-
プロセスを強制終了します。
sudo kill -9 process_number
-
5分待ってから、サービスがバックアップされていることを確認します
[[step-1 -—- connecting-to-your-debian-6-droplet]] ==ステップ1— Debian6ドロップレットに接続する
次に、MySQLを使用した実用的な例を見ていきます。
DigitalOceanコントロールパネルから、1 GBのRAMを備えたDebian 6.0 x64ドロップレットを作成します。
ドロップレットが初期化されたら、SSHを使用してサーバーに接続します(WindowsユーザーはPuTTYなどのツールを使用して接続できます)。
ssh sammy@your_server_ip
次の手順では、アカウントにsudo権限があることを前提としています。
[[step-2 -—- installing-mysql]] ==ステップ2—MySQLのインストール
テストサービスとしてMySQLを使用します。 次のコマンドを実行して、MySQLサーバーをインストールします。
sudo apt-get install mysql-server -y
以下に示すようなグラフィカル画面が表示され、新しいルートパスワードを求められます。 それを提供する:
次のプロンプトでパスワードを繰り返します。
ENTER
を押して確認します。
MySQLがインストールされると、行がスクロールします。 インストールが完了したら、次のコマンドを実行してインストールを強化します。
mysql_secure_installation
これにより、現在のルートパスワードが要求されます。 同じパスワードを維持するには、N
を押します。 次に、Y
を押して匿名ユーザーを削除し、リモートrootログインを無効にして、テストデータベースを削除します。 最後に、Y
を押して特権テーブルをリロードします。
これでMySQLのインストールが完了しました。
サービスが実行されているかどうかを確認するには、次のコマンドを実行します。
service mysql status
出力には数行の情報が表示され、そのうちの1行にはMySQLサービスが実行されている時間(稼働時間)が表示されます。
Output/usr/bin/mysqladmin Ver 8.42 Distrib 5.1.73, for debian-linux-gnu on x86_64
. . .
Uptime: 4 days 18 hours 58 min 27 sec
Threads: 1 Questions: 18 Slow queries: 0 Opens: 15 Flush tables: 1 Open tables: 8 Queries per second avg: 0.0.
[[step-3 -—- configuring-mysql-to-auto-start-after-reboot]] ==ステップ3—再起動後に自動起動するようにMySQLを設定する
デフォルトでは、MySQLは再起動後に起動するようにすでに設定されています。
/etc/rc2.d
ディレクトリにあるMySQLのinitスクリプトへのこのシンボリックリンクが表示されます。 NOTはこれらのシンボリックリンクを手動で作成する必要があることに注意してください。 update-rc.d
コマンドを使用して、サービスを有効または無効にします。
ls -l /etc/rc2.d
Outputlrwxrwxrwx 1 root root 15 Jul 31 07:09 S02mysql -> ../init.d/mysql
サービスのデフォルトのランレベルディレクトリの下にS
スクリプトがある限り、initはサーバーの起動時にサービスを開始します。
したがって、MySQLが実行されているはずです。 次に、起動時に自動起動することを確認します。 次のコマンドでマシンを再起動します。
sudo reboot
サーバーがオンラインに戻ったら、SSHで接続します。
service mysql status
コマンドを再実行してください。 繰り返しますが、サービスは実行中として表示されます。 つまり、オペレーティングシステムの起動時にサービスが自動的に開始されます。
ただし、すべてのサービスがこのようになるわけではありません。 そのような場合、自動再起動のためにサービスを手動で構成する必要があります。 Debianの場合、update-rc.d
コマンドを使用すると、起動時に自動的に開始されるサービスを追加(または削除)できます。
MySQLサービスを無効にして、自動開始のために再度有効にする方法を見てみましょう。 このコマンドを実行して、MySQLを無効にします。
sudo update-rc.d mysql disable
テストするには、サーバーを再起動します。
sudo reboot
SSHを使用してサーバーに接続します。
MySQLクライアントツールを使用してMySQLへの接続を試行します。
mysql -u root -p
次のメッセージが表示されます。
OutputERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
サービスを再度有効にします。
sudo update-rc.d mysql enable
出力は次のようになります。
Outputupdate-rc.d: using dependency based boot sequencing
System VでCentOSシステムを実行している場合、コマンドはupdate-rc.d
ではなくchkconfig
を使用します。
起動時にサービスを自動開始するように有効にしても、サービスが停止しても自動的に開始されないことに注意してください。 MySQLを起動するには、次のコマンドを実行します。
sudo service mysql start
[[step-4 -—- configuring-mysql-to-auto-start-after-crash]] ==ステップ4—クラッシュ後に自動起動するようにMySQLを設定する
サービスが再び実行されたので、クラッシュ後に自動的に開始されるかどうかを見てみましょう。 System Vでは、デフォルトでNOTが自動的に起動します。
プロセスを突然強制終了してクラッシュをエミュレートします。 次のコマンドを実行してプロセスIDを見つけます。
ps -ef | grep mysql
出力は次のようになります。
Outputroot 1167 1 0 07:21 pts/0 00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql 1292 1167 0 07:21 pts/0 00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root 1293 1167 0 07:21 pts/0 00:00:00 logger -t mysqld -p daemon.error
root 1384 1123 0 07:21 pts/0 00:00:00 grep mysql
MySQLを実行する主なプロセスはmysqld_safe
とmysqld
です。 mysqld_safe
は、mysqld
の親プロセスです。
この例では、それぞれプロセスID 1167と1292を持っていることがわかります。 それらのプロセス番号は、上の赤で強調表示されています。
kill -9
コマンドでクラッシュをエミュレートしましょう。 必ず独自のプロセスIDを使用してください。
sudo kill -9 1167
sudo kill -9 1292
サービスの状態を確認します。
sudo service mysql status
出力には、サービスが停止したことが示されます。
OutputMySQL is stopped..
サービスがクラッシュしたので、どのようにしてサービスを起動しますか? もちろん再起動できますが、それは手動のプロセスです。再起動は自動的に行われます。 クラッシュ後にMySQLを自動再起動するには、/etc/inittab
ファイルを編集する必要があります。
パート2で/etc/inittab
ファイルについて詳しく説明しますが、ここでは、起動時にSystem Vinitが最初に読み取るファイルであることを理解しましょう。
特に、/etc/inittab
は、プロセスがクラッシュした場合のプロセスの動作を決定します。 一部のプロセスでは、サービスを再生成することを意図しています。 MySQLがこれらのサービスに含まれていることを確認する必要があります。 最初にコピーを作成しましょう。
sudo cp /etc/inittab /etc/inittab.orig
注意事項:/etc/inittab
ファイルを編集するときは特に注意してください。 コマンドを間違えたり、既存の設定を削除したりすると、再起動時にシステムが起動しない場合があります。
テキストエディタで/etc/inittab
を開きます。
sudo nano /etc/inittab
ファイルの最後に、次の行を追加します。
/etc/inittab
ms:2345:respawn:/bin/sh /usr/bin/mysqld_safe
ここで何をしているのでしょうか?
さて、クラッシュしたときに/etc/inittab
ファイルのrespawnにmysqld_safe process
のコマンドを入れています。 4つのフィールドがあり、それぞれがコロン(:)で区切られています。
-
ms:
最初の2文字は、プロセスのidを指定します。 -
2345:
2番目のフィールドは、適用することになっているrunlevelsを指定します。 この場合、ランレベル2、3、4、および5用です。 -
respawn:
3番目のフィールドはactionを指定します(サービスを再生成しています) -
/bin/sh /usr/bin/mysqld_safe
:最後に、4番目のフィールドはprocess(実行するコマンド)です。
パート2で/etc/inittab
ファイルに戻って、クラッシュ後にMySQLを自動起動するのにどのように役立つかを確認します。 ここでは、ファイルを保存してエディターを終了します。
サービスを再度開始します。
sudo service mysql start
サーバーを再起動して、変更を有効にします。
sudo reboot
ここで、コマンドを繰り返してプロセス番号を見つけ、プロセスを強制終了し、ps -ef | grep mysql
から始めてステータスを再度確認します。
Wait for five minutes程度にして、次のコマンドを実行します。
sudo service mysql status
今回は、クラッシュ後にMySQLが自動的に起動したことがわかります。
それでおしまい! MySQLは、サービスのクラッシュまたはシステムの再起動後に自動的に起動します。
Upstartによるサービスの自動開始
Upstartは別のinitメソッドで、Ubuntu 6で最初に導入されました。 Ubuntu 9.10でデフォルトになり、後にRHEL 6とその派生製品に採用されました。 GoogleのChrome OSもUpstartを使用しています。
-
Ubuntu 9.10からUbuntu 14.10(Ubuntu 14.04を含む)
-
CentOS 6
Ubuntuの現在のLTSバージョン(執筆時点では14.04)で強力になっていますが、systemdを支持してどこでも段階的に廃止されています。これについては前のセクションで説明します。
Upstartはシステムサービスの処理においてSystem Vよりも優れており、理解も容易です。 ただし、チュートリアルのこの部分では、Upstartについて詳しくは説明しません。 DigitalOceanコミュニティにはvery good tutorial on Upstartがあります。
今日は、主にUpstart構成ファイルに焦点を当て、それらを使用してサービスを自動開始する方法を確認します。
Upstartは構成ファイルを使用してサービスを制御します。 ファイルは/etc/init
ディレクトリの下にあります。 ファイルには、stanzasと呼ばれる読みやすいセクションを持つプレーンテキストコンテンツが含まれています。 各スタンザは、サービスのさまざまな側面とその動作を説明します。
デフォルトでは、NginxやMySQLなど、インストールできるほとんどの標準アプリケーションは、デフォルトでstart after rebootとstart after a crashになるため、これを機能させるために何もする必要はありません。 すでに/etc/init
に独自のinitスクリプトが付属しています。
カスタムアプリケーションの場合は、これを自分で設定する必要があります。 独自のカスタムUpstartスクリプトを作成する方法については、前に参照したintroductory Upstart tutorialをお読みください。
Upstartの自動起動チェックリスト
このセクションは、サービスが自動的に開始するように設定されていることを確認するためのクイックリファレンスです。
構成チェックリスト
-
サービスの
/etc/init/service.conf
に機能的なUpstartinitスクリプトがあることを確認してください-
再起動後の自動起動を有効にするには、
/etc/init/service.conf
ファイルにstart on runlevel [2345]
のような行を含める必要があります -
/etc/init/service.conf
ファイルには、クラッシュ後にサービスがリスポーンできるように、respawn
のような行も含める必要があります
-
-
サービスにno override fileがあることを確認してください:
/etc/init/service.override
(あなたまたは別の管理者が以前に作成した場合にのみ存在します)
-
サービスを停止してから開始します。
sudo initctl stop service
sudo initctl start service
-
サーバーを再起動します。
sudo reboot
Test
これらが機能していることをテストするには、次のことができます。
-
サーバーを再起動し、サービスが起動していることを確認します
-
プロセス番号を検索:
ps -ef | grep service
-
プロセスを強制終了します。
sudo kill -9 process_number
-
数秒以内に、サービスがバックアップされていることを確認します
[[step-1 -—- connecting-to-your-ubuntu-14-04-droplet]] ==ステップ1— Ubuntu14.04ドロップレットに接続する
MySQLを実行するUbuntu 14.04サーバーを使用して、Upstartのデモを行います。
1 GBのRAMを備えたドロップレットを作成し、ベースイメージとしてUbuntu 14.04 x64を選択します。
SSHでサーバーに接続します(WindowsユーザーはPuTTyなどのツールを使用して接続できます)。
ssh sammy@your_server_ip
次の手順では、アカウントにsudo権限があることを前提としています。
[[step-2 -—- installing-mysql]] ==ステップ2—MySQLのインストール
次に、MySQLをインストールします。
次のコマンドを実行して、パッケージリストを更新します。
sudo apt-get update
MySQLサーバーをインストールします。
sudo apt-get install mysql-server -y
MySQLの新しいルートパスワードを作成し、プロンプトが表示されたら確認します。
インストールが完了したら、mysql_secure_installation
コマンドを実行します。
mysql_secure_installation
Debianにインストールするときに以前に行ったのと同じ回答をプロンプトに提供します(前のセクションを参照)。
[[step-3 -—- configuring-mysql-to-auto-start-after-reboot]] ==ステップ3—再起動後に自動起動するようにMySQLを設定する
デフォルトでは、MySQLは再起動後に自動的に起動します。 この方法で独自のサービスをセットアップできるように、その構成を確認すると便利です。
まず、MySQLサーバープロセスが実行されているかどうかを確認しましょう。
sudo initctl status mysql
次のような出力が表示されます。
Outputmysql start/running, process 2553
サーバーを再起動します。
sudo reboot
サーバーがオンラインに戻ったら、SSHを使用して再接続します。
MySQLのステータスを確認します。
sudo initctl status mysql
出力には、MySQLが自動的に開始されたことが示されます。 したがって、サービスを有効にするためにここで特別なことをする必要はありません。
/etc/init/
ディレクトリに独自のUpstartファイルを作成してサービスを手動で有効にする必要がある他のアプリケーションデーモンには当てはまらない可能性があることに注意してください。
また、MySQLが再起動時に自動起動する必要があることをUpstartはどのように認識しますか?
MySQLのUpstart initファイルを見てみましょう。 /etc/init/mysql.conf
ファイルをテキストエディタで開きます。
sudo nano /etc/init/mysql.conf
Upstartファイルは、Debianマシンで見たようなシェルスクリプトではありません。
MySQLの初期設定ファイルには、開始前および開始後イベント用のスクリプトブロックがあります。 これらのコードブロックは、mysqldプロセスが起動中または起動済みのときに実行するものをUpstartシステムに指示します。
ファイルの最初の10行を詳しく見てみましょう。
/etc/init/mysql.conf
...
description "MySQL Server"
author "Mario Limonciello "
start on runlevel [2345]
stop on starting rc RUNLEVEL=[016]
respawn
respawn limit 2 5
MySQLはランレベル2、3、4、5で起動するはずであり、ランレベル0、1、6で実行するはずではないことがわかります。
ここで、Upstartデーモンのサービス起動動作を定義します。 update-rc.d
またはchkconfig
コマンドを使用したSystem Vとは異なり、Upstartではサービス構成ファイルを使用します。 必要なのは、start
スタンザを追加/変更することだけです。 パート2では、このファイルを使用して、MySQLサービスの有効化と無効化がこのファイルにどのように影響するか、およびその逆を確認します。
respawn
ディレクティブはクラッシュ後にサービスを再起動するため、次のステップで説明します。
[[step-4 -—- configuring-mysql-to-auto-start-after-crash]] ==ステップ4—クラッシュ後に自動起動するようにMySQLを設定する
まだ/etc/init/mysql.conf
を開いているはずです。
respawn
ディレクティブは自明です。クラッシュするとMySQLが起動します。 これはデフォルトですでに有効になっています。
その後のディレクティブはさらに興味深いものです。respawn limit
ディレクティブは、Linuxが秒単位で指定された間隔でクラッシュしたサービスの再起動を試行する回数を指定します。 この場合、最初の引数(2
)は試行回数であり、2番目の引数(5
)は間隔です。 このしきい値内でサービスが正常に起動(再起動)しない場合、サービスは停止状態のままになります。 サービスが継続的にクラッシュしている場合は、システム全体の安定性に影響を与えるよりも、サービスを無効にする方が適切であるため、この正常なデフォルトの動作です。
今のところ、変更を加えずにテキストエディタを終了します。
これまで見てきたように、デフォルトではMySQLはクラッシュ後に自動的に復帰するようにも設定されています。
これをテストするには、サービスPIDを確認しましょう。
sudo initctl status mysql
システムの新しいPID(再起動後)は次のようになります。
Outputmysql start/running, process 961
テストケースのプロセスIDを書き留めます。 次に、独自のプロセス番号を使用して、kill -9
コマンドでプロセスを強制終了することにより、クラッシュをエミュレートします。
sudo kill -9 961
MySQLのステータスを今すぐ確認してください。 新しいPIDを使用して(即時または数秒以内に)実行する必要があります。
sudo initctl status mysql
この場合、新しいPIDは1552です。
Outputmysql start/running, process 1552
必要に応じて、再び殺すことができます。 毎回再び表示されます:
これは、mysql.conf
ファイルのrespawn
ディレクティブが原因で発生しています。
/etc/init/mysql.conf
respawn
MySQLにはデフォルトでクラッシュ後に再起動する機能がありますが、他のサービスの場合は、このディレクティブを手動でUpstartファイルに追加する必要があります。 繰り返しになりますが、パート2では、構成ファイルからクラッシュ動作を変更する方法を説明します。
systemdを使用したサービスの自動開始
systemdはLinuxのsystem and service managerであり、ほとんどの新しいLinuxディストリビューションの事実上の初期化デーモンになっています。
最初にFedoraに実装されたsystemdには、RHEL 7とその派生物であるCentOS 7が付属しています。 Ubuntu 15.04にはネイティブsystemdも同梱されています。 他のディストリビューションはsystemdを組み込んでいるか、まもなく発表します。
-
Debian 7およびDebian 8
-
Ubuntu 15.04
-
CentOS 7
systemdは、System Vコマンドおよび初期化スクリプトと下位互換性があります。
つまり、System Vサービスもsystemdの下で実行されます。 ほとんどのUpstartおよびSystem V管理コマンドは、systemdで動作するように変更されています。 そのため、System V initではdrop-in replacementと呼ばれることがよくあります。
systemdを使用すると、NginxやMySQLなど、インストールできるほとんどの標準アプリケーションはデフォルトでstart after rebootとstart after a crashになるため、これを機能させるために何もする必要はありません。 すでに/etc/systemd/system
に独自のinitスクリプトが付属しています。
カスタムアプリケーションの場合は、独自の初期化スクリプトを作成し、独自にサービスを自動的に開始できるようにする必要があります。 ここでは、カスタムinitスクリプトに含まれる内容の詳細については説明しませんが、systemdの詳細についてはこのintroductory systemd articleを参照してください。
systemdの自動開始チェックリスト
このセクションは、サービスが自動的に開始するように設定されていることを確認するためのクイックリファレンスです。
構成チェックリスト
-
サービスに
/etc/systemd/system/multi-user.target.wants/service.service
にある機能的なsystemdinitスクリプトがあることを確認してください -
systemctl
コマンドを使用して、サービスを有効にします。
sudo systemctl enable service.service
-
これにより、次のようなシンボリックリンクが
/etc/systemd/system/multi-user.target.wants/
に作成されます(NOTはこれを手動で作成します)。
lrwxrwxrwx 1 root root 38 Aug 1 04:43 /etc/systemd/system/multi-user.target.wants/service.service -> /usr/lib/systemd/system/service.service
これにより、再起動後の自動起動が有効になります。
-
/etc/systemd/system/multi-user.target.wants/service.service
ファイルには、クラッシュ後にサービスがリスポーンできるように、ファイルの[Service]
セクションの下にRestart=always
のような行も含める必要があります。 -
systemdデーモンをリロードしてから、サービスを再起動します。
sudo systemctl daemon-reload
sudo systemctl restart service.service
Test
これらが機能していることをテストするには、次のことができます。
-
サーバーを再起動し、サービスが起動していることを確認します
sudo reboot
-
プロセス番号を検索:
ps -ef | grep service
-
プロセスを強制終了します。
sudo kill -9 process_number
-
数秒以内に、サービスがバックアップされていることを確認します
[[step-1 -—- connecting-to-your-centos-7-droplet]] ==ステップ1— CentOS7ドロップレットへの接続
CentOS 7とMySQLを使用して、systemdサービスを構成する方法を示します。
1 GBのRAMを備えたドロップレットを作成し、ベースイメージとしてCentOS 7 x64を選択します。
SSHを使用してサーバーに接続します(WindowsユーザーはPuTTyなどのツールを使用して接続できます)。
ssh sammy@your_server_ip
sudo特権を持つアカウントを使用していると想定しています。
[[step-2 -—- installing-mysql]] ==ステップ2—MySQLのインストール
次のコマンドを実行して、MySQL Community Serverリポジトリをダウンロードしてインストールします。
sudo wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm
sudo rpm -ivh mysql-community-release-el7-5.noarch.rpm
MySQLサーバーをインストールします。
sudo yum install mysql-server -y
インストールが完了したら、mysqldサービスを開始します。
(これは、MySQLをDebianおよびUbuntuの下にインストールしたときと同じではないことに注意してください。 他のディストリビューションでは、MySQLは自動的に起動しました。)
また、systemctl
という新しいsystemdコマンドを使用してサービスを制御しています。
sudo systemctl start mysqld
次に、mysql_secure_installation
コマンドを実行します。
mysql_secure_installation
この場合、MySQLルートパスワードは空になるため、新しいパスワードを作成することを選択する必要があります。 他のプロンプトに対して、DebianまたはUbuntuでインストールしたときと同じ回答を提供します(詳細については、以前のDebianセクションを参照してください)。
[[step-3 -—- configuring-mysql-to-auto-start-after-reboot]] ==ステップ3—再起動後に自動起動するようにMySQLを設定する
デフォルトでは、MySQLは再起動後に自動的に起動するように設定されています。 これがどのように機能するか見てみましょう。
mysqld
デーモンが起動時に自動的に起動するように構成されているかどうかを確認するには、is-enabled
オプションを指定してsystemctl
コマンドを実行します。
sudo systemctl is-enabled mysqld.service
結果は次のようになります。
Outputenabled
マシンを再起動しましょう。
sudo reboot
サーバーが復旧したら、SSHで接続します。
次のコマンドを実行して、サービスのステータスを確認します。
sudo systemctl status mysqld.service
出力には、サービスが実行されていることが示されます。
Outputmysqld.service - MySQL Community Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
Active: active (running) since Fri 2015-07-31 21:58:03 EDT; 1min 52s ago
Process: 662 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
Process: 625 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 661 (mysqld_safe)
...
サービスを無効にするには、次のコマンドを実行します。
sudo systemctl disable mysqld.service
これはサービスを停止しませんが、無効にします。 実際、出力はシンボリックリンクが削除されたことを示しています。
Outputrm '/etc/systemd/system/multi-user.target.wants/mysqld.service'
rm '/etc/systemd/system/mysql.service'
必要に応じて、サーバーを再起動し、MySQLサーバーが実行されているかどうかを再度テストして確認できます(実行されません)。
または、systemctl is-enabled
を再度実行します。 disabled
の応答を取得する必要があります。
sudo systemctl is-enabled mysqld.service
Outputdisabled
サービスを再度有効にします。
sudo systemctl enable mysqld.service
出力には、再作成されるシンボリックリンクが表示されます。
Outputln -s '/usr/lib/systemd/system/mysqld.service' '/etc/systemd/system/mysql.service'
ln -s '/usr/lib/systemd/system/mysqld.service' '/etc/systemd/system/multi-user.target.wants/mysqld.service'
サービスは再起動後に自動的に開始されます。
[[step-4 -—- configuring-mysql-to-auto-start-after-crash]] ==ステップ4—クラッシュ後に自動起動するようにMySQLを設定する
次に、クラッシュ後に自動起動するようにMySQLがどのように構成されているかを確認します。
まず、エディターでmysqld.service
ユニットファイルを開きます(systemdサービスは構成にユニットファイルを使用することを忘れないでください)。
sudo nano /etc/systemd/system/multi-user.target.wants/mysqld.service
ファイルの最後に、再起動のディレクティブがあります。
/etc/systemd/system/multi-user.target.wants/mysqld.service
[Unit]
...
[Install]
...
[Service]
...
...
Restart=always
...
Restart
パラメータの値はalways
に設定されます。 これは、クリーンまたはクリーンでない終了コードまたはタイムアウトでMySQLサービスが再起動することを意味します。
それがsystemdで自動再起動が定義される場所です。
Upstartのrespawn
ディレクティブと同様に、systemdのRestart
パラメーターは、サービスがクラッシュした場合の動作を定義します。
すべてのsystemdサービスでこの機能がデフォルトで有効になっているわけではありません。クラッシュ後にサービスを起動させるには、サービスユニットファイルの[Service]
セクションにこの追加のディレクティブを追加するだけです。 セクションヘッダーが存在しない場合は、[Service]
ヘッダーも追加する必要があります。
クラッシュをエミュレートするには、最初にエディターを終了してから、MySQLプロセスIDを確認します。
sudo systemctl status mysqld.service
Outputmysqld.service - MySQL Community Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
Active: active (running) since Fri 2015-07-31 21:58:03 EDT; 1h 7min ago
Main PID: 661 (mysqld_safe)
...
kill -9
シグナルでこのプロセスを強制終了します。 この場合、メインPIDは661です。 PIDを独自のものに置き換えます。
sudo kill -9 661
ステータスを確認します。
sudo systemctl status mysqld.service
出力は、MySQLが新しいPIDで再起動したことを示します(この場合、新しいプロセスIDは11217です)。
Outputmysqld.service - MySQL Community Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
Active: active (running) since Fri 2015-07-31 23:06:38 EDT; 1min 8s ago
Process: 11218 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
Process: 11207 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 11217 (mysqld_safe)
...
...
そのため、クラッシュ後にもサービスが起動することがわかります。
結論
チュートリアルのこの最初の部分では、System V、Upstart、およびsystemdサービスを再起動またはクラッシュ後に自動起動するように構成する方法を説明しました。
この動作を制御するファイル、構成パラメーター、およびコマンドも確認しました。
これは、より実践的な導入でした。 このシリーズの次回の記事では、概念と基本について詳しく説明します。
ドロップレットはまだ削除しないでください。the next partで戻ってくるので、実行を続けてください。