+`の下にあるものを使用します。+`の適切なディレクトリの下にそのサービスユニットファイルのシンボリックリンクが作成されます。system`の下にある同じ名前のファイルへのシンボリックリンクです。systemd初期化シーケンス:ターゲットユニット特別なタイプのユニットファイルは、_ターゲットユニット_です。ターゲットユニットのファイル名には、「+。+」という接尾辞が付きます。ターゲットユニットは特定のリソースを表すものではないため、他のユニットファイルとは異なります。それらはいつでもシステムの状態を表します。ターゲットユニットは、その状態の一部である複数のユニットファイルをグループ化して起動することでこれを行います。Vランレベルと大まかに比較できますが、それらは同じではありません。各ターゲットには、番号ではなく名前があります。+」などで起動すると、基本的にサーバーはランレベル2、3、または4になります。これは、ネットワーキングが有効なマルチユーザーテキストモードです。サーバーをどのようにしてその段階に移行させるかが違いがあります。Vとは異なり、systemdはサービスを順番に起動しません。途中で、他のサービスまたはリソースの存在を確認し、それらのロードの順序を決定できます。これにより、サービスを並行してロードできます。Vでは、Linuxシステムが1つのランレベルにしか存在できないことです。ランレベルを変更できますが、システムはその新しいランレベルにのみ存在します。systemdでは、ターゲットユニットを「包括的」にすることができます。これは、ターゲットユニットがアクティブになると、他のターゲットユニットがその一部としてロードされることを意味します。`がアクティブになります。+`も自動的にロードおよびアクティブになります。Vの用語では、ランレベル3と5を同時にアクティブにするようなものです。)以下の表では、ランレベルとターゲットを比較しています。+`はデフォルトのランレベルと同等です。`というファイルでデフォルトのランレベルが定義されていました。`に置き換えられます。system`ディレクトリの下にあります。system`の下にあるターゲットユニットファイルの1つへのシンボリックリンクです。デフォルトのターゲットを変更すると、基本的にそのシンボリックリンクを再作成し、システムのランレベルを変更します。Vのinittabファイルは、Linuxがinitスクリプトを実行するディレクトリも指定しました。dディレクトリのいずれかです。systemdでは、デフォルトのターゲットユニットが、ブート時にロードされるリソースユニットを決定します。これらのユニットはすべてアクティブになりますが、すべてが並列にまたはすべて順番に実行されるわけではありません。リソースユニットのロード方法は、それが_wants_または_requires_する他のリソースユニットによって異なります。systemd依存関係:欲しいものと必要なものユニットファイルとターゲットユニットに関するこの議論の理由は、systemdがデーモン間の依存関係に対処する方法を強調するためです。前に見たように、Upstartは構成ファイルを使用してサービスの並列読み込みを保証します。Vでは、特定のランレベルでサービスを開始できますが、別のサービスまたはリソースが利用可能になるまで待機させることもできます。同様に、systemdサービスを作成して1つ以上のターゲットをロードしたり、別のサービスまたはリソースがアクティブになるまで待つことができます。systemdでは、別のユニットを必要とするユニットは、必要なユニットがロードされてアクティブになるまで起動しません。最初のユニットがアクティブな間に何らかの理由で必要なユニットが故障すると、最初のユニットも停止します。考えてみると、これによりシステムの安定性が保証されます。したがって、特定のディレクトリが存在する必要があるサービスは、そのディレクトリへのマウントポイントがアクティブになるまで待機することができます。他のユニットを_wants_するユニットは、そのような制限を課しません。発信者がアクティブなときに目的のユニットが停止しても停止しません。これの例は、グラフィカルターゲットモードで起動する非必須サービスです。systemdの例systemdでのMySQLの起動時の動作について詳しく説明します。7ドロップレットに戻りましょう。SSHコマンドを使用してサーバーに接続します(WindowsユーザーはPuTTyなどのツールを使用して接続できます)。protected]ステップ2-default.targetファイルと依存関係の確認これは長いセクションです。+」ウサギトレイルをたどっていくためです。systemdの起動シーケンスは、依存関係の長いチェーンに従います。+`ファイルは、通常のサーバー起動中に開始するサービスを制御します。次のコマンドを実行して、デフォルトのターゲットユニットファイルをリストします。/etc/systemd/system/default.targetこれにより、次のような出力が表示されます。`の下のマルチユーザーターゲットファイルへのシンボリックリンクです。+`で起動することになっています。+`ファイル_wants_のすべてのサービスを確認します。/etc/systemd/system/multi-user.target.wants/*.serviceこれにより、次のような出力が表示されます。+`の下にある実際のユニットファイルを指し示しています。multi-user.target`の一部であることがわかります。このコマンドを実行して出力をフィルタリングすると、同じ情報が見つかります。+`などのさまざまなタイプのターゲットがあります。マルチユーザーターゲットが依存するターゲットを確認するには、次のコマンドを実行します。+」を最初にロードする必要があります。+`が依存する他のターゲットを確認するには、次のコマンドを実行します。-10出力は次のようになります。sysinit.target`に必要なユニットがあるかどうかを確認できます。-10これにより、sysinitが必要とする多くのサービスが表示されます。.ご覧のとおり、システムは1つのターゲットのみにとどまりません。ターゲット間を移行するときに、依存する方法でサービスをロードします。手順3-ユニットファイルの確認さらに一歩進んで、サービスユニットファイルの内部を見てみましょう。このチュートリアルのパート1でMySQLサービスユニットファイルを確認しました。使用しますが、ここでは別のサービスユニットファイル、sshdのファイルを開きます。$MAINPIDKillMode=processRestart=on-failureRestartSec=42s[Install]WantedBy=multi-user.targetUpstartデーモンの構成ファイルと同じように、このサービスユニットファイルはクリーンでわかりやすいものです。これは、システムおよびネットワークターゲットと監査ログサービスが読み込まれた後に、SSHDサービスを読み込む必要があることを示しています。+」によって_wanted_であることも示しています。ターゲットはこのサービスをロードしますが、sshdが失敗してもシャットダウンまたはクラッシュしません。+`がデフォルトのターゲットであるため、sshdデーモンはブート時に起動することになっています。エディターを終了します。ステップ4-起動時のMySQL起動動作のテストチュートリアルのパート1では、MySQLサービスを有効にして実行したままにしました。それを変更する方法を見てみましょう。`に必要であることを確認するコマンドを実行しました。/の下の元のサービスユニットを指すシンボリックリンクが見つかりました。次のコマンドを実行してサービスを無効にし、起動時に自動起動しないようにします。multi-user.target`で必要かどうかを確認します。mysql何も返されません。以下のコマンドを実行して、シンボリックリンクがまだ存在するかどうかを確認します。directory必要に応じて、サーバーを再起動してください。MySQLは起動しません。次に、サービスを有効にします。/usr/lib/systemd/system/mysqld.service(以前に再起動した場合は、MySQLを再起動する必要があります。+`ディレクトリにシンボリックリンクが作成または削除されます。ステップ5-クラッシュ時のMySQL起動動作のテストMySQLは現在、クラッシュ後に自動的に起動します。それを無効にする方法を見てみましょう。エディターでMySQLサービスユニットファイルを開きます。/etc/systemd/system/multi-user.target.wants/mysqld.serviceヘッダー情報の後、ファイルの内容は次のようになります。+`のみに設定されました)。これは、MySQLサービスがクリーンまたはクリーンでない終了コードまたはタイムアウトで再起動することを意味します。systemdサービスのマニュアルページには、再起動パラメータに関する次の表が示されています。+-がクラッシュ動作を制御します。最初のパラメーターはサービスをいつ再起動するかを指定し、2番目のパラメーターは再起動するまで待機する時間を定義します。Restartディレクティブをコメントアウトし、ファイルを保存して、エディターを終了します。これにより、再起動動作が無効になります。+`サービスを再起動します。mysqld.service次に、次のコマンドを実行して、サービスのメインPIDを見つけます。+`コマンドを使用して、独自の番号を使用してメインPIDを強制終了します。+`を再度実行すると、サービスが失敗したことが表示されます。systemd[1]:サービスステータスを数回検索してみてください。そのたびに、サービスが失敗として表示されます。そのため、サービスが停止して戻ってこないクラッシュをエミュレートしました。これは、サービスを再起動しないようにsystemdに指示したためです。+`パラメーターのコメントを外して保存し、systemctlデーモンをリロードし、最後にサービスを開始すると、以前の状態に戻るはずです。これは、クラッシュ後に自動起動するようにネイティブsystemdサービスを構成する方法です。+)の追加ディレクティブを追加することです。結論これが、Linuxがサービスの起動を処理する方法です。initプロセスがどのように機能し、リブートまたはクラッシュ後のサービスの自動開始とどのように関連するかを見てきました。initスクリプトを改良したものです。独自のLinux環境で作業する場合は、ディストリビューションのバージョンを確認し、サポートしているinitデーモンを確認してください。どこでサービスを有効にし、どこで無効にするかを考えることは価値があります。ほとんどの場合、サードパーティのアプリケーションやネイティブのLinuxデーモンについては何も変更する必要はありません。独自のサービスベースのアプリケーションを作成する場合にのみ、それらのスタートアップとリスポーンの動作について考える必要があります。