TOC

クラッシュまたはリブート後に自動的に開始するようにLinuxサービスを構成する方法-パート2：リファレンス

前書き

Linuxサービスの自動起動に関するチュートリアルのこの第2部では、一歩下がってinitプロセスについて詳しく説明します。 デーモンの起動動作を制御する方法を十分に理解する必要があります。

このチュートリアルシリーズのfirst partで、クラッシュまたは再起動後にLinuxサービスを自動起動できるようにする方法についてMySQLを使用したいくつかの実用的な例を共有しました。

System V、Upstart、systemdの3つの異なるinitモードからこれを行う方法を見てきました。 ディストリビューションがデフォルトでどのinitシステムを使用するかを復習するためにfirst tutorialを読んでください。

このチュートリアルでは、コマンドを実行し、実行した構成ファイルを編集した理由を説明します。 System V initデーモンから始めます。 また、時間の経過とともに新しいinitモードに置き換えられた理由も確認します。

前提条件

このチュートリアルに従うには、beforeを作成した3つのDigitalOceanドロップレットが必要です。

我々は持っていた：

  • MySQLを実行しているDebian 6サーバー

  • MySQLを実行するUbuntu 14.04サーバー

  • MySQLを実行しているCentOS 7サーバー

このシリーズのパート1に戻って、最初にドロップレットを作成することをお勧めします。

また、rootユーザーになるか、サーバーでsudo特権を持っている必要があります。 sudo特権がどのように機能するかを理解するには、this DigitalOcean tutorial about sudoを参照してください。

このチュートリアルのコマンド、クエリ、または構成は、実稼働Linuxサーバーでは実行しないでください。

ランレベル

runlevelは、Linuxシステムの現在の状態を表します。

この概念はSystem V initから生まれました。Linuxシステムが起動し、カーネルを初期化してから、ランレベルを1つだけ入力します。

たとえば、ランレベルは、Linuxサーバーのシャットダウン状態、シングルユーザーモード、再起動モードなどになります。 各モードは、その状態で実行できるサービスを決定します。

一部のサービスは1つ以上のランレベルで実行できますが、他のサービスでは実行できません。

ランレベルは1桁で示され、0〜6の値をとることができます。 次のリストは、これらの各レベルの意味を示しています。

  • Runlevel 0:システムのシャットダウン

  • Runlevel 1:シングルユーザー、レスキューモード

  • Runlevels 2, 3, 4:ネットワークが有効になっているマルチユーザーのテキストモード

  • Runlevel 5:マルチユーザー、ネットワーク対応、グラフィカルモード

  • Runlevel 6:システムの再起動

ランレベル2、3、および4は、ディストリビューションによって異なります。 たとえば、一部のLinuxディストリビューションはランレベル4を実装していませんが、他のディストリビューションは実装しています。 一部の分布では、これら3つのレベルが明確に区別されています。 一般に、ランレベル2、3、または4は、Linuxがマルチユーザー、ネットワーク対応、テキストモードで起動した状態を意味します。

サービスの自動開始を有効にすると、実際にはランレベルに追加されます。 System Vでは、OSは特定のランレベルで起動します。そして、起動すると、そのランレベルに関連付けられているすべてのサービスを開始しようとします。

ランレベルはsystemdではtargetsになります。これについては、systemdのセクションで説明します。

InitおよびPID 1

initは、マシンが起動してカーネルがメモリにロードされた後、Linuxシステムで開始される最初のプロセスです。

特に、ユーザープロセスまたはシステムサービスのロード方法、順序、および自動的に開始するかどうかを決定します。

LinuxのすべてのプロセスにはプロセスID（PID）があり、initのPIDは1です。 これは、システムがオンラインになったときに生成される他のすべてのプロセスの親です。

Initの歴史

Linuxが進化するにつれて、initデーモンの動作も進化しました。 もともと、LinuxはUNIXで使用されていたのと同じSystem V initで始まりました。 それ以来、LinuxはUpstart initデーモン（Ubuntuによって作成された）を実装し、現在はsystemd initデーモン（Fedoraによって最初に実装された）を実装しています。

ほとんどのLinuxディストリビューションは、System Vから徐々に移行するか、段階的に廃止し、下位互換性のためだけに維持しています。 UNIXの変形であるFreeBSDは、BSD initとして知られるSystem Vの異なる実装を使用します。 古いバージョンのDebianもSysVinitを使用しています。

initデーモンの各バージョンには、サービスを管理するさまざまな方法があります。 これらの変更の背後にある理由は、サービスだけでなく、デバイス、ポート、およびその他のリソースを処理する堅牢なサービス管理ツールの必要性でした。リソースを並行してロードし、クラッシュから正常に回復します。

System V初期化シーケンス

System Vはinittabファイルを使用します。このファイルは、Upstartなどの後のinitメソッドが下位互換性のために保持しています。

System Vの起動シーケンスを実行してみましょう。

  1. initデーモンはバイナリファイル/sbin/initから作成されます

  2. initデーモンが最初に読み取るファイルは/etc/inittabです

  3. このファイルのエントリの1つは、マシンを起動するランレベルを決定します。 たとえば、ランレベルの値が3に指定されている場合、Linuxはネットワークが有効なマルチユーザーテキストモードで起動します。 （このランレベルはデフォルトのランレベルとして知られています）

  4. 次に、initデーモンは/etc/inittabファイルをさらに調べて、そのランレベルで実行する必要のあるinit scriptsを読み取ります。

そのため、initデーモンは、指定されたランレベルで実行する必要があるinitスクリプトを見つけると、基本的に、起動する必要があるサービスを見つけます。 これらの初期化スクリプトは、最初のチュートリアルでMySQLに対して行ったように、個々のサービスの起動時の動作を構成できる場所です。

次に、initスクリプトを詳細に見てみましょう。

System V構成ファイル：初期化スクリプト

initスクリプトは、System VでMySQLサーバーなどの特定のサービスを制御するものです。

サービスの初期化スクリプトは、アプリケーションのベンダーから提供されるか、Linuxディストリビューションに付属しています（ネイティブサービス用）。 また、カスタム作成サービス用に独自の初期化スクリプトを作成することもできます。

MySQL Serverなどのプロセスまたはサービスが開始されると、そのバイナリプログラムファイルがメモリにロードされる必要があります。

サービスの構成方法によっては、このプログラムはバックグラウンドで継続的に実行し続ける必要があります（そしてクライアント接続を受け入れます）。 このバイナリアプリケーションを開始、停止、または再読み込みするジョブは、サービスの初期化スクリプトによって処理されます。 initializesがサービスであるため、initスクリプトと呼ばれます。

System Vでは、initスクリプトはシェルスクリプトです。

initスクリプトは、rc（コマンド実行）スクリプトとも呼ばれます。

ディレクトリ構造

/etcディレクトリは、initスクリプトの親ディレクトリです。

initシェルスクリプトの実際の場所は/etc/init.dの下です。 これらのスクリプトは、rcディレクトリにシンボリックリンクされています。

/etcディレクトリ内には、いくつかのrcディレクトリがあり、それぞれの名前に番号が付いています。

数字は異なるランレベルを表します。 したがって、/etc/rc0.d、/etc/rc1.d、/etc/rc2.dなどがあります。

次に、各rcn.dディレクトリ内に、ファイル名がKまたはSで始まり、その後に2桁の数字が続くファイルがあります。 これらは、実際のinitシェルスクリプトを指すシンボリックリンクファイルです。 なぜKとS？ KはKillを意味します（つまり、 停止）および「S」は開始を表します。

2桁は、スクリプトの実行順序を表します。 したがって、K25some_scriptという名前のファイルがある場合、そのファイルはK99another_scriptの前に実行されます。

起動

スタートアップシーケンスに戻りましょう。 では、initスクリプトはどのように呼び出されますか？ 誰がそれらを呼び出しますか？

KおよびSスクリプトは、initデーモンによって直接呼び出されるのではなく、別のスクリプトである/etc/init.d/rcスクリプトによって呼び出されます。

覚えているかと思いますが、/etc/inittabファイルは、システムがデフォルトで入力するランレベルをinitデーモンに通知します。 ランレベルごとに、/etc/inittabファイルの行が/etc/init.d/rcスクリプトを呼び出し、そのランレベルをパラメーターとして渡します。 次に、このパラメータに基づいて、スクリプトは対応する/etc/rcn.dディレクトリの下のファイルを呼び出します。 したがって、サーバーがランレベル2で起動すると、/etc/rc2.dの下のスクリプトが呼び出されます。ランレベル3の場合、/etc/rc3.dの下のスクリプトが実行されます。

rcディレクトリ内では、最初に、すべてのKスクリプトが「stop」の引数で番号順に実行され、次にすべてのSスクリプトが「start」の引数で同様の方法で実行されます。舞台裏では、対応するinitシェルスクリプトがそれぞれstopパラメーターとstartパラメーターを使用して呼び出されます。

/etc/rcn.dディレクトリの下のファイル（KnnおよびSnnファイル）はシンボリックリンクのみであるため、それらを呼び出すことは、stopおよびstartパラメーターを使用して実際のinitシェルスクリプトを呼び出すことを意味します。

要約すると、Linuxサーバーがランレベルに入ると、特定のスクリプトが実行されて一部のサービスが停止し、他のスクリプトが実行されて他のサービスが開始されます。

[。注意]＃＃

このinitスクリプトの呼び出しは、システムが新しいランレベルに切り替わるたびに発生します。対応する/etc/rc<n>.dディレクトリスクリプトが実行されます。 また、これらのKファイルとSファイルはリンクにすぎないため、/etc/init.dディレクトリの下にある実際のシェルスクリプトは、適切な開始引数または停止引数を使用して実行されます。

プロセス全体により、そのランレベルで実行されるはずのないサービスが停止され、そのランレベルで実行されるはずのすべてのサービスが開始されます。

System Vの自動起動

ブート時にサービスを自動開始できるようにするため、実際にはinitの動作を変更しています。

したがって、たとえば、サービスがランレベル3で自動開始できるようにすると、バックグラウンドでプロセスが/etc/rc3.dディレクトリに適切なリンクを作成します。

紛らわしい場合は、心配しないでください。すぐにその意味がわかります。

システムVの例

MySQLサービスの例に戻りますが、今回はより多くの理論を使用します。

[[step-1 -—- logging-in-to-debian-droplet]] ===ステップ1—Debianドロップレットにログインする

チュートリアルのこのパートでは、パート1で作成したDebian 6ドロップレットに戻ります。 SSHコマンドを使用してサーバーに接続します（WindowsユーザーはPuTTyなどのツールを使用して接続できます）。 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-inittab]] ===ステップ2—inittabを見る

次のコマンドを実行して、inittabファイルの内容を確認します。 

cat /etc/inittab | grep initdefault

出力は次のようになります。 

Outputid:2:initdefault:

idフィールドの後の2は、システムがランレベル2で開始するように構成されていることを示しています。 これがデフォルトのランレベルです。 この場合、Debianは2をマルチユーザー、テキストモードとして指定します。 次のコマンドを実行すると： 

cat /etc/inittab | grep Runlevel

出力はこれを確認します： 

Output# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

[[step-3 -—- looking-at-the-rc-directories]] ===ステップ3—rcディレクトリを確認する

次のコマンドを実行して、rcディレクトリを一覧表示します。 次の6つが表示されます。 

ls -ld /etc/rc*.d
Outputdrwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc0.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc1.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc2.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc3.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc4.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc5.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc6.d
drwxr-xr-x 2 root root 4096 Jul 23  2012 /etc/rcS.d

システムはランレベル2（inittabファイルからのデフォルトのinit）で起動するため、/etc/rc2.dディレクトリの下のスクリプトはシステムの起動時に実行されます。

このディレクトリの内容をリストします。 

ls -l /etc/rc2.d

これは、ファイルがシンボリックリンクにすぎず、それぞれが/etc/init.dの下のスクリプトファイルを指していることを示しています。 

Output. . .
lrwxrwxrwx 1 root root  17 Jul 23  2012 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  22 Jul 23  2012 S02acpi-support -> ../init.d/acpi-support
lrwxrwxrwx 1 root root  15 Jul 23  2012 S02acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root  17 Jul 23  2012 S02anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02atd -> ../init.d/atd
lrwxrwxrwx 1 root root  14 Jul 23  2012 S02cron -> ../init.d/cron
lrwxrwxrwx 1 root root  15 Jul 31 07:09 S02mysql -> ../init.d/mysql
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02ssh -> ../init.d/ssh
. . .

ここにはKスクリプトはなく、S（開始）スクリプトのみが表示されています。 スクリプトは、rsyslog、cron、またはsshなどの既知のサービスを開始します。

Sの後の2桁が起動順序を決定することに注意してください。たとえば、rsyslogはcronデーモンの前に起動します。 MySQLがここにリストされていることもわかります。

[[step-4 -—- looking-at-an-init-script]] ===ステップ4—初期化スクリプトを見る

System V準拠のサービスをインストールすると、/etc/init.dディレクトリの下にシェルスクリプトが作成されることがわかりました。 MySQLのシェルスクリプトを確認します。 

ls -l /etc/init.d/my*
Output-rwxr-xr-x 1 root root 5437 Jan 14  2014 /etc/init.d/mysql

起動スクリプトが実際にどのように見えるかを確認するには、ファイルを読んでください： 

cat /etc/init.d/mysql | less

出力から、大きなbashスクリプトであることがわかります。

[[step-5 --- using-chkconfig-or-sysv-rc-conf]] ===ステップ5—chkconfigまたはsysv-rc-confを使用する

CentOSのようなRHELベースのディストリビューションでは、chkconfigというコマンドを使用して、SystemVでサービスを有効または無効にすることができます。 また、インストールされているサービスとそれらのランレベルをリストすることもできます。

[。注意]＃＃

CentOSシステム上のすべてのランレベルのサービスのステータスをチェックする構文は次のとおりです。 

chkonfig --list | grep service_name

そのようなユーティリティはDebianにネイティブに同梱されていません（update-rc.dはランレベルからのみサービスをインストールまたは削除します）。 ただし、サービスの管理に役立つsysv-rc-confというカスタムツールをインストールすることはできます。

次のコマンドを実行して、sysv-rc-confをインストールします。 

sudo apt-get install sysv-rc-conf -y

ツールをインストールしたら、次のコマンドを実行するだけで、さまざまなサービスのランレベルの動作を確認できます。 

sudo sysv-rc-conf

出力は、以下に示すようなかなりグラフィカルなウィンドウになります。 ここから、どのランレベルでどのサービスが有効になっているかを明確に確認できます（Xでマーク）。

sysv-rc-conf Window showing X marks for various services for each runlevel

矢印キーとSPACEBARを使用して、1つ以上のランレベルのサービスを有効または無効にできます。

今のところ、Qを押して画面を終了します。

[[step-7 -—- testing-mysql-startup-behavior-at-boot]] ===ステップ7—起動時のMySQL起動動作のテスト

前のセクションのスクリーンショットと、チュートリアルのパート1のテストからわかるように、MySQLは現在、ランレベル2〜5で有効になっています。

以下のコマンドを実行して、MySQLサービスをdisableします。 

sudo update-rc.d mysql disable
Outputupdate-rc.d: using dependency based boot sequencing
insserv: warning: current start runlevel(s) (empty) of script `mysql' overwrites defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' overwrites defaults (0 1 6).

次のコマンドを実行します。 

ls -l /etc/rc2.d

出力には、/etc/rc2.dから/etc/init.d/mysqlへのシンボリックリンクがKに変更されたことが示されます。 

Output. . .
lrwxrwxrwx 1 root root  15 Jul 31 07:09 K02mysql -> ../init.d/mysql
. . .

つまり、MySQLはデフォルトのランレベル（2）で起動しなくなります。

これは、サービスを有効または無効にしたときにSystem Vの背後で発生することです。 サービスのデフォルトのランレベルディレクトリの下にSスクリプトがある限り、initは起動時にそのサービスを開始します。

サービスを再度有効にします。 

sudo update-rc.d mysql enable

[[step-8 -—- testing-mysql-start-up-behavior-on-crash]] ===ステップ8—クラッシュ時のMySQL起動動作のテスト

System Vがサービスクラッシュを処理する方法を見てみましょう。

このチュートリアルのパート1で/etc/inittabファイルに変更を加えて、クラッシュ後にMySQLが自動的に起動できるようにしたことを思い出してください。 次の行を追加しました。

/etc/inittab

ms:2345:respawn:/bin/sh /usr/bin/mysqld_safe

これは、クラッシュ後にMySQLサービスが開始されるようにするためでした。 それが発生するかどうかを確認するには、まずサーバーを再起動します。 

sudo reboot

サーバーが戻ったら、SSHでサーバーに接続し、以前のようにMySQLプロセスIDを確認します。 

ps -ef | grep mysql

mysqld_safeおよびmysqldのプロセスIDに注意してください。 私たちの場合、これらはそれぞれ895と1019でした。 

Outputroot       907     1  0 07:30 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     1031   907  0 07:30 ?        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      1032   907  0 07:30 ?        00:00:00 logger -t mysqld -p daemon.error
root      2550  2532  0 07:31 pts/0    00:00:00 grep mysql

-9スイッチを使用してプロセスを再度強制終了します（PIDをDebianシステムのPIDに置き換えます）。 

sudo kill -9 907
sudo kill -9 1031

5分ほど待ってから、コマンドを実行します。 

sudo service mysql status

出力には、次の行から始まるMySQLサービスが実行されていることが示されます。 

Output/usr/bin/mysqladmin  Ver 8.42 Distrib 5.1.73, for debian-linux-gnu on x86_64

ps -ef | grep mysqlコマンドを再度実行すると、mysqld_safeプロセスとmysqldプロセスの両方が起動したことがわかります。

プロセスをさらに数回強制終了してみてください。いずれの場合も、5分後に再起動するはずです。

これが、/etc/inittabにその余分な行を追加した理由です。これは、クラッシュ時にリスポーンするようにSystemVサービスを構成する方法です。 この行の構文の詳細な説明はPart 1にあります。

ただし、サービスの自動再起動を追加するときは注意してください。サービスが2分以内に再生成を試みて10回以上失敗すると、Linuxは次の5分間の再生成を無効にします。 これは、システムが安定したままであり、コンピューティングリソースが不足しないようにするためです。

コンソールでそのようなイベントに関するメッセージを受信した場合、またはシステムログでそれを見つけた場合、クラッシュし続けるため、修正が必要なアプリケーションに問題があることがわかります。

新興企業の紹介

クラシックSysVinitは、Upstartが登場する前から長い間、主流のLinuxディストリビューションの一部でした。

Linux市場が成長するにつれて、ジョブとサービスをロードするシリアル化された方法は、より時間がかかり複雑になりました。 同時に、ホットプラグ可能なストレージメディアなどの最新のデバイスが市場で急増するにつれて、SysVinitはそれらを迅速に処理できないことがわかりました。

OSのより高速なロード、クラッシュしたサービスの適切なクリーンアップ、およびシステムサービス間の予測可能な依存関係の必要性により、より優れたサービスマネージャーが必要になりました。 Ubuntuの開発者は、初期化の別の手段であるUpstartデーモンを思いつきました。

Upstart initは、いくつかの点でSystem V initよりも優れています。

  • Upstartは、サービスをロードおよび管理するための難解なシェルスクリプトを処理しません。 代わりに、わかりやすく変更しやすいシンプルな構成ファイルを使用します

  • Upstartは、System Vのようなサービスを連続してロードしません。 これにより、システムの起動時間が短縮されます

  • Upstart’sは、柔軟なeventシステムを使用して、さまざまな状態でのサービスの処理方法をカスタマイズします

  • Upstartには、クラッシュしたサービスがどのように再生成されるべきかを処理するより良い方法があります

  • 同じスクリプトを指すすべての冗長なシンボリックリンクを保持する必要はありません。

  • UpstartはSystem Vと下位互換性があります。 /etc/init.d/rcスクリプトは、ネイティブSystemVサービスを管理するために引き続き実行されます

新興イベント

Upstartを使用すると、複数のeventsをサービスに関連付けることができます。 このイベントベースのアーキテクチャにより、Upstartはサービス管理を柔軟に処理できます。

各イベントは、そのイベントを処理するシェルスクリプトを起動できます。

Upstartイベントには以下が含まれます。

  • 起動

  • 始めました

  • 停止中

  • 停止

これらのイベントの間に、サービスは次のようにいくつかのstatesに含まれる可能性があります。

  • 待っている

  • 事前開始

  • 起動

  • ランニング

  • 事前停止

  • 止まる

  • etc.

Upstartはこれらの各状態に対してもアクションを実行でき、非常に柔軟なアーキテクチャを作成します。

Upstart Initシーケンス

System Vと同様に、Upstartも起動時に/etc/init.d/rcスクリプトを実行します。 このスクリプトは、System V initスクリプトを通常どおり実行します。

Upstartはまた、/etc/initディレクトリの下を調べ、各サービス構成ファイルでシェルコマンドを実行します。

スタートアップ構成ファイル

Upstartは構成ファイルを使用してサービスを制御します。

UpstartはSystem VのようにBashスクリプトを使用しません。 代わりに、Upstartはservice_name.confの命名基準でservice configurationファイルを使用します。

ファイルには、stanzasと呼ばれるさまざまなセクションを持つプレーンテキストコンテンツが含まれています。 各スタンザは、サービスのさまざまな側面とその動作を説明します。

異なるスタンザは、pre-start、start、pre-stop、post-stopなどのサービスのさまざまなイベントを制御します。

スタンザ自体にはシェルコマンドが含まれています。 したがって、各サービスのイベントごとに複数のアクションを呼び出すことができます。

各構成ファイルは、次の2つのことも指定します。

  • サービスを開始および停止するランレベル

  • クラッシュした場合にサービスをrespawnにするかどうか

ディレクトリ構造

Upstart構成ファイルは/etc/initディレクトリの下にあります（/etc/init.dと混同しないでください）。

アップスタートの例

UpstartがMySQLサーバーを再び処理する方法を見てみましょう。今回はより多くの背景知識があります。

[[step-1 -—- logging-in-to-ubuntu-droplet]] ===ステップ1—Ubuntuドロップレットにログインする

パート1で作成したUbuntu 14.04ドロップレットに戻ります。

SSHコマンドを使用してサーバーに接続します（WindowsユーザーはPuTTyなどのツールを使用して接続できます）。 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-the-init-and-rc-directories]] ===ステップ2—initおよびrcディレクトリを確認する

Upstartの設定ファイルのほとんどは/etc/initディレクトリにあります。 これは、新しいサービスを作成するときに使用する必要があるディレクトリです。

サーバーにログインしたら、次のコマンドを実行します。 

sudo ls -l /etc/init/ | less

その結果、多数のサービス構成ファイルが一度に1画面ずつ表示されます。 これらは、Upstartの下でネイティブに実行されるサービスです。 

Outputtotal 356
. . .
-rw-r--r-- 1 root root  297 Feb  9  2013 cron.conf
-rw-r--r-- 1 root root  489 Nov 11  2013 dbus.conf
-rw-r--r-- 1 root root  273 Nov 19  2010 dmesg.conf
. . .
-rw-r--r-- 1 root root 1770 Feb 19  2014 mysql.conf
-rw-r--r-- 1 root root 2493 Mar 20  2014 networking.conf

Qを押して、lessを終了します。

これをシステムのネイティブSystem V initサービスと比較します。 

sudo ls -l /etc/rc3.d/* | less

ほんの一握りがあります： 

Output-rw-r--r-- 1 root root 677 Jun 14 23:31 /etc/rc3.d/README
lrwxrwxrwx 1 root root  15 Apr 17  2014 /etc/rc3.d/S20rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  24 Apr 17  2014 /etc/rc3.d/S20screen-cleanup -> ../init.d/screen-cleanup
lrwxrwxrwx 1 root root  19 Apr 17  2014 /etc/rc3.d/S70dns-clean -> ../init.d/dns-clean
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S70pppd-dns -> ../init.d/pppd-dns
lrwxrwxrwx 1 root root  26 Apr 17  2014 /etc/rc3.d/S99digitalocean -> ../init.d//rc.digitalocean
lrwxrwxrwx 1 root root  21 Apr 17  2014 /etc/rc3.d/S99grub-common -> ../init.d/grub-common
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99ondemand -> ../init.d/ondemand
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99rc.local -> ../init.d/rc.local

[[step-3 -—- looking-at-an-upstart-file]] ===ステップ3—アップスタートファイルを確認する

このチュートリアルのパート1で、mysql.confファイルをすでに見てきました。 それでは、別の設定ファイルを開きましょう：cronデーモン用です。 

sudo nano /etc/init/cron.conf

ご覧のとおり、これはcronデーモンのかなり単純な構成ファイルです。

/etc/init/cron.conf

# cron - regular background program processing daemon
#
# cron is a standard UNIX program that runs user-specified programs at
# periodic scheduled times

description     "regular background program processing daemon"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork
respawn

exec cron

ここで注意すべき重要なフィールドは、start on、stop on、およびrespawnです。

start onディレクティブは、システムがランレベル2、3、4、または5に入ると、crondデーモンを開始するようにUbuntuに指示します。 2、3、および4はネットワークが有効なマルチユーザーテキストモードで、5はマルチユーザーグラフィカルモードです。 サービスは他のランレベル（0、1、6など）では実行されません。

forkディレクティブは、Upstartに、プロセスをコンソールから切り離してバックグラウンドで実行するように指示します。

次はrespawnディレクティブです。 これは、何らかの理由でcronがクラッシュした場合にcronが自動的に開始することをシステムに伝えます。

変更を加えずにエディターを終了します。

cron構成ファイルは、かなり小さな構成ファイルです。 MySQL構成ファイルは、cron構成ファイルと構造的に類似しています。また、開始、停止、およびリスポーンのスタンザもあります。 さらに、開始前および開始後イベント用の2つのスクリプトブロックもあります。 これらのコードブロックは、mysqldプロセスが起動中または起動済みのときに実行するものをシステムに指示します。

独自のUpstartファイルを作成するための実用的なヘルプについては、this tutorial about Upstartを参照してください。

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] ===ステップ4—起動時のMySQL起動動作のテスト

Ubuntu 14.04サーバー上のMySQLインスタンスは、デフォルトでブート時に自動起動するように設定されています。 無効にする方法を見てみましょう。

Upstartでは、サービスの無効化は、service_name.overrideと呼ばれる/etc/init/の下のファイルの存在に依存します。 ファイルの内容は、manualという単純な単語である必要があります。

このファイルを使用してMySQLを無効にする方法を確認するには、次のコマンドを実行してMySQLのこのオーバーライドファイルを作成します。 

sudo nano /etc/init/mysql.override

この単一行を追加します。

/etc/init/mysql.override

manual

変更を保存してください。

次に、サーバーを再起動します。 

sudo reboot

サーバーがオンラインに戻ったら、サービスのステータスを確認します 

sudo initctl status mysql

出力は次のようになります。 

Outputmysql stop/waiting

これは、MySQLが起動しなかったことを意味します。

MySQLサービス構成ファイルでstartディレクティブが変更されているかどうかを確認します。 

sudo cat /etc/init/mysql.conf | grep start\ on

まだ同じであるはずです： 

Outputstart on runlevel [2345]

これは、initディレクトリ内の.confファイルをチェックすることが、サービスが適切なレベルで開始されるかどうかを確認する唯一の要因ではないことを意味します。 また、.overrideファイルが存在しないことを確認する必要があります。

MySQLを再度有効にするには、オーバーライドファイルを削除してサーバーを再起動します。 

sudo rm -f /etc/init/mysql.override
sudo reboot

サーバーが再起動したら、リモートでサーバーに接続します。

sudo initctl status mysqlコマンドを実行すると、サービスが自動的に開始されたことが示されます。

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] ===ステップ5—クラッシュ時のMySQL起動動作のテスト

デフォルトでは、MySQLはクラッシュ後に自動的に起動します。

MySQLを停止するには、/etc/init/mysql.confサービス構成ファイルを開きます。 

sudo nano /etc/init/mysql.conf

両方のrespawnディレクティブをコメントアウトします。

/etc/init/mysql.conf

# respawn
# respawn limit 2 5

次のコマンドを実行して、サービスを再起動します。 

sudo initctl stop mysql
sudo initctl start mysql

テストでinitctl restartまたはinitctl reloadがここでは機能しないことが示されたため、サービスを明示的に停止および開始しています。

サービスを開始する2番目のコマンドは、MySQLが開始されたPIDを表示します。 

Outputmysql start/running, process 1274

MySQLのインスタンスのPIDに注意してください。 ここでmysqlプロセスをクラッシュさせても、自動的には起動しません。 プロセスOFを強制終了します（独自の番号に置き換えます）。 

sudo kill -9 1274

次に、ステータスを確認します。 

sudo initctl status mysql
Outputmysql stop/waiting

それぞれの間に時間を空けて、さらに数回ステータスを見つけてください。 どの場合でも、MySQLは引き続き停止されます。 これは、サービス構成ファイルにrespawnディレクティブが含まれていないために発生しています。

チュートリアルのPart 1には、respawnディレクティブのより詳細な説明があります。

[。注意]＃＃

再起動またはクラッシュした後、notがUpstartサービスを起動するのはいつですか？

Linuxカーネルをアップグレードしたか、最新のパッチを適用したとしましょう。 ドラマは必要ありません。あなただけのサーバーが登場します。 Upstartプロセスの自動起動を無効にすることで、リスクを大幅に排除できます。

サービスが起動してもクラッシュし続ける場合は、最初にサービスを停止してから、リスポーン動作を変更することもできます。

systemdの概要

Linux initデーモンの最新のものはsystemdです。 実際、initdデーモン以上のものです。systemdは、最新のLinuxシステムの多くのコンポーネントを含むまったく新しいフレームワークです。

その機能の1つは、Linuxのsystem and service managerとして機能することです。 この能力において、systemdが制御することの1つは、サービスがクラッシュまたはマシンがリブートした場合のサービスの動作です。 systemd’s systemctl hereについて読むことができます。

systemdは、System Vコマンドおよび初期化スクリプトと下位互換性があります。 つまり、System Vサービスもsystemdの下で実行されます。 これは、ほとんどのUpstartおよびSystem V管理コマンドがsystemdで動作するように変更されているために可能です。

実際、ps -ef | grep systemdコマンドをそれをサポートするオペレーティングシステムで実行すると、起動時にsystemdの名前がinitに変更されるため、何も表示されません。 /bin/systemdへのシンボリックリンクである/sbin/initファイルがあります。

systemd構成ファイル：ユニットファイル

systemdの中心にはunit filesがあります。 各ユニットファイルはシステムリソースを表します。 systemdと他の2つのinitメソッドの主な違いは、systemdがサービスデーモンだけでなく、ソケット、デバイスオペレーティングシステムパス、マウントポイント、ソケットなどの他のタイプのリソースの初期化も担当することです。 リソースはこれらのいずれかです。

リソースに関する情報は、ユニットファイルで追跡されます。

各ユニットファイルは特定のシステムリソースを表し、service name.unit typeの命名スタイルを持っています。

したがって、dbus.service、sshd.socket、またはhome.mountのようなファイルがあります。

後で説明するように、サービスユニットファイルは、宣言型構文を持つ単純なテキストファイル（Upstart.confファイルなど）です。 これらのファイルは非常に簡単に理解して変更できます。

ディレクトリ構造

CentOSのようなRed Hatベースのシステムでは、ユニットファイルは2つの場所にあります。 主な場所は/lib/systemd/system/です。

カスタム作成されたユニットファイルまたはシステム管理者によって変更された既存のユニットファイルは、/etc/systemd/systemの下に存在します。

同じ名前のユニットファイルが両方の場所に存在する場合、systemdは/etcの下にあるものを使用します。 サービスが起動時またはその他のターゲット/ランレベルで開始できるようになっている場合、/etc/systemd/systemの適切なディレクトリの下にそのサービスユニットファイルのシンボリックリンクが作成されます。 /etc/systemd/systemの下のユニットファイルは、実際には/lib/systemd/systemの下の同じ名前のファイルへのシンボリックリンクです。

systemd初期化シーケンス：ターゲットユニット

特別なタイプのユニットファイルはtarget unitです。

ターゲットユニットのファイル名には、.targetの接尾辞が付いています。 ターゲットユニットは特定のリソースを表すものではないため、他のユニットファイルとは異なります。 むしろ、それらはいつでもシステムの状態を表します。

ターゲットユニットは、その状態の一部である複数のユニットファイルをグループ化して起動することでこれを行います。 したがって、systemdtargetsは、同じではありませんが、SystemVのランレベルと大まかに比較できます。

各ターゲットには、番号ではなく名前があります。 たとえば、ランレベル3の代わりにmulti-user.target、またはランレベル6の代わりにreboot.targetがあります。

Linuxサーバーがたとえばmulti-user.targetで起動すると、基本的にサーバーはランレベル2、3、または4になります。これは、ネットワークが有効になっているマルチユーザーテキストモードです。

どのようにしてサーバーをその段階に移行させるかが違いがあります。 System Vとは異なり、systemdはサービスを順番に起動しません。 途中で、他のサービスまたはリソースの存在を確認し、それらのロードの順序を決定できます。 これにより、サービスを並行してロードできます。

ターゲットユニットとランレベルのもう1つの違いは、System Vでは、Linuxシステムが1つのランレベルにしか存在できないことです。 ランレベルを変更できますが、システムはその新しいランレベルにのみ存在します。 systemdを使用すると、ターゲットユニットをinclusiveにすることができます。つまり、ターゲットユニットがアクティブになると、他のターゲットユニットがその一部としてロードされるようになります。

たとえば、グラフィカルユーザーインターフェイスで起動するLinuxシステムでは、graphical.targetがアクティブ化されます。これにより、multi-user.targetも自動的にロードされてアクティブ化されます。

（System Vの用語では、ランレベル3と5を同時にアクティブにするようなものです。）

以下の表では、ランレベルとターゲットを比較しています。

ランレベル（System V init） ターゲットユニット（Systemd）

ランレベル0

poweroff.target

ランレベル1

resuce.target

ランレベル2、3、4

multi-user.target

ランレベル5

graphical.target

ランレベル6

reboot.target

systemd default.target

default.targetは、デフォルトのランレベルと同等です。

System Vでは、inittabというファイルでデフォルトのランレベルが定義されていました。 systemdでは、そのファイルはdefault.targetに置き換えられます。 デフォルトのターゲットユニットファイルは、/etc/systemd/systemディレクトリの下にあります。 これは、/lib/systemd/systemの下にあるターゲットユニットファイルの1つへのシンボリックリンクです。

デフォルトのターゲットを変更すると、基本的にそのシンボリックリンクを再作成し、システムのランレベルを変更します。

System Vのinittabファイルは、Linuxがinitスクリプトを実行するディレクトリも指定しました。これはrcn.dディレクトリのいずれかです。 systemdでは、デフォルトのターゲットユニットが、ブート時にロードされるリソースユニットを決定します。

これらのユニットはすべてアクティブになりますが、すべてが並列にまたはすべて順番に実行されるわけではありません。 リソースユニットのロード方法は、wantsまたはrequiresの他のリソースユニットに依存する場合があります。

systemd依存関係：欲しいものと必要なもの

ユニットファイルとターゲットユニットに関するこの議論の理由は、systemdがデーモン間の依存関係に対処する方法を強調するためです。

前に見たように、Upstartは構成ファイルを使用してサービスの並列読み込みを保証します。 System Vでは、サービスは特定のランレベルで開始できますが、別のサービスまたはリソースが利用可能になるまで待機することもできます。 同様に、systemdサービスを1つ以上のターゲットにロードするか、別のサービスまたはリソースがアクティブになるまで待つことができます。

systemdでは、別のユニットをrequiresするユニットは、必要なユニットがロードされてアクティブ化されるまで起動しません。 最初のユニットがアクティブな間に何らかの理由で必要なユニットが故障すると、最初のユニットも停止します。

考えてみると、これによりシステムの安定性が保証されます。 したがって、特定のディレクトリが存在する必要があるサービスは、そのディレクトリへのマウントポイントがアクティブになるまで待機することができます。 一方、別のユニットをwantsするユニットは、そのような制限を課しません。 発信者がアクティブなときに目的のユニットが停止しても停止しません。 これの例は、グラフィカルターゲットモードで起動する非必須サービスです。

systemdの例

systemdでのMySQLの起動時の動作について詳しく説明します。

[[step-1 -—- log-in-to-centos-droplet]] ===ステップ1— CentOSDropletにログインします

これらのすべての概念と、それらの概念がサービスを自動開始できるようにすることとの関係を理解するために、パート1で作成したCentOS 7 Dropletに戻りましょう。

SSHコマンドを使用してサーバーに接続します（WindowsユーザーはPuTTyなどのツールを使用して接続できます）。 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-the-default-target-file-and-dependencies]] ===ステップ2—default.targetファイルと依存関係を確認する

.targetのウサギの軌跡を可能な限り追跡するため、これは長いセクションです。 systemdの起動シーケンスは、依存関係の長いチェーンに従います。

defaul.target

default.targetファイルは、通常のサーバー起動中に開始するサービスを制御します。

次のコマンドを実行して、デフォルトのターゲットユニットファイルをリストします。 

sudo ls -l /etc/systemd/system/default.target

これにより、次のような出力が表示されます。 

Outputlrwxrwxrwx. 1 root root 37 Jul  8  2014 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

ご覧のとおり、デフォルトのターゲットは、実際には/lib/systemd/system/の下にあるマルチユーザーターゲットファイルへのシンボリックリンクです。 したがって、システムはmulti-user.targetで起動することになっています。これは、ランレベル3と同様です。

multi-user.target.wants

次に、次のコマンドを実行して、multi-user.targetファイルwantsのすべてのサービスを確認します。 

sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service

これにより、次のような出力が表示されます。 

Output. . .
lrwxrwxrwx. 1 root root  37 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service
. . .
lrwxrwxrwx  1 root root  38 Jul 31 22:02 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service
lrwxrwxrwx. 1 root root  46 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root  36 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service
. . .

これらはすべてシンボリックリンクファイルであり、/lib/systemd/system/の下の実際のユニットファイルを指していることがわかります。 また、mysqld.serviceがmulti-user.targetの一部であることがわかります。

このコマンドを実行して出力をフィルタリングすると、同じ情報が見つかります。 

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql
Outputmysqld.service

multi-user.target以外にも、system-update.targetやbasic.targetなどのさまざまなタイプのターゲットがあります。

マルチユーザーターゲットが依存するターゲットを確認するには、次のコマンドを実行します。 

sudo systemctl show --property "Requires" multi-user.target | fmt -10
OutputRequires=basic.target

したがって、システムをmulti-user.targetモードで起動するには、basic.targetを最初にロードする必要があります。

basic.target

他のターゲットbasic.targetが依存しているものを確認するには、次のコマンドを実行します。 

sudo systemctl show --property "Requires" basic.target | fmt -10

出力は次のようになります。 

OutputRequires=sysinit.target

sysinit.target

再帰的に進むと、sysinit.targetに必要な単位があるかどうかを確認できます。 ありません。 ただし、どのサービスがwantedであるかをsysinit.targetで確認できます。 

sudo systemctl show --property "Wants" sysinit.target | fmt -10

これにより、sysinitが必要とする多くのサービスが表示されます。 

OutputWants=local-fs.target
swap.target
cryptsetup.target
systemd-udevd.service
systemd-update-utmp.service
systemd-journal-flush.service
plymouth-read-write.service
. . .

ご覧のとおり、システムは1つのターゲットのみにとどまりません。 ターゲット間を移行するときに、依存する方法でサービスをロードします。

[[step-3 -—- looking-at-a-unit-file]] ===ステップ3—ユニットファイルを見る

さらに一歩進んで、サービスユニットファイルの内部を見てみましょう。 このチュートリアルのパート1でMySQLサービスユニットファイルを確認しました。すぐに再び使用しますが、ここでは別のサービスユニットファイル、sshdのファイルを開きます。 

sudo nano /etc/systemd/system/multi-user.target.wants/sshd.service

それはこのように見えます： 

Output[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Upstartデーモンの構成ファイルと同じように、このサービスユニットファイルはクリーンでわかりやすいものです。

理解すべき最初の重要なビットは、After句です。 これは、システムおよびネットワークターゲットと監査ログサービスが読み込まれた後に、SSHDサービスを読み込む必要があることを示しています。

このファイルは、サービスがmulti-user.targetによってwantedであることも示しています。これは、ターゲットがこのサービスをロードすることを意味しますが、sshdが失敗してもシャットダウンまたはクラッシュしません。

multi-user.targetがデフォルトのターゲットであるため、sshdデーモンは起動時に起動することになっています。

エディターを終了します。

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] ===ステップ4—起動時のMySQL起動動作のテスト

チュートリアルのパート1では、MySQLサービスを有効にして実行したままにしました。 それを変更する方法を見てみましょう。

前のセクションでは、mysqld.serviceがmulti-user.targetに必要であることを確認するコマンドを実行しました。 /etc/systemd/system/multi-user.target.wants/ディレクトリの内容を一覧表示すると、/usr/lib/systemd/system/の下にある元のサービスユニットを指すシンボリックリンクが表示されました。

次のコマンドを実行してサービスを無効にし、起動時に自動起動しないようにします。 

sudo systemctl disable mysqld.service

ここで、このコマンドを実行して、MySQLがまだmulti-user.targetに必要かどうかを確認します。 

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql

何も返されません。 以下のコマンドを実行して、シンボリックリンクがまだ存在するかどうかを確認します。 

sudo ls -l /etc/systemd/system/multi-user.target.wants/mysql*

リンクが存在しません： 

Outputls: cannot access /etc/systemd/system/multi-user.target.wants/mysql*: No such file or directory

必要に応じて、サーバーを再起動してください。 MySQLは起動しません。

次に、サービスを有効にします。 

sudo systemctl enable mysqld.service

リンクが戻ってきます： 

sudo ls -l /etc/systemd/system/multi-user.target.wants/mysql*
Outputlrwxrwxrwx 1 root root 38 Aug  1 04:43 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service

（以前に再起動した場合は、MySQLを再起動する必要があります。）

ご覧のとおり、systemdサービスを有効または無効にすると、デフォルトのターゲットのwantsディレクトリからシンボリックリンクが作成または削除されます。

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] ===ステップ5—クラッシュ時のMySQL起動動作のテスト

MySQLは現在、クラッシュ後に自動的に起動します。 それを無効にする方法を見てみましょう。

エディターでMySQLサービスユニットファイルを開きます。 

sudo nano /etc/systemd/system/multi-user.target.wants/mysqld.service

ヘッダー情報の後、ファイルの内容は次のようになります。

/etc/systemd/system/multi-user.target.wants/mysqld.service

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
User=mysql
Group=mysql

# Execute pre and post scripts as root
PermissionsStartOnly=true

# Needed to create system tables etc.
ExecStartPre=/usr/bin/mysql-systemd-start pre

# Start main service
ExecStart=/usr/bin/mysqld_safe

# Don't signal startup success before a ping works
ExecStartPost=/usr/bin/mysql-systemd-start post

# Give up if ping don't get an answer
TimeoutSec=600

Restart=always
PrivateTmp=false

パート1で見たように、Restartパラメーターの値はalwaysに設定されます（sshdの場合、これはon-failureのみに設定されました）。 これは、MySQLサービスがクリーンまたはクリーンでない終了コードまたはタイムアウトで再起動することを意味します。

man page for systemd serviceは、再起動パラメーターの次の表を示しています。

再起動設定/終了原因 no 常に 成功 失敗時 オン-異常 中絶 オンウォッチドッグ

終了コードまたはシグナルをクリーンアップする

X

X

汚れた終了コード

X

X

汚れた信号

X

X

X

X

タイムアウト

X

X

X

ウォッチドッグ

X

X

X

X

systemdサービスユニットファイルでは、2つのパラメータ（RestartとRestartSec）がクラッシュ動作を制御します。 最初のパラメーターはサービスをいつ再起動するかを指定し、2番目のパラメーターは再起動するまで待機する時間を定義します。

Restartディレクティブをコメントアウトし、ファイルを保存して、エディターを終了します。 これにより、再起動動作が無効になります。

/etc/systemd/system/multi-user.target.wants/mysqld.service

# Restart=always

次に、systemdデーモンをリロードしてから、mysqldサービスを再起動します。 

sudo systemctl daemon-reload
sudo systemctl restart mysqld.service

次に、次のコマンドを実行して、サービスのメインPIDを見つけます。 

sudo systemctl status mysqld.service
Output. . .
Main PID: 11217 (mysqld_safe)

kill -9コマンドを使用して、独自の番号を使用してメインPIDを強制終了します。 

sudo kill -9 11217

sudo systemctl status mysqld.serviceを再度実行すると、サービスが失敗したことが示されます。 

sudo systemctl status mysqld.service
Outputmysqld.service - MySQL Community Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
   Active: failed (Result: signal) since Sun 2015-06-21 02:28:17 EDT; 1min 33s ago
  Process: 2566 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 2565 ExecStart=/usr/bin/mysqld_safe (code=killed, signal=KILL)
  Process: 2554 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 2565 (code=killed, signal=KILL)

Jun 21 02:20:09 test-centos7 systemd[1]: Starting MySQL Community Server...
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Logging to '/var/log/mysqld.log'.
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Jun 21 02:20:10 test-centos7 systemd[1]: Started MySQL Community Server.
Jun 21 02:28:16 test-centos7 systemd[1]: mysqld.service: main process exited, code=killed, status=9/KILL
Jun 21 02:28:17 test-centos7 systemd[1]: Unit mysqld.service entered failed state.

サービスステータスを数回検索してみてください。サービスが失敗したと表示されるたびに。

そのため、サービスが停止して戻ってこないクラッシュをエミュレートしました。 これは、サービスを再起動しないようにsystemdに指示したためです。

ここで、mysqld.serviceユニットファイルを再度編集し、Restartパラメータのコメントを解除して保存し、systemctlデーモンをリロードして、最後にサービスを開始すると、以前の状態に戻るはずです。

これは、クラッシュ後に自動起動するようにネイティブsystemdサービスを構成する方法です。 サービスユニットファイルの[Service]セクションの下にRestart（およびオプションでRestartSec）のディレクティブを追加するだけです。

結論

これが、Linuxがサービスの起動を処理する方法です。 System V、Upstart、およびsystemd initプロセスがどのように機能し、リブートまたはクラッシュ後のサービスの自動開始とどのように関連するかを見てきました。

Upstart構成ファイルまたはsystemdユニットファイルの宣言構文は、不可解なSystem V initスクリプトを改良したものです。

独自のLinux環境で作業する場合は、ディストリビューションのバージョンを確認し、サポートしているinitデーモンを確認してください。

どこでサービスを有効にし、どこで無効にするかを考えることは価値があります。 ほとんどの場合、サードパーティのアプリケーションやネイティブのLinuxデーモンについては何も変更する必要はありません。 独自のサービスベースのアプリケーションを作成する場合にのみ、それらのスタートアップとリスポーンの動作について考える必要があります。

Related