詳細なCentOS7 / RHEL7 systemd

CentOS7 / RHEL7systemdの詳細な説明

なぜsystemd
（1）Linuxサービス管理について
（2）SysVinitの長所と短所
（3）UpStartの改善
（4）systemdの誕生
（5）systemdがすぐに起動できる理由
SysVinitの概要
（1）SystemVとは
（2）SysVinitの実行レベル
（3）SysVinit実行シーケンス
（4）SysVの初期化とシステムのシャットダウン
（5）SysVinitの管理および制御機能
systemdの機能
（1）systemdはどのような問題を解決しますか？
（2）systemdに関する論争はどこにありますか？
（3）systemdはサービスプロセスをより完全に終了できます
CentOS7のシステム機能
（1）ソケットサービスはアクティブなままです
（2）プロセス間通信はアクティブな機能を維持します
（3）デバイスはアクティブな機能を維持します
（4）ファイルパスをアクティブに保つ
（5）システム状態のスナップショット
（6）マウントおよび自動マウントポイント管理
（7）ライトニングパラレルスタート
（8）ユニットロジックシミュレーションチェック
（9）SysVinitとの下位互換性
systemdの起動速度を分析および測定する方法
（1）各サービスで消費された詳細な起動時間を表示する
（2）時間のかかるサービスツリー表を見る
（3）分析図やその他のコマンドを印刷する
CentOS 7systemdは下位互換性があります
（1）Systemdは、実行レベルのサポートが制限されています。
（2）systemdは、initスクリプトのようなパーソナライズされたコマンドをサポートしていません。
（3）systemdは、systemdから開始されていないサービスとの通信をサポートしていません。
（4）systemdは実行中のサービスのみを停止できます
（5）標準出力機器からシステムサービス情報を読み取ることができません。
（6）systemdはコンテキストを継承しません。
（7）SysVinitスクリプトの依存関係
（8）タイムアウトメカニズム
システムサービス管理
（1）ユニットとは
（2）systemdのサービス管理
（3）サービスの詳細を表示する
systemdターゲットを使用する
（1）ターゲットが必要とするプロセスサービスを知る方法は？
（2）ターゲットおよび実行レベル
（3）ターゲット管理
システムをシャットダウン、一時停止、休止状態にする
systemdを介してリモートシステムを管理する
systemdユニットファイルを作成および変更する
（1）ユニットファイルの概要
（2）ユニットファイルの構造を理解する
（3）カスタムユニットファイルを作成する
（4）emacs.serviceの例を作成します。
（5）2番目のsshdサービスの例を作成します
（6）既存のユニットファイルを変更する
（7）拡張されたデフォルトのユニット構成ファイル構成
ユニットのインスタンス化
VNCサーバー構成

**1. なぜsystemd **

（1）Linuxサービス管理について

Linuxシステムの起動からサービスの提供までのプロセスは次のようになります。最初にマシンの電源がオンになり、次にGRUBがMBRまたはUEFIを介してロードされ、次にカーネルが開始され、カーネルがサービスを開始し、次に外部サービスが開始されます。
SysV init UpStart systemdは、主にサービスブート管理の問題を解決します。
ヒント：systemdのスペルに関しては、正式な用語はsystemdであり、SyetemdでもsystemDでもありません。

（2）SysVinitの長所と短所

SysV initは最も初期のソリューションであり、さまざまな実行レベルを分割し、さまざまなサービスセットを開始することに依存しています。サービスはスクリプトによって制御され、順次実行されます。
SysVinitソリューションの利点は次のとおりです。
原理はシンプルで理解しやすいです。
シェルスクリプト制御に依存しているため、サービススクリプトを作成するためのしきい値は比較的低くなっています。
弱点は次のとおりです。
サービスは順番に開始され、起動プロセスは比較的遅いです。
必要に応じてサービスを開始することはできません。たとえば、通常USBフラッシュドライブを挿入したい場合は、USBで制御するサービスを開始できるため、システムリソースを節約できます。

（3）UpStartの改善

システムサービスのプラグアンドプレイを解決するために、UpStartが誕生しました。CentOS6システムでは、SysV initとUpStartが共存し、UpStartは主にサービスのプラグアンドプレイを解決します。サービスシーケンスの開始が遅いという問題。UpStartのソリューションは、関連するサービスをグループ化することです。グループ内のサービスは順番に開始され、グループは並行して開始されます。

（4）systemdの誕生

SysV initサービスの起動が遅いことは、これまで問題ではありませんでした。特に、Linuxシステムは主にサーバーシステム上にあり、年に1回再起動することはめったにありませんでした。一部のサーバーは、光ハードウェアを検出するのに5分以上かかり、システムの起動は比較的高速です。
ただし、モバイルインターネットの出現により、SysVinitサービスの起動が遅いという問題がますます顕著になっています。多くのモバイルデバイスはAndroidなどのLinuxカーネルに基づいています。モバイルデバイスは頻繁に起動し、起動するたびにサービスが順番に開始されるのを待たなければなりませんが、これは明らかに受け入れられません。Systemdはこの問題を解決するために生まれました。
systemdのデザインアイデアは次のとおりです：
できるだけ早くサービスを開始してください。
システムリソースの占有を可能な限り減らします。

（5）systemdがすぐに起動できる理由

Systemdは、順次実行されるSysV initとは異なり、並列方式を使用してサービスを開始するため、システムの起動時間を大幅に節約します。
並列起動の場合、最大の問題はサービス間の依存関係を解決することです。systemdのソリューションは、バッファープールのようなアプローチを使用することです。たとえば、TCPに依存するサービスは、開始時に依存サービスのTCPポートをチェックします。Systemdは最初にTCPポートの要求をキャッシュします。依存サーバーが開始されると、サービスに要求を渡して2つのサービスを作成します。コミュニケーション。プロセス間通信のD-BUSの同じ原理は同じです。ディレクトリのマウントは、サービスにディレクトリが最初にマウントされたと認識させ、次にディレクトリが実際にアクセスされたときに実際の操作を実行することです。

2. SysVinitの概要

SysV initは、systemVスタイルのinitシステムです。名前が示すように、SystemVシリーズUNIXから派生しています。 BSDスタイルのinitシステムよりも柔軟性があります。これは、数十年にわたって人気があり、さまざまなLinuxディストリビューションで採用されているUNIXinitシステムです。

（1）SystemVとは

SystemVは、かつてAT＆T SystemVとも呼ばれ、Unixオペレーティングシステムの多くのバージョンの1つです。もともとはAT＆Tによって開発され、1983年に最初にリリースされました。 SystemVの合計4つのメジャーバージョンがリリースされました：バージョン1、2、3、および4。 SystemV Release4、またはSVR4は最も成功したバージョンであり、システムの起動とシャットダウンを制御するために使用される「SysV初期化スクリプト」（/etc/init.d）、SystemVインターフェイス定義（SVID）などのいくつかの一般的なUNIX機能のソースになっています。）は、SystemVがどのように機能するかの標準的な定義です。

（2）SysVinitの実行レベル

SysV initは、ランレベルという用語を使用して「サブスクライブされた実行モード」を定義します。 SysV initは、「/ etc / inittab」ファイルに「initdefault」の項目があるかどうかを確認します。デフォルトの動作モードがあるかどうかをinitシステムに通知します。デフォルトの動作モードがない場合、ユーザーはシステムコンソールに入り、どの動作モードに入るかを手動で決定します。
SysV initの動作モードは、システムのさまざまなサブスクリプションの動作モードを記述します。通常、8つの動作モードがあります。つまり、動作モード0〜6とSまたはsです。
Linuxディストリビューションごとに、動作モードの定義が異なります。しかし、0、1、および6は、全員一致で合意されています。
0 シャットダウン
1 シングルユーザーモード
6 リブート
さまざまな動作モードの動作範囲は、通常、/ etc / inittabファイルで定義されます。たとえば、RedHatは実行レベル3と5を定義します。実行モード3は、システムを文字インターフェイスのシェルモードに初期化します。実行モード5は、システムをGUIモードに初期化します。コマンドラインインターフェイスまたはGUIに関係なく、操作モード3および5は、他の操作モードと比較して完全で正式な操作状態であり、コンピューターはユーザーが必要とするタスクを完了することができます。モード1、Sなどは、システム障害後のトラブルシューティングとリカバリによく使用されます。
明らかに、これらの異なる動作モードでは、システムは実行中のプロセスを初期化する必要があり、初期化の準備は異なります。たとえば、動作モード3ではXシステムを起動する必要はありません。ユーザーは、入力する必要のあるモードを指定するだけでよく、SysV initは、このモードに必要なすべての初期化作業を実行する責任があります。

（3）SysVinit実行シーケンス

SysV initは、スクリプト、ファイル命名ルール、およびソフトリンクを巧みに使用して、さまざまな実行レベルを実現します。まず、SysVinitは/ etc / inittabファイルを読み取る必要があります。このファイルの内容を分析すると、次の構成情報が取得されます。
システムが入力する必要のある実行レベル。
キーの組み合わせの定義をキャプチャします。
電源障害/復元スクリプトを定義します。
gettyと仮想コンソールを起動します。
構成情報を取得した後、SysV initは次の手順を順番に実行して、システムをスケジュールされたrunlevelXに初期化します。
/etc/rc.d/rc.sysinit
/etc/rc.d/rcおよび/etc/rc.d/rcX.d/（Xは実行レベル0〜6を表します）
/etc/rc.d/rc.local
XDisplayManager（必要な場合）

1 ）Rc.sysinitスクリプト関数

まず、rc.sysinitを実行して、いくつかの重要なシステム初期化タスクを実行します。 RedHatのRHEL5（RHEL6はUpStartを使用）では、rc.sysinitは主に次のタスクを完了します。
udevとselinuxをアクティブ化します。
/etc/sysctl.confで定義されているカーネルパラメータを設定します。
システムクロックを設定します。
キーマップをロードします。
スワップパーティションをアクティブにします。
ホスト名（ホスト名）を設定します。
ルートパーティションのチェックと再マウント。
RAIDおよびLVMデバイスをアクティブ化します。
ディスククォータをオンにします。
すべてのファイルシステムを確認してマウントします。
期限切れのロックとPIDファイルをクリアします。

2 ）Rc.dスクリプト

上記の作業が完了すると、SysVinitは/etc/rc.d/rcスクリプトの実行を開始します。さまざまな実行レベルに応じて、rcスクリプトは実行レベル（Xは実行レベル）に対応するrcX.dディレクトリを開き、このディレクトリに格納されているすべての起動スクリプトを見つけて実行します。各runlevelXにはそのようなディレクトリがあり、ディレクトリ名は/etc/rc.d/rcX.dです。
これらのディレクトリには、さまざまなスクリプトが保存されています。ファイル名がSで始まるスクリプトは、起動時に実行する必要のあるスクリプトです。Sに続く番号は、これらのスクリプトの実行順序を定義します。 /etc/rc.d/rcX.dディレクトリ内のスクリプトは、実際にはいくつかのソフトリンクファイルであり、実際のスクリプトファイルは/etc/init.dディレクトリに保存されます。次のように：
rc5.dディレクトリ内のスクリプト

[ root@www~]#ll/etc/rc5.d/
lrwxrwxrwx1rootroot16Sep42008K02dhcdbd->../init.d/dhcdbd
....( 省略)....
lrwxrwxrwx1rootroot14Sep42008K91capi->../init.d/capi
lrwxrwxrwx1rootroot23Sep42008S00microcode_ctl->../init.d/microcode_ctl
lrwxrwxrwx1rootroot22Sep42008S02lvm2-monitor->../init.d/lvm2-monitor
....( 省略)....
lrwxrwxrwx1rootroot17Sep42008S10network->../init.d/network
....( 省略)....
lrwxrwxrwx1rootroot11Sep42008S99local->../rc.local
lrwxrwxrwx1rootroot16Sep42008S99smartd->../init.d/smartd
....( 以下は省略)....

すべての初期化スクリプトが実行されたとき。 SysV initは、/ etc / rc.d /rc.localスクリプトを実行します。
rc.localは、Linuxがユーザーに設定のパーソナライズを任せる場所です。設定したいものをここに置いて、個人的に開始することができます。通常、LinuxServerのユーザーは複数いるため、これがこの考慮事項の理由です。

（4）SysVの初期化とシステムのシャットダウン

SysV initは、システムの初期化だけでなく、システムのシャットダウンも担当します。システムがシャットダウンされるとき、データの一貫性を確保するために、注意深く完了し、順番にクリーンアップする必要があります。
たとえば、ファイルシステムの読み取りと書き込みを行うサービスを停止してから、ファイルシステムをアンマウントする必要があります。そうしないと、データが失われます。
この順序の制御は、/ etc / rc.d / rcX.d /ディレクトリ内のすべてのスクリプトの命名規則によっても制御されます。このディレクトリ内のKで始まるすべてのスクリプトは、システムのシャットダウン時に呼び出されます。文字K次の番号は、実行の順序を定義します。
これらのスクリプトは、サービスまたはその他のシャットダウンタスクを安全に停止する役割を果たします。

（5）SysVinitの管理および制御機能

さらに、システムの起動後、管理者は開始されたプロセスを管理および制御する必要もあります。 SysV initパッケージには、他のすべてのプログラムの起動、操作、およびシャットダウンを制御するための一連のツールが含まれています。
停止するとシステムが停止します。
initは、SysV init自体のinitプロセスエンティティであり、pid1として実行され、すべてのユーザープロセスの親プロセスです。主な機能は、/ etc / inittabファイルを使用して起動プロセス中にプロセスを作成することです。
killall5は、システムVのkillallコマンドです。自分のセッションプロセス以外のプロセスに信号を送信するため、現在使用中のシェルを強制終了することはできません。
最後に、/ var / log / wtmpファイル（または-fオプションで指定されたファイル）をさかのぼって、このファイルが作成されてからのすべてのユーザーのログインステータスを示します。
Lastbの効果はlastと同じです。デフォルトでは、/ var / log / btmpファイルを使用して、失敗したすべてのログイン試行を表示します。
mesgは、他のユーザーのユーザー端末へのアクセスを制御します。
pidofは、プログラムのプロセス識別番号（pid）を見つけて、それを標準出力デバイスに出力します。
poweroffは、shutdown-h–pまたはtelinit0と同じです。システムをシャットダウンし、電源を遮断します。
再起動はshutdown-rまたはtelinit6と同じです。システムを再起動します。
runlevelは、システムログインレコードファイル（通常は/ var / run / utmp）を読み取り、以前および現在のシステム実行レベルを標準出力デバイスに出力します。
シャットダウンは安全な方法でシステムを終了します。ログインしているすべてのユーザーは、システムが終了しようとしているという通知を受け取り、新しいログインは許可されません。
suloginは、システムがシングルユーザーモードに入るときにinitによって呼び出されます。ブートローダーによって渡された-bオプションを受信すると、initはsuloginも呼び出します。
Telinitは実際にはinitの接続であり、単一文字のパラメーターと信号をinitに送信するために使用されます。
utmpdumpは、/ var / run / utmpファイルの内容をユーザーフレンドリーな形式で標準出力デバイスに表示します。
wallは、情報権限を持つすべてのログインユーザーにメッセージを送信します。
さまざまなLinuxディストリビューションが、これらのSysV init基本ツールに基づいて、initシステムの管理を簡素化するためのいくつかの補助ツールを開発しました。たとえば、RedHatのRHELは、SysV initに基づいてinitscriptsパッケージを開発しました。これには、多数の起動スクリプト（rc.sysinitなど）が含まれ、service、chkconfig、さらにはinitシステムを管理するための一連のグラフィカルインターフェイスなどのコマンドラインツールも提供されます。。他のLinuxディストリビューションにも、SysV initの管理を簡素化するために、独自のinitscriptまたは他の名前のinitパッケージがあります。
SysV initのメカニズムを理解している限り、SysV initのみを使用する最も単純なシステムでは、スクリプトを直接呼び出してサービスを開始および停止し、手動でinittabを作成し、ソフト接続を作成してこれらのタスクを完了することができます。したがって、SysVinitの基本的な原則とコマンドを理解することが最も重要です。独自の管理ツールのセットを開発することもできます。

**3. systemd **の機能

（1）systemdはどのような問題を解決しますか？

システムリソースの消費を削減するために、オンデマンドでサービスを開始します。
システム起動の待機時間を短縮するために、プロセスを可能な限り並行して開始します。
サービス構成だけでなく、一貫した構成環境を提供します。
特定の時点でサービスステータスを復元できるサービスステータスのスナップショットを提供します。

（2）systemdに関する論争はどこにありますか？

systemdは、一貫した構成環境を提供しようとします。サービス構成だけでなく、システム構成の他の側面も、これはsystemdの野心でもあり、この目標を達成するために、systemdを犠牲にしてLinuxシステムの構成を統合することを望んでいることに注意してください。 SysVinitとBSDシステムの互換性。 systemdはLinuxカーネルAPIをフルに活用し、BSDシステムをサポートしなくなりました。これは現在、オープンソースコミュニティにおけるsystemdの最大の議論です。
個人的には、これは良いことです。管理者にとって、スクリプトを作成するために、さまざまなディストリビューションでさまざまな構成を学習したり、さまざまな判断を下したり、さまざまなヘアスタイルを判断したりする必要はありません。運用と保守の自動化の前提条件は標準化です。標準化を自動化できる場合にのみ、systemdはこの方向に大きな一歩を踏み出すことができます。 systemdの学習コストでさえ比較的高いです。

（3）systemdはサービスプロセスをより完全に終了できます

デーモンプロセスはサービスになるために2回フォークするため、プロセス番号が変更されます。UpStartがプロセスを終了すると、間違ったプロセス番号が検出され、サービスが停止しない場合があります。
さらに特殊なケースがあります。プロセスが子プロセスを生成する場合、子プロセスはそれ自体で2回フォークし、メインプロセスを終了します。このような子プロセスを終了するために、UpStartはstraceを使用してフォークと終了の呼び出しを追跡します。このメソッドとても難しい。
Systemdはカーネルの最新機能を利用し、CGroupを使用してこの問題を解決します。CGroupのプロセスはツリー型であるため、サービスが新しい子プロセスを開始する方法に関係なく、これらの関連プロセスはすべて同じCGroupに属します。Systemdは指定されたものをトラバースするだけで済みます。 CGroupは、関連するすべてのプロセスを正しく検索し、それらを1つずつ停止できます。

4. CentOS7のシステム機能

（1）ソケットサービスはアクティブなままです

システムが起動すると、systemdはソケットアクティベーション機能をサポートするすべてのサービスのリスニングポートを作成します。サービスが起動すると、これらのサービスにソケットを渡します。この方法では、起動時にサービスを並行して開始できるだけでなく、サービスの再起動中にサービスへの接続要求が失われないようにすることもできます。サービスポートへの要求は予約され、キューに保存されます。

（2）プロセス間通信はアクティブな機能を維持します

クライアントアプリケーションがD-Busを介したプロセス間通信を初めて要求すると、systemdは対応するサービスをすぐに開始します。 systemdは、プロセス間通信を使用して、D-Bus構成ファイルに従ってアクティブな機能を維持します。

（3）デバイスはアクティブな機能を維持します

特定のハードウェアが挿入されると、systemdは対応するハードウェアサービスサポートを開始します。 systemdは、ハードウェアサービスユニット構成ファイルに従って、いつでもハードウェアをアクティブ化したままにします。

（4）ファイルパスをアクティブに保つ

特定のファイルまたはパスのステータスが変更されると、systemdは対応するサービスをアクティブにします。 systemdは、パスサービスユニット構成ファイルに従ってサービスがアクティブ化されることを保証します。

（5）システム状態のスナップショット

systemdは、現在のすべてのユニット構成ファイルを一時的に保存したり、以前のスナップショットからユニット構成ファイルを復元したりできます。現在のシステムサービスステータスを保存するために、systemdはユニットファイルのスナップショットを動的に生成できます。

（6）マウントおよび自動マウントポイント管理

systemdは、マウントポイントと自動マウントポイントを監視および管理し、マウントポイントのユニット構成ファイルに従ってマウントします。

（7）ライトニングパラレルスタート

ソケットはアクティブな機能を維持するため、systemdを並行して起動できるため、ソケット監視サービスによってシステムの起動時間が大幅に短縮されます。

（8）ユニットロジックシミュレーションチェック

ユニットがアクティブ化または非アクティブ化されると、systemdは従属線を計算し、一時的なシミュレーションチェックを生成し、整合性を検証します。それらに一貫性がない場合、systemdはそれらを自動的に修正し、エラーを報告する重要でないタスクを削除しようとします。

（9）SysVinitとの下位互換性

systemdは、SysV initLinux標準の基本的なコア仕様スクリプトを完全にサポートしています。このようなスクリプトは、systemdサービスユニットに簡単にアップグレードできます。

5. システムの起動速度を分析および測定する方法

systemd-analyzeは、起動時のパフォーマンスを分析するためのツールであり、起動時のサービス時間の消費を分析するために使用されます。デフォルトのディスプレイブートは、カーネルとユーザースペースによって消費される時間です。

[ root@localhost~]#systemd-analyze
Startupfinishedin818ms(kernel)+6.240s(initrd)+32.979s(userspace)=40.038s

systemd-analyzetimeコマンドを使用するのと同じ効果があります。

（1）各サービスで消費された詳細な起動時間を表示する

systemd-analyzeblameコマンドを使用して、各サービスで消費された詳細な起動時間を表示します。

[ root@localhost~]#systemd-analyzeblame
30.852 siscsi.service
16.994 skdump.service
10.871 sboot.mount
...
103 mssystemd-sysctl.service
101 msdatapool.mount

（2）時間のかかるサービスツリー表を見る

systemd-analyzecritical-chainコマンドは、起動にかかった時間に従ってソートされた、非常に時間がかかるサービスのツリーのようなテーブルを出力します。時間がかかるほど、最初にランク付けされます。 @の後の時間はサービスのアクティブ化または起動時間であり、+記号の後の時間はサービスの起動に費やされた時間です。個人的な理解@は、システムの起動からサービスの起動までの時間であり、相対的な時間消費です。+は、サービスの起動で消費される時間であり、絶対的な時間消費です。

[ root@localhost~]#systemd-analyzecritical-chain
Thetimeaftertheunitisactiveorstartedisprintedafterthe"@"character.
Thetimetheunittakestostartisprintedafterthe"+"character.
[email protected]
└─[email protected]+16.994s
└─[email protected]
└─[email protected]+54ms
└─[email protected]+535ms
└─[email protected]
└─[email protected]
└─[email protected]
└─[email protected]
└─[email protected]+2ms
└─[email protected]+67ms
└─[email protected]
└─[email protected]+10.871s
└─systemd-fsck@dev-disk-by\x2duuid-8c77568b\x2d7e51\x2d4e32\x2dbbdf\[email protected]+226ms
└─[email protected]+152ms
└─[email protected]+25ms

（3）分析チャートおよびその他のコマンドを印刷する

systemd-analyzeplotは、サービス消費スケジュールをsvg形式で出力します。これは、ブラウザーを介してグラフィカルに表示できます。これは非常に直感的です。

[ root@localhost~]#systemd-analyzeplot>plot.svg

その他のパラメーター：
systemd-analyzedotは、セパレータを使用して現在のサービスを生成します
systemd-analyzedumpは、現在のサービスステータスをわかりやすい方法で表示します
6 Systemdファイルタイプと保存場所
systemd構成ファイルはユニットユニットと呼ばれ、タイプに応じて異なる拡張子で終わります。
. サービスシステムサービス;
. システムサービスのグループをターゲットにします。
. 自動マウント自動マウントポイント。
. デバイスカーネルが認識できるデバイス。
. マウントマウントポイント;
. パスファイルシステムのファイルまたはディレクトリ。
. スコープ外で作成されたプロセス。
. スライスは、階層的な管理システムプロセスのグループです。
. スナップショットシステムサービスステータス管理。
. ソケットプロセス間通信ソケット。
. swapは、スワップファイルまたはデバイスを定義します。
. timerはタイマーを定義します。

6. CentOS 7systemdは下位互換性があります

systemdは、SysV initおよびUpstartと可能な限り下位互換性があるように設計されています。以下は、以前のメジャーバージョンのRHELと互換性がなくなった部分の一部です。

（1）Systemdは、実行レベルのサポートが制限されています。

互換性を維持するために、systemdは特定の数のターゲットユニットを提供します。これは、実行レベルに直接対応するか、初期の分散実行レベルコマンドでサポートできます。すべてのターゲットを実行レベルにマップできるわけではありません。この場合、runlevelコマンドを使用すると、不明な実行レベルNが返される可能性があるため、RHEL7でrunlevelコマンドを使用しないことをお勧めします。

（2）systemdは、initスクリプトのようなパーソナライズされたコマンドをサポートしていません。

SysV initのサーバースクリプトは実際にはシェルスクリプトであり、コマンドパラメータは実際にはシェルスクリプトであるため、SysV initスクリプトは、start、stop、statusなどのいくつかの標準コマンドパラメータに加えて、必要に応じて必要なパラメータをサポートし、パラメータを通じて追加機能を提供できます。シェルのサブ機能。たとえば、RHEL6のiptablesサービススクリプトは、パニックコマンドラインパラメータを実行できます。このパラメータを使用すると、システムはすぐに緊急モードに入り、すべての着信および発信データパケットを破棄できます。ただし、このようなコマンドラインパラメータはsystemdではサポートされていません。Systemdは、構成ファイルでのコマンドラインパラメータの指定のみをサポートしています。

（3）systemdは、systemdから開始されていないサービスとの通信をサポートしていません。

systemdがサービスを開始すると、追跡を容易にするためにプロセスのメインIDが保存されます。systemctlツールはプロセスPIDを使用して、サービスを照会および管理します。逆に、ユーザーがコマンドラインから特定のサービスを開始した場合、systemctlコマンドには、サービスが稼働しているか実行されているかを判別する方法がありません。

（4）systemdは実行中のサービスのみを停止できます

RHEL6以前のバージョンでは、システムをシャットダウンするプログラムが開始されると、RHEL6システムは、サービスが実行されているかどうかに関係なく、/ etc / rc0.d /の下にあるすべてのサービススクリプトのシャットダウン操作を実行します。また、systemdは実行中のサービスのみを閉じることができるため、シャットダウン時間を大幅に節約できます。

（5）標準出力機器からシステムサービス情報を読み取ることができません。

systemdがサービスを開始すると、ユーザーの邪魔にならないように、標準の出力情報が/ dev / nullに送信されます。

（6）systemdはコンテキストを継承しません。

systemdは、HOMEの環境変数や、ユーザーまたはセッションのPATHなどのコンテキストを継承しません。各サービスはクリーンなコンテキストを取得します。

（7）SysVinitスクリプトの依存関係

systemdがSysVinitスクリプトを開始すると、systemdが実行されているときに、LinuxStandardBase（LSB）Linux標準ライブラリヘッダーファイルからサービス依存関係情報を読み取り、継承します。

（8）タイムアウトメカニズム

システムがスタックするのを防ぐために、すべてのサービスには5分のタイムアウトメカニズムがあります。

7. システムサービス管理

（1）ユニットとは

RHEL7より前は、サービス管理はSysV initまたはUpStartによって、/ etc / rc.d /init.dの下のスクリプトを介して分散および管理されていました。これらのスクリプトは、管理者がサービスのステータスを制御できるようにする従来のBashスクリプトです。 RHEL7では、これらのスクリプトはサービスユニットファイルに置き換えられています。
systemdでは、サービスやマウントなどのリソースをまとめてユニットと呼びます。そのため、systemdには多くのユニットタイプがあります。サービスユニットファイルの拡張子は.serviceで、スクリプトの機能に似ています。たとえば、サービスを表示、開始、停止、再起動、有効化、または無効化するためのパラメータがあります。
systemdユニットファイルを配置します。
/ usr / lib / systemd / system / systemdデフォルトのユニットファイルインストールディレクトリ
/ run / systemd / systemsystemdは、systemdユニットの実行時に作成されます。このディレクトリは、次のディレクトリよりも優先されます
/ etc / systemd / systemシステム管理者によって作成および管理されるユニットディレクトリが最も優先されます。

（2）systemdのサービス管理

systemclコマンドを使用してサービスを制御できます。serviceコマンドとchkconfigコマンドは引き続き使用できますが、主に互換性の理由から、可能な限り避ける必要があります。
systemctlコマンドを使用する場合、サービス名の拡張子を完全に書き込むことができます。次に例を示します。
systemctl stop bluuetooth.service
たとえば、無視することもできます。
systemctl stop bluetooth
Systemctlで一般的に使用されるコマンド：
サービスを開始しますsystemctlstart name.service
サービスsystemctlstopname.serviceをシャットダウンします
サービスを再起動しますsystemctlrestar tname.service
サービスが実行されている場合にのみ、サービスを再起動しますsystemctl try-restart name.service
サービス構成ファイルsystemctlrelaodname.serviceをリロードします
サービスの動作ステータスを確認しますsystemctlstatusname.serviceまたはsystemctlis-active \ name.service
すべてのサービスステータスの詳細を表示するsystemctllist-units--type service --all
サービスがsystemctlenablename.serviceを開始できるようにします
サービスの起動を無効にするsystemcltname.serviceを無効にする
サービスの起動ステータスsystemctlstatusname.serviceまたはsystemctl \を確認してください
is-enabled name.service
すべてのサービスを一覧表示し、systemctl list-unit-files --typeserviceを開始するかどうかを確認します

（3）サービスの詳細を表示する

次のコマンドを使用して、サービスを一覧表示します。
systemctl list-units --type service
デフォルトでは、アクティブなサービスのみが一覧表示されます。すべてのサービスを表示する場合は、-allまたは-aパラメーターを使用します。
systemctl list-units--type service --all
起動時にセットアップできるサービスを確認したい場合は、次のコマンドを使用します。
systemctl list-unit-files --type service
サービスの詳細を表示するには、次のコマンドを使用します。
systemctl status name.service
サービス情報キーワード説明
Loadedサービスがロードされ、ユニットファイルの絶対パスが表示され、ユニットファイルが使用可能であることが示されます。
アクティブなサービスが実行されており、開始時刻情報があります。
メインPIDは、プロセス名と一致するPID、およびメインプロセスPIDです。
ステータスサービスの添付情報。
関連するプロセスの添付情報。
CGroupプロセスのCGroup情報。

8. systemdターゲットを使用

（1）ターゲットが必要とするプロセスサービスを知る方法は？

たとえば、ターゲットユニットmulti-user.targetで有効になっているサービスを理解する場合は、次のコマンドを使用します。

$systemctlshow-p"Wants"multi-user.target
Wants=rc-local.serviceavahi-daemon.servicerpcbind.serviceNetworkManager.serviceacpid.servicedbus.serviceatd.servicecrond.serviceauditd.servicentpd.serviceudisks.servicebluetooth.serviceorg.cups.cupsd.servicewpa_supplicant.servicegetty.targetmodem-manager.serviceportreserve.serviceabrtd.serviceyum-updatesd.serviceupowerd.servicetest-first.servicepcscd.servicersyslog.servicehaldaemon.serviceremote-fs.targetplymouth-quit.servicesystemd-update-utmp-runlevel.servicesendmail.servicelvm2-monitor.servicecpuspeed.serviceudev-post.servicemdmonitor.serviceiscsid.servicelivesys.servicelivesys-late.serviceirqbalance.serviceiscsi.service

Wantsに加えて、WantedBy、Requires、RequiredBy、Conflicts、ConflictedBy、Before、Afterなどのさまざまな形式の依存情報と依存情報を表示することもできます。

（2）ターゲットおよび実行レベル

RHEL7より前のバージョンでは、実行レベルは特定の動作モードを表すために使用されていました。実行レベルは、0から6までの数字で表される7つのレベルとして定義され、各レベルは特定のサービスを開始できます。 RHEL7は、basicを実行する代わりにtargetを使用します。
systemdターゲットは、ターゲットユニットファイルの説明を使用します。ターゲットユニットファイルの拡張子は.targetです。ターゲットユニットファイルの唯一の目的は、一連の依存関係を通じて他のsystemdユニットファイルをまとめることです。たとえば、graphical.targetユニットは、グラフィカルセッションを開始するために使用されます。Systemdは、GNOMEディスプレイ管理（gdm.service）、アカウントサービス（axxounts-daemon）などのサービスを開始し、multi-user.targetユニットをアクティブ化します。同様のmulti-user.targetユニットは、必要なNetworkManager.serviceおよびdbus.serviceサービスを開始し、basic.targetユニットをアクティブ化します。
RHEL7は、以前の実行レベルとは多少異なるいくつかのターゲットを事前に定義しています。互換性のために、systemdは、SysVinitの実行レベルにマップされたいくつかのターゲットも提供します。具体的な対応情報は次のとおりです。
0 runlevel0.target、poweroff.targetはシステムをシャットダウンします。
1 runlevel1.target、rescue.targetはレスキューモードに入ります。
2 runlevel2.target、multi-user.targetは、非グラフィカルインターフェイスのマルチユーザーモードに入ります。
3 runlevel3.target、multi-user.targetは、非グラフィカルインターフェイスのマルチユーザーモードに入ります。
4 runlevel4.target、multi-user.targetは、非グラフィカルインターフェイスのマルチユーザーモードに入ります。
5 runlevel5.target、graphical.targetは、グラフィカルインターフェイスのマルチユーザーモードに入ります。
6 runlevel6.target、reboot.targetはシステムを再起動します。

（3）ターゲット管理

1 ）次のコマンドを使用して、現在使用可能なターゲットを表示します。

systemctl list-units --type target

現在の操作を変更するには、基本的に次のコマンドを使用します。

systemctl isolate name.target

2 ）デフォルトの実行レベルを変更します
systemctl get-defaultコマンドを使用して、デフォルトの実行レベルを取得します。

[ root@localhost~]#systemctlget-default
multi-user.target

systemctl set-default name.targetを使用して、デフォルトの実行中の基本を変更します

[ root@localhost~]#systemctlset-defaultgraphical.target
rm'/etc/systemd/system/default.target'
ln-s'/usr/lib/systemd/system/graphical.target''/etc/systemd/system/default.target'

3 ）レスキューモードと緊急モード
systemctlrescueを使用してレスキューモードに入ります。レスキューモードにさえ入ることができない場合は、緊急モードに入ることができます。

systtmctl emergency

緊急モードは、システムの修復を容易にするために小規模システム環境に入ります。緊急モードのルートディレクトリは読み取り専用でマウントされ、ネットワークはアクティブ化されず、いくつかのサービスのみが開始され、緊急モードに入るにはルートパスワードが必要です。

9. システムをシャットダウン、一時停止、休止状態にする

RHEL7では、systemctlを使用して一連の電源管理コマンドを置き換えます。元のコマンドは引き続き使用できますが、できるだけ使用しないことをお勧めします。 systemctlとこれらのコマンドの対応する関係は次のとおりです。
hatl、systemctlhaltシステムを停止します
poweroff、systemctl poweroffはシステムをシャットダウンし、システムの電源をシャットダウンします。
再起動、systemctl再起動システムを再起動します
pm-suspend、systemctlsuspendでシステムを一時停止します
pm-hibernate、systemct lhibernate hibernation system
pm-suspend-hybrid、systemctl hybrid-sleepシステムを一時停止し、休止状態にします

**10. systemd **を介してリモートシステムを管理する

ローカルシステムを管理できるだけでなく、systemdはリモートシステムも制御できます。リモートシステムは主にSSHプロトコルを介して管理されます。SSHがリモートシステムに接続できることを確認するだけです。systemctlコマンドの後に-Hまたは--hostパラメータを追加し、さらにリモートシステムを追加します。 ipまたはホスト名で十分です。

11. systemdユニットファイルの作成と変更

（1）ユニットファイルの概要

ユニットファイルには、ユニットの指示と動作情報が含まれています。バックグラウンドでは、systemctlコマンドはユニットファイルを処理します。ジョブを適切かつ正しく実行するには、システム管理者がユニットファイルを手動で編集できる必要があります。通常、システム管理者が手動で作成したユニットファイルは、/ etc / systemd / system /ディレクトリに保存することをお勧めします。
ユニット構成ファイルの形式は次のとおりです。

unit_name.type_extension

ここで、unit_nameはユニット名を表し、type_extensionはユニットタイプを表します。
ユニットファイルは、追加ファイルとしてディレクトリの下に配置できます。たとえば、sshd.serviceサービスをカスタマイズするために、sshd.service.d / custom.confファイルを作成し、ファイルにいくつかのカスタム構成を作成できます。
同様に、sshd.service.wants /およびsshd.service.requires /ディレクトリを作成できます。これらのディレクトリには、sshdサービス関連サービスのソフト接続が含まれています。システムがインストールされると、これらのソフト接続は自動または手動で作成できます。
多くのユニット構成ファイルは、ユニット指定子（ワイルドカード文字列）を使用できます。ワイルドカード文字列は、ユニットファイルの起動時に変数に動的に置き換えることができます。これにより、いくつかの一般的なユニット構成テンプレートを作成できます。

（2）ユニットファイルの構造を理解する

一般的なユニットファイルには、次の3つのセクションがあります。
[ [ユニット]セクションには、ユニットタイプに依存しない一般的なオプションが含まれています。これらの選択により、ユニットの説明、ユニットの動作の確認、ユニットの構成、および他のユニットの依存関係が提供されます。
[ unittype]セクションでは、ユニットに特定のタイプの命令がある場合、これらの命令はunittypeセクションにグループ化されます。たとえば、サービスユニットファイルには、頻繁に使用されるサービス構成を含む[サービス]セクションが含まれています。
[ [インストール]セクションには、systemctlenableまたはdisableコマンドのインストール情報が含まれています。
1 ）[ユニット]セクションオプション
説明ユニットの説明情報。これらのテキスト情報は、systemclstatusコマンドで出力されます。
ドキュメンテーションユニット内のドキュメンテーション情報のURL。
これらのユニットの後に開始するように定義された後、このユニットは指定されたユニットが開始された後にのみ開始されます。特定のユニットを明示的にアクティブ化しないRequiresオプションとは異なり、Beforeオプションには逆の機能があります。
Required構成ユニットの依存関係、Requiresオプションのユニットを一緒にアクティブ化する必要があります。一方のユニットが起動に失敗した場合、他のユニットは起動されません。
WantsはRequiresオプションの依存関係よりもはるかに弱いです。リスト内のユニットが起動に失敗しても、他のユニットには影響しません。これは、カスタムユニットの依存関係を確立するための推奨される方法です。
Conflictsは、Requiresの反対であるユニット競合関係を定義します。
2 ）[unittype]タイプが[Service]の場合のオプション
タイプ起動時のハイブプロセスのタイプ。実行機能と関連オプションに影響します。オプションのキーワードは次のとおりです。
単純なデフォルト値、サービスのプロセスとメインプロセスが一緒に開始されます。
フォークプロセスはサービスメインプロセスの子プロセスとして開始され、親プロセスは完全に開始された後に終了します。
ワンショットはシンプルに似ていますが、ユニットの起動後にプロセスが終了します。
Dbusは単純に似ていますが、ユニットの起動後にメインプロセスのみがD-BUS名を取得します。
Notifyはsimpleに似ていますが、ユニットの起動後、sd_notify（）関数によってメインメッセージが送信されます。
アイドルは単純に似ており、プロセスのバイナリプログラムの実際の実行は、主にサービスステータスとシェルの混合出力を回避するために、すべてのユニットのタスクが完了するまで遅延されます。
ExecStartは、ユニットを起動するコマンドまたはスクリプトを指定し、ExecStartPreセクションとExecStartPostセクションは、ExecStartの前後に実行されるユーザー定義スクリプトを指定します。 Type = oneshotを使用すると、順番に実行する複数のユーザー定義コマンドを指定できます。
ExecStopは、ユニットが停止したときに実行されるコマンドまたはスクリプトを指定します。
ExecReloadは、ユニットがリロードされたときに実行されるコマンドまたはスクリプトを指定します。
再起動オプションが許可されている場合、サービスが再起動するとプロセスが終了し、systemctlコマンドを使用してクリアおよび再起動操作が実行されます。
RemainAfterExitがtrueに設定されている場合、すべてのプロセスが終了した場合でも、サービスはアクティブであると見なされます。デフォルト値はfalseです。このオプションは、Type = oneshotの場合にのみ構成する必要があります。
3 ）[インストール]セクションオプション
エイリアスは、ユニットの空間的に分離された追加の名前を提供します。
RequiredByユニットは、一連の必須の依存ユニットを実行でき、RequiredByリストはRequireから依存情報を取得します。
WantByユニットは、必要な弱依存ユニットの実行を許可され、WantbyはWantリストから依存情報を取得します。
また、ユニットが取り付けられているか、ユニットを補助していることも示します。
DefaultInstanceインスタンスユニットの制限。このオプションは、ユニットがデフォルトインスタンスの実行を許可されるかどうかを指定します。
4 ）後置サービスの例：
ユニットファイルは/usr/lib/systemd/system/postifix.serviceにあり、内容は次のとおりです。

[ Unit]
Description=PostfixMailTransportAgent
After=syslog.targetnetwork.target
Conflicts=sendmail.serviceexim.service
[ Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfixstart
ExecReload=/usr/sbin/postfixreload
ExecStop=/usr/sbin/postfixstop
[ Install]
WantedBy=multi-user.target

（3）カスタムユニットファイルを作成する

次のシナリオでは、カスタムユニットファイルが必要です。
自分でデーモンを作成したいと思っています。
既存のサービスの2番目のインスタンスを作成します。
SysVinitスクリプトを導入します。
一方、既存のユニットファイルを変更する必要がある場合もあります。
次に、ユニットファイルを作成する手順について説明します。
1 ）カスタムサービスの実行ファイルを準備します。
実行可能ファイルは、ソフトウェアプロバイダーのスクリプトまたはプログラムにすることができます。必要に応じて、カスタムサービスのメインプロセス用にPIDファイルを準備して、PIDが変更されないようにします。さらに、すべてのスクリプトに実行可能な属性があり、対話を必要としないようにするために、環境変数を構成するスクリプトが必要になる場合があります。
2 ）/ etc / systemd / system /ディレクトリにユニットファイルを作成し、rootユーザーのみが編集できるようにします。

touch/etc/systemd/system/name.servicechmod664/etc/systemd/system/name.service

このファイルには実行権限は必要ありません。
3 ）name.serviceファイルを開き、サービス構成を追加します。さまざまな変数を構成する方法は、追加するサービスのタイプによって異なります。以下は、ネットワークサービスに依存する構成例です。

[ Unit]
Description=service_description
After=network.target
[ Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile
[ Install]
WantedBy=default.target

4 ）新しいサービスが追加されたことをsystemdに通知します。

systemctldaemon-reload
systemctlstartname.service

（4）emacs.serviceの例を作成します。

1 ）ファイルを作成し、正しい権限を確認します。

~]# touch/etc/systemd/system/emacs.service
~]# chmod664/etc/systemd/system/emacs.service

2 ）構成情報を追加します。

[ Unit]
Description=Emacs:theextensible,self-documentingtexteditor
[ Service]
Type=forking
ExecStart=/usr/bin/emacs--daemon
ExecStop=/usr/bin/emacsclient--eval"(kill-emacs)"
Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=always
[ Install]
WantedBy=default.target

3 ）systemdに通知し、サービスを開始します。

~]# systemctldaemon-reload
~]# systemctlstartemacs.service

（5）2番目のsshdサービスの例を作成します

1 ）sshd_configファイルをコピーします

]# cp/etc/ssh/sshd{,-second}_config

2 ）sshd-second_configファイルを編集し、22220のポートとPIDファイルを追加します。

Port22220
PidFile/var/run/sshd-second.pid

他のパラメータを変更する必要がある場合は、ヘルプをお読みください。
3 ）ユニットファイルのコピー：

~]# cp/usr/lib/systemd/system/sshd{,-second}.service

4 ）ユニットファイルsshd-second.serviceを編集します
説明フィールドを変更します
Description=OpenSSHserversecondinstancedaemon
Afterキーワードの後にsshd.serviceサービスを追加します。
After=syslog.targetnetwork.targetauditd.servicesshd.service
sshdkeyの作成を削除します。
ExecStartPre = / usr / sbin / sshd-keygenこの行を削除します
実行スクリプトで、2番目のsshdサービスの構成ファイルを追加します。
ExecStart=/usr/sbin/sshd-D-f/etc/ssh/sshd-second_config$OPTIONS
変更されたsshd-second.serviceファイルの内容は次のとおりです。

[ Unit]
Description=OpenSSHserversecondinstancedaemon
After=syslog.target network.targe tauditd.service sshd.service
[ Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config$OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[ Install]
WantedBy=multi-user.target

5 ）SELinuxを使用してtcpポートを追加すると、2番目のsshdサービスを担当するポートのバインドが拒否されます。

~]# semanage port -a -tssh_port_t -p tcp22220

6 ）ブートとテストを設定します。

~]# systemctl enable sshd-second.service
~] $ssh -p 22220 user@server

ファイアウォールポートも開いていることを確認してください。

（6）既存のユニットファイルを変更する

systemdユニット構成ファイルはデフォルトで/ usr / lib / systemd / system /ディレクトリに保存されます。システム管理者は、このディレクトリ内のファイルを直接変更することはお勧めしません。カスタマイズされたファイルは/ etc / systemd / system /ディレクトリにあります。拡張子がある場合必要に応じて、次のソリューションを使用できます。
ディレクトリ/etc/systemd/system/unit.d/を作成します。これが最も推奨される方法です。最初のユニットファイルを参照し、添付ファイル構成ファイルを介してデフォルト構成を拡張すると、デフォルトユニットファイルのアップグレードが自動的に行われます。アップグレードとアプリケーション。
元の構成ファイルのコピーを/ usr / lib / systemd / system /から/ etc / systemd / system /にコピーしてから、変更します。コピーされたバージョンは元の構成を上書きします。このメソッドは追加の構成パッケージを追加できず、追加の機能を必要としないシナリオで使用されます。
デフォルトの構成ファイルに復元する必要がある場合は、/ etc / systemd / system /の下の構成ファイルを削除するだけで、マシンを再起動せずに、次のコマンドを使用して変更を適用するだけです。

systemctl daemon-reload

demo-reloadオプションは、すべてのユニットファイルをリロードし、依存関係を再作成します。これは、ユニットファイルの変更をすぐに適用する必要がある場合に使用されます。さらに、次のコマンドを使用して同じ目的を達成することもできます。

init q

また、変更が実行中のサービスのユニットファイルである場合は、サービスを再起動する必要があります。

systemct lrestart name.service

（7）拡張されたデフォルトのユニット構成ファイル構成

デフォルトのユニットファイル構成を拡張するには、/ etc / systemd / system /の下にディレクトリを作成し、rootとして次のようなコマンドを実行する必要があります。

mkdir/etc/systemd/system/name.service.d

作成したディレクトリの下に構成ファイルを作成します。構成ファイルは.confファイルで終わる必要があります。
たとえば、次の内容のカスタム依存関係ファイルを作成します。

[ Unit]
Requires=new_dependency
After=new_dependency

別の例として、再起動時に、メインプロセスが終了してから30秒後に再起動するように構成できます。構成例は次のとおりです。

[ Service]
Restart=always
RestartSec=30

一度に1つの小さなファイルのみを生成することをお勧めします。各ファイルは、1つの機能の完成にのみ焦点を当てているため、構成ファイルを簡単に削除したり、他のサービスペアの構成ディレクトリにリンクしたりできます。
今すぐ変更を適用するには、rootを使用して次の操作を実行します。

systemctldaemon-reload
systemctlrestartname.service

例：httpd.serviceサービス構成を拡張する
httpdサービスの開始時にユーザー定義スクリプトを実行するには、httpdユニット構成ファイルを変更し、次の手順を実行する必要があります。最初に、カスタムファイルディレクトリとカスタムファイルを作成します。

~]# mkdir/etc/systemd/system/httpd.service.d
~]# touch/etc/systemd/system/httpd.service.d/custom_script.conf

カスタムファイルの場所が/usr/local/bin/custom.shであると想定して、次の情報をcustom_script.confカスタムスクリプトに追加します。

[ Service]
ExecStartPost=/usr/local/bin/custom.sh

変更を適用する：

~]# systemctldaemon-reload
~]# systemctlrestarthttpd.service

12. ユニットのインスタンス化

実行時に、テンプレートを複数のユニットにインスタンス化する必要がある場合があります。@文字は、テンプレートとユニットファイルの関係を識別するために使用されます。インスタンス化ユニットは、別のユニットファイルからのもの（RequiresまたはWantsオプションを使用）、またはsystemctlstartコマンドを使用できます。インスタンス化されたサービスユニットには、次のような名前を付けることができます。

template_name@instance_name.service

複数のインスタンスが、同じテンプレートファイル構成オプションのすべての一般的なインスタンスを指すことができます。たとえば、ユニット構成ファイルのウォンツオプションは次のようになります。

[email protected],[email protected]

まず、systemdに特定のサービスユニットを検索させます。見つからない場合、systemdは@とdotの間の部分を無視し、getty @ .serviceサービスファイルを直接検索し、構成を読み取り、サービスを開始します。
ユニット指定子と呼ばれるワイルドカードフィールドは、任意のユニット構成ファイルで使用できます。ユニット指定子は、実行時にいくつかのユニットパラメータと説明を置き換えます。一般的に使用されるユニット指定子は次のとおりです。
％nタイプのサフィックスを含むユニット名全体％Nは同じ意味ですが、ASCIIは禁止されている文字に置き換えられます。
％pは名前の前に付けます。インスタンス化するとき、％pは@文字の前の部分を表します。
％iインスタンス名、@文字、およびユニットタイプの直接の部分。％Iも同じ意味ですが、ASCIIは禁止されている文字に置き換えられています。
％Hホスト名、構成ファイルがロードされたときのホスト名。
rootユーザーの場合は現在実行中のディレクトリである％tランタイムディレクトリは/ runディレクトリであり、非特権ユーザーの場合はXDG_RUNTIME_DIR変数で指定されたディレクトリです。
たとえば、getty @ .serviceには次の構造が含まれています。

[ Unit]
Description=Gettyon%I
...[ Service]
ExecStart=-/sbin/agetty--noclear%I$TERM
...

[email protected]および[email protected]がインスタンス化されると、Description =は「GettyonttyA」および「GettyonttyB」として解釈されます。

13. VNCサーバー構成

インストール：

yum install tigervnc-server

構成：

（1）構成ファイルをコピーします。

~]# cp /lib/systemd/system/[email protected] \
/etc/systemd/system/[email protected]

（2）構成ファイルを編集します。

ExecStart=/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
PIDFile=/home/USER/.vnc/%H%i.pid

USERを、使用するVNCサービスのユーザー（rootなど）に置き換えます。

ExecStart=/sbin/runuser -l root -c "/usr/bin/vncserver %i"

解像度を変更する場合は、ジオメトリコンテンツを変更でき、変更する必要はありません。
次に、構成を保持します。

（3）systemctlコマンドを使用して、構成ファイルを強制的に再度読み取ります。

~]# systemctl daemon-reload

（4）vncserverパスワードを構成します

vncpasswd

（5）2人のユーザーが同時にvncを使用する場合は、2つの構成ファイルを構成する必要があります。
vncserver-USER_1 @ .serviceおよびvncserver-USER_2 @ .serviceの場合、ファイルの内容はrootユーザーの構成方法と同じです。
次に、2人のユーザーのvncパスワードを作成します。

~] $ su - USER_1
~] $ vncpasswd
Password:
Verify:~]$ su - USER_2
~] $ vncpasswd
Password:
Verify:

（6）vncサービスを開始します

systemctl start vncserver@:10

起動するには、次のコマンドを使用します。

systemctl enable vncserver@:10
ln -s '/etc/systemd/system/[email protected]' \
' /etc/systemd/system/multi-user.target.wants/vncserver@:10.service'

（7）プロセスを閉じます

systemctl disable vncserver@:display_number.service
systemctl stop vncserver@:display_number.service

**参照文書： **

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/index.html

https://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/