UNITファイルの調査
【調査前の漠然とした疑問】
・ExecStart
ExecStart→ラッパー→ラッパー→・・・→ラッパー→ELFバイナリ起動コマンド
としたときに、途中のラッパーが終了しないことにより、ELFバイナリ起動コマンドの親プロセスがsystemdではなく、途中のラッパーのままだった場合、systemdはELFバイナリ起動コマンドの状態を把握できるのか？
---【論点】---
子プロセスの死活は親からなら見える。
systemdになってから、親プロセスは孫プロセスの死活まで見えるのかどうか？
もし見えないのなら、pidファイルを作ってsystemdに教えて初めて制御できるのか？
もし見えるのなら、cgroupsな感じでsystemdはサービスのプロセスを観測＆制御するのか？
※dfコマンドの出力に「cgroup」っていっぱい出てくるのあれ何？
※systemdの「.slice」ファイルって何？
------------
・[Unit]、[Service]、[Install]
・起動の依存関係、順序性の設定（After、Wants、WantedBy）
・停止の依存関係、順序性の設定
・Type=forking、Type=simpleとは？
・PIDFileの設定の仕方
・ExecStartPre
・その他、サービスの起動/停止に関するいろいろなポイント
【調査方針】
ｓｙｓｔｅｍｄの役割はＯＳの多岐にわたるが、いまのところ下記の2つ役割
A.デーモンサービスの起動/停止/再起動
B.プロセス監視（主にpid管理）
に着目して、systemdの仕様、機能を調査し、設定について考察する。
※システム全体の起動/停止/再起動（デバイスチェック、デバイス初期化、リソース準備、システムサービスの起動など）については今回は考察しない。
※systemdが密結合による複雑さの増大により「想定外」を無限に副産している（win〇owsのような）ことなく、各方面に洗練された配慮がいきわたって至れり尽くせりなソリューションとなっていることを願う。
A.デーモンサービスの起動/停止/再起動
■システム起動/停止/再起動に伴うサービス自動起動/停止/再起動
※システム全体の要件、方式設計（スタンドアロンの場合、HAクラスタのメンバーの場合、負荷分散クラスタのメンバの場合など）、および詳細設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決められる。
１．システム起動/停止/再起動に伴うサービス自動起動/停止/再起動の要件
システム全体の要件、方式設計によりさまざまなバリエーションが考えられるが、サービス起動/停止/再起動は伝統的に自動化が期待されている
※ただし、ミッションクリティカルで複雑なシステム構成に含まれる一部のミドルウェアやサーバデーモンは、障害発生時または計画停止時に手動で停止/手動する構成/運用設計になっている場合がある。
２．systemdの設定
※systemdの役割範囲が決まった後にsystemdの設定値が決まる。
・スタンドアロンシステム起動/停止/再起動に伴うサービス自動起動/停止/再起動
伝統的に、OS側のinitサービスが利用されるが、下記の場合には考慮が必要な場合がある
- サーバ仮想化ハイパバイザ管理下のシステムの場合、ハイパバイザ側の機能や準仮想化ドライバの機能を考慮する
- デーモンサービスの起動/停止の順序性を考慮する
- デーモンサービスの起動/停止シーケンスの内容を考慮する
temporalyファイルとメモリの同期、トランザクション、セッション維持、タイミング、ロックファイル生成/削除、pidファイル生成/削除、デーモンサービスが複数の子プロセスや子スレッドから構成されている、時間のかかるIOの途中などを考慮する
- OSやサードパーティ製のエージェント（watchdog、監視エージェント、バックアップソフト、ジョブエージェント、ウイルス監視ソフト、その他運用管理エージェントなど）やカーネルモジュール（リアルタイムスキャナーなど）との連携をしている
- 特殊なデバイス構成、特殊なカーネルモジュールロード、あるいは特殊なシステムサービスの起動を伴うシステム構成の場合、とくにサービス起動/停止の依存性、順序性を考慮する
- カーネルのACPI機能を考慮する
- カーネルのAPIC機能を考慮する
- その他OSの特殊なブート方式を考慮する
iscsiブート、SANブート、その他BIOSあるいは初期RAMディスク内のドライバで認識できない（認識のために設定が必要な）デバイス上にシステムイメージが保存されてるブート、ネットワークブートなど
- UPSに接続された物理マシン上のOSの場合、UPS側の自動シャットダウン設定を考慮する
・HAクラスタや負荷分散クラスタ構成のシステム起動/停止/再起動に伴うサービス自動起動/停止/再起動は下記を考慮する。
- サーバ仮想化ハイパバイザ管理下のシステムの場合でかつ、ハイパバイザ側のHAクラスタ機能を使っている場合は、これらの機能と整合するように設定する。
- HAクラスタウェアや負荷分散クラスタウェア管理下のシステムの場合は、各クラスタウェアに委任する。
■障害からのサービス自動起動/停止/再起動
※システム全体の可用性要件とそれ以外の要件にもとづき設計された可用性方式設計（スタンドアロン、HAクラスタ、負荷分散クラスタなど）、およびその詳細設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決められる。
１．可用性要件
許容ダウンタイム、データ完全性などに対するSLAなどにもとづき決定される。
２．systemdの設定
※systemdの役割範囲が決まった後にsystemdの設定値が決まる。
・考えられる役割
- ダウンタイム低減
- データロスト防止
- 運用性保守性の向上
その他の要件、システム構成全体から考えて機能兼用、機能一元化を図る。
- 費用対効果との兼ね合い
・自動起動/停止タイプ「[service]のTypeディレクティブ？」
- システム起動停止と連動すること
- システム起動停止時以外のタイミングで手動停止/起動できること
- システム起動停止時以外のタイミングで停止したら自動起動させるかどうか（設計次第）
※冗長構成により設定内容が大きく異なる
・システム起動停止時以外のタイミングのデーモンサービス自動起動
下記①～③の場合でsystemdの役割分担は異なる。
①スタンドアロンの場合
- systemdの機能で再起動する（respawnなどの機能）
- OS側の他の機能で管理する（watchdogなど）
- システムブート時以外はとくに（あえて）自動起動しない
②HAクラスタのメンバーの場合
クラスタウェアの機能で管理するのでsystemdでは管理しない
③負荷分散クラスタのメンバの場合
クラスタウェアの機能で管理するのでsystemdでは管理しない
■手動によるサービス起動/停止/再起動
※システム全体の要件、方式設計（スタンドアロンの場合、HAクラスタのメンバーの場合、負荷分散クラスタのメンバの場合など）、および詳細設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決められる。
１．手動によるサービス起動/停止/再起動の要件
・サービスが自動起動/停止設計と設定がされていたとしても必ず手動によるサービスの停止/起動/再起動が必要となる場合が出てくる。
※特定のサービスだけダウンした場合の起動、障害の切り分けなど
２．systemdの設定
※systemdの役割範囲が決まった後にsystemdの設定値が決まる。
下記①～③の場合におけるsystemdのシステム全体の中での役割分担は？
systemd側の機能でどこまでやるか？
■負荷増減に伴うサービス自動起動/停止
※システム全体の拡張性性要件とそれ以外の要件にもとづき設計された拡張性方式設計（スタンドアロン、HAクラスタ、負荷分散クラスタなど）、およびその詳細設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決められる。
１．拡張性性要件
・費用対効果により決定される。
- 手動スケールアップ/スケールアウト、自動スケールアップ/スケールアウト
- 可用性要件と矛盾するのは本末転倒である。
２．systemdの設定
※systemdの役割範囲が決まった後にsystemdの設定値が決まる。
・負荷分散クラスタのメンバーの場合
・手動によるスケールアウトの場合
Ｂ．システム監視
※システム要件にもとづき設計されたシステム構成、システム全体の監視要件にもとづき設計された監視設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決められる
１．監視要件
※システム構成によりいろいろなバリエーションがある
①障害監視
②パフォーマンス監視
障害予兆の発見、障害時の異常値に対するベースライン取得、リリースやリプレイスで利用するパフォーマンス情報の取得、監査報告
③セキュリティ監視
２．監視方式設計
※システム構成および監視要件によりいろいろなバリエーションがある
※小規模システムの場合、ＯＳとデーモンが出力するログ監視と簡単な死活監視だけで監視系を構成する場合もある。
①監視項目
- 死活
サービス死活、プロセス死活、network疎通、プログラム異常終了
- リソース・パフォーマンス
- ログ
②監視方式
- 監視コンソール
配置場所、表示内容（網羅性、レイテンシ、）、機能（検索、ソート、フィルタ）、その他UI
- アラート通知
通知条件、即応性、内容、通知先、通知方法（メール発信、電話発信、ランプ点灯、・・・）
- 監視データ保管
保管期間、検索速度、機能（レポート作成サポート、アーカイブ化）
- 統合性
他の監視項目（ハードウェア監視、ネットワーク監視、・・・）、他の運用システム（ジョブ管理、デプロイ管理、バックアップ管理、・・・）
３．監視詳細設計
※システム構成、監視要件および監視方式設計によりいろいろなバリエーションがある。
- サードパーティ製の監視ソフトで管理する
監視エージェントにイベントをpush
監視マネージャからポーリングさせる
- systemdの機能を使う
- systemdのログに出力するだけ（ログ監視エージェントやsyslogｄに委ねる）
４．systemdの設定
※システム構成、監視要件、監視方式設計、および監視詳細設計がまずあって、その中でゲストOS内のsystemdの役割範囲が決まり、systemdの設定値が決まる。
【systemdの要件】
下記の２つ役割に関して
A.デーモンサービスの起動/停止/再起動
B.プロセス監視（主にpid管理）
systemdの機能でまかなえる役割のバリエーションから、systemdに担わせる役割を決定することでsystemdの要件が決まる。
【systemdの設計】
systemdの要件からsystemdの詳細設計（パラメータの決定）を行う。
■.serviceファイル
[Unit]
After、Wants、
[Service]
Type、PIDFile、ExecStartPre、ExecStart、ExecReload、ExecStop、TimeoutSec、User、Environment
[Install]
WantedBy
■起動コマンド/スクリプト
■pidfile
→（編集中）systemd その7 UNITファイルの調査 その2
