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

前書き

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

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

Systemv、Upstart、systemdの3つの異なるinitモードからこれを行う方法を見ました。 最初のチュートリアル

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

前提条件

このチュートリアルに従うには、https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-aで作成した3つのDigitalOcean Dropletsが必要です。 -crash-or-reboot-part-1-practical-examples [before]。

我々は持っていた:

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

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

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

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

また、rootユーザーになるか、サーバーでsudo特権を持っている必要があります。 sudo特権がどのように機能するかを理解するには、https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file-on-ubuntu-and-centos [このsudoに関するDigitalOceanチュートリアル]を参照してください。

本チュートリアルのコマンド、クエリ、設定を本番Linuxサーバーで実行しないでください。

ランレベル

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

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

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

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

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

  • *ランレベル0:*システムのシャットダウン

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

  • *ランレベル2、3、4:*ネットワークが有効なマルチユーザー、テキストモード

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

  • *ランレベル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 *には1のPIDがあります。 これは、システムがオンラインになったときに生成される他のすべてのプロセスの親です。

初期化の歴史

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

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

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

初期化スクリプトは、rc(コマンドの実行)スクリプトとも呼ばれます。

ディレクトリ構造

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

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

`+ / etc `ディレクトリ内には、名前に数字が入った多数の ` rc +`ディレクトリがあります。

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

次に、各 `+ rc.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 / rc.d `ディレクトリの下のファイルを呼び出します。 したがって、サーバーがランレベル2で起動すると、 ` / etc / rc2.d `の下のスクリプトが呼び出されます。ランレベル3では、 ` / etc / rc3.d +`の下のスクリプトが実行されます。

`+ rc +`ディレクトリ内では、最初にすべてのKスクリプトが「stop」の引数で数値順に実行され、次にすべてのSスクリプトが「start」の引数で同様の方法で実行されます。 initシェルスクリプトは、それぞれstopパラメーターとstartパラメーターで呼び出されます。

これで、 `+ / etc / rc.d `ディレクトリ( ` K `および ` S +`ファイル)の下のファイルはシンボリックリンクのみであるため、それらを呼び出すことは、停止パラメーターと開始パラメーターで実際のinitシェルスクリプトを呼び出すことを意味します。

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

System Vの自動起動

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

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

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

システムVの例

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

ステップ1-Debianドロップレットへのログイン

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

ステップ2-inittabを見る

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

cat /etc/inittab | grep initdefault

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

Output

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

cat /etc/inittab | grep Runlevel

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

Output# Runlevel 0 is halt.
# Runlevel 1 is single-user.

# Runlevel 6 is reboot.

ステップ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  13 Jul 23  2012 S02ssh -> ../init.d/ssh
. . .

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

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

ステップ4-初期化スクリプトを見る

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

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

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

cat /etc/init.d/mysql | less

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

ステップ5-chkconfigまたはsysv-rc-confの使用

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

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

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

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

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

sudo sysv-rc-conf

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

image:https://assets.digitalocean.com/articles/auto-starting-2/drQB0Hx.jpg [各ランレベルのさまざまなサービスのXマークを表示するsysv-rc-confウィンドウ]

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

今のところ、「+ Q +」を押して画面を閉じます。

ステップ7-起動時のMySQL起動動作のテスト

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

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

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 02mysql -> ../init.d/mysql
. . .

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

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

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

sudo update-rc.d mysql enable

ステップ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            1  0 07:30 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql        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
sudo kill -9

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 +`に追加の行を追加した理由です。これは、クラッシュ時に再起動するようにSystem Vサービスを構成する方法です。 https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-にこの行の構文の詳細な説明がありますor-reboot-part-1-practical-examples#step-4-%E2%80%94-configuring-mysql-to-auto-start-after-crash [パート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 +`スクリプトはネイティブのSystem Vサービスを管理するためにまだ実行されています

新興イベント

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は、命名基準が「+ .conf +」の_service configuration_ファイルを使用します。

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

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

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

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

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

  • サービスがクラッシュした場合に_respawn_する必要があるかどうか

ディレクトリ構造

Upstart設定ファイルは、 `+ / etc / init `ディレクトリの下にあります( ` / etc / init.d +`と混同しないでください)。

アップスタートの例

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

ステップ1-Ubuntuドロップレットへのログイン

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

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

ステップ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 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

ステップ3-Upstartファイルの確認

このチュートリアルのパート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ファイルの作成に関する実用的なヘルプについては、https://www.digitalocean.com/community/tutorials/the-upstart-event-system-what-it-is-and-how-to-use-it [this Upstartに関するチュートリアル]。

ステップ4-起動時のMySQL起動動作のテスト

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

Upstartでは、サービスの無効化は、「。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]

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

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

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

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

ステップ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 MySQLを表示します。

Outputmysql start/running, process

MySQLのインスタンスのPIDに注意してください。 今、 `+ mysql`プロセスをクラッシュした場合、自動的に起動することはありません。 プロセスOFを強制終了します(独自の番号に置き換えます)。

sudo kill -9

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

sudo initctl status mysql
Outputmysql stop/waiting

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

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples [チュートリアルのパート1]には、 `+ respawn +`ディレクティブのより詳細な説明があります。

systemdの概要

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

その機能の1つは、Linuxの_system and service manager_として機能することです。 この能力において、systemdが制御することの1つは、サービスがクラッシュまたはマシンがリブートした場合のサービスの動作です。 systemdの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がサービスデーモンだけでなく、ソケット、デバイスオペレーティングシステムパス、マウントポイント、ソケットなどの他のタイプのリソースの初期化も担当することです。 リソースはこれらのいずれかです。

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

各ユニットファイルは特定のシステムリソースを表し、「。」という命名スタイルを持っています。

したがって、 + dbus.service、` + sssd.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 +」という接尾辞が付きます。 ターゲットユニットは特定のリソースを表すものではないため、他のユニットファイルとは異なります。 むしろ、それらはいつでもシステムの状態を表します。

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

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

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

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

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

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

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

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

Runlevel (System V init) Target Units (Systemd)

runlevel 0

poweroff.target

runlevel 1

resuce.target

runlevel 2, 3, 4

multi-user.target

runlevel 5

graphical.target

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

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

systemdの例

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

ステップ1-CentOS Dropletへのログイン

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

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

ステップ2-default.targetファイルと依存関係の確認

これは長いセクションです。可能な限り「+ .target +」ウサギトレイルをたどっていくためです。 systemdの起動シーケンスは、依存関係の長いチェーンに従います。

  • default.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 / `の下のマルチユーザーターゲットファイルへのシンボリックリンクです。 したがって、システムはランレベル3に似た ` multi-user.target +`で起動することになっています。

  • 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/
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`に必要なユニットがあるかどうかを確認できます。 ありません。 しかし、 `+ 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つのターゲットのみにとどまりません。 ターゲット間を移行するときに、依存する方法でサービスをロードします。

手順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デーモンはブート時に起動することになっています。

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

ステップ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 +`ディレクトリにシンボリックリンクが作成または削除されます。

ステップ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


PrivateTmp=false

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

systemdサービスのマニュアルページには、再起動パラメータに関する次の表が示されています。

Restart settings/Exit causes no always on-success on-failure on-abnormal on-abort on-watchdog

Clean exit code or signal

X

X

Unclean exit code

X

X

Unclean signal

X

X

X

X

Timeout

X

X

X

Watchdog

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:  (mysqld_safe)

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

sudo kill -9

`+ 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:  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]:
Jun 21 02:28:17 test-centos7 systemd[1]:

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

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

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

これは、クラッシュ後に自動起動するようにネイティブsystemdサービスを構成する方法です。 私たちがしなければならないことは、サービスユニットファイルの + [Service] +`セクションの下に `+ Restart +(およびオプションで + RestartSec +)の追加ディレクティブを追加することです。

結論

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

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

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

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