Systemd

systemdは、システム管理を担うソフトウェア群であり、従来のSystem V initに代わって導入された仕組みである。デーモン・ライブラリおよび各種ユーティリティで構成され、システム管理・設定における中心的プラットフォームとして、2010年、RedHat社のエンジニアにより、Linux OS用に設計された。

著者によるとsystemdはオペレーティングシステムの「基本的な積木」であると評され、UNIX System VやBSDから継承されたLinuxのinitシステムを置き換えることを第一の目標としている。//systemd//という名前はファイル名の最後尾に//d//という文字を付けることでデーモンを区別しやすくするというUNIXの慣習を受け継いでいる。またこの名称は言葉遊びの側面もあり、フランスで最近よく言われている「システムD」という言葉に因んでいる。「システムD」とは、状況に迅速に適応し問題を即興で解決する個人の能力を意味する。

systemdはLinux用に設計され、Linux API専用にプログラミングされている。systemdはGNU Lesser General Public License  version 2.1以降という条件でフリーなオープンソースソフトウェアとして公表されている。

systemdの設計はフリーソフトウェアコミュニティにおける重要な論争の元となった。これはsystemdのアーキテクチャはUNIX哲学に反しており最終的に相互依存でがんじがらめの塊を作ってしまうと批評家達を主張させるようになっているためである。しかしながら2015年現在、主要なLinuxディストリビューションのほとんどはsystemdをデフォルトのinitシステムとして採用している。

1. 設計
-----

初期にsystemdを開発したソフトウェア技術者であるLennart PoetteringとKay Sieversはどうにかしてinitデーモンの効率をしのごうとした。彼らはシステムのブート中にたくさんの処理を並行または並列に行えるようにし、さらにシェルのオーバーヘッドを減少させるために、依存関係を表現できるようにそのソフトウェアフレームワークを改良したいと思っていた。

Poetteringはsystemdの開発を「決して終了せず決して完成しないが、技術の進歩を追い求める」ことと述べている。2014年5月にPoetteringはさらに進んで、systemdは以下の3つの一般的な機能を提供して「ディストリビューション間の無意味な違い」の統合を目指すものであると定義した:

システムとサービスマネージャ
ソフトウェアプラットフォーム
アプリケーションとLinuxカーネルとの接着剤systemdは単なるinitデーモンの名前ではなく、systemd}} initデーモンに加えjournald}}、logind}}およびnetworkd}}の各デーモンとそれ以外の多くの低レベルコンポーネントを含む、ソフトウェアバンドル全体を指している。2013年1月、Poetteringはsystemdは1つのプログラムではなく、69個の個別バイナリから成る巨大なソフトウェア一式だと述べた。systemdは統合されたソフトウェアスイートとして、伝統的なinitデーモンが自身の制御の元で実行するシェルスクリプトと協力して制御していた起動過程とランレベルを置き換える。その他にもsystemdは、ユーザーログイン、システムコンソール、デバイスホットプラグ、計画された実行、ロギング、ホスト名およびロケールを処理することで、Linuxシステムで共通するサービスの多くを統合する。

systemd}}はinitデーモンのように、systemd}}自身を含むバックグランドプロセスである全てのデーモンを管理するデーモンである。systemd}}はブート中に開始される最初のデーモンであり、シャットダウン中に終了される最後のデーモンである。systemd}}デーモンはユーザー空間のプロセスツリーのルートとなる。最初のプロセス  はデーモンプロセスが終了した際にSIGCHLDシグナルを受け取るため、UNIXシステムでは特殊な役割を持つ。このため、最初のプロセスはデーモンをモニタリングする目的のために特に適している。systemdはこの領域において、デーモンを自動的に再起動するのではなくデーモンを一度だけ開始してモニタリングをしないという伝統的なアプローチよりも改善しようとしている。

systemd}}はその起動過程の要素を並行に実行する。それは伝統的な起動過程のシーケンシャルなアプローチよりも高速である。プロセス間通信  のため、systemd}}はUNIXドメインソケットとD-Busを実行しているデーモンから使えるようにする。将来の再呼び出しに備えて、systemd}}自身の状態をスナップショットに保存することもできる。

1.1. ユニットファイル
-------------

systemd}}は伝統的に使われるデーモンごとの起動シェルスクリプトを置き換えるため、宣言型言語を使う設定ファイルに各デーモン用の初期化命令を記録する。ユニットファイルの型にはservice}}、socket}}、device}}、mount}}、automount}}、swap}}、target}}、path}}、timer}}、snapshot}}、slice}}およびscope}}などがある。

1.2. コアコンポーネントおよびライブラリ
----------------------

systemdは統合されたアプローチに従い、起動シェルスクリプト、pm-utils、inetd、acpid}}、syslog、watchdog、cronおよび[[at などの様々なデーモンやユーティリティの代替も提供する。systemdのコアコンポーネントには以下が含まれる:

systemd}}はLinuxオペレーティングシステム用のシステムおよびサービスマネージャである。
systemctl}}はsystemdのシステムおよびサービスマネージャの状態を監視し制御できる。
systemd-analyze}}はシステムブートアップパフォーマンス統計を決定し、システムおよびサービスマネージャからの他の状態と追跡情報を回収することために使うことができる。NSPAWN}}MACHINECTL systemd}}はプロセス識別子  ではなくLinuxカーネルのcgroupsサブシステムを使うことでプロセスを追跡する。このため、デーモンは2回forkしてもsystemd}}から逃れることができない。systemd}}はcgroupsだけを使うのではなく、ソフトウェアコンテナの作成と管理を容易にするユーティリティプログラムであるsystemd-nspawn}}とmachinectl}}によりcgroupsを強化する。バージョン205から、systemdはそのLinuxカーネルcgroupsへのAPIであるControlGroupInterfaceも提供する。Linuxカーネルcgroupsはkernfsをサポートするよう改造されており、さらに統一された階層構造をサポートするよう修正中である。

1.3. 補助コンポーネント
--------------

systemd一式はLinux initシステムの代替を提供することを第一の目的としているが、それ以外にも以下のコンポーネントを含む追加機能を提供する:

systemd-consoled}}はユーザーコンソールデーモンを提供し、Linuxカーネルの仮想コンソールサポートをより能力のあるユーザー空間コンポーネントで置き換えようとしている。systemd-consoled}}のプレビューバージョンは2014年10月にsystemd バージョン217の一部としてリリースされた。 systemd-journald}}はイベントロギングを担当するデーモンであり、そのログファイルは追加専用のバイナリファイルである。システム管理者はシステムイベントのログ出力をsystemd-journald}}、syslog-ng}}またはrsyslog}}のどれで行うかを決めることができる。 systemd-logind}}は様々な方法でユーザーログインとシートを管理するデーモンである。これはマルチシートの改善を提供し既に保守されていない//ConsoleKit//を置き換える、統合されたログインマネージャである。XディスプレイマネージャにおいてConsoleKitをlogind}}に置き換えるのは最小限の移植で済む。これはsystemdバージョン30で統合された。 networkd}}によりsystemdは様々なネットワーク設定を行うことができる。バージョン209でnetworkd}}が最初に統合された時、静的に割り当てられたアドレスしかサポートせず、さらにブリッジ設定の基本的なサポートしかなかった。2014年7月に、IPv4ホストのDHCPサーバーやVXLANサポートといった新機能を追加したsystemdバージョン215がリリースされた。 systemd-timedated}}はシステム時間、システムタイムゾーン、またはUTCとローカルタイムゾーンシステムクロックとのどちらかの選択といった時間関連設定のコントロールに使えるデーモンである。D-Busでアクセスできる。systemdバージョン30で統合された。 udevはLinuxカーネル用のデバイスマネージャである。udevは/dev}}ディレクトリを処理し、さらにデバイスの装着および脱着時におけるファームウェアのロードなどのユーザー空間アクションを全て処理する。2012年4月、udev用のソースツリーがシステムソースツリーにマージされた。
libudev}}はudevを利用するための標準ライブラリで、これによりサードパーティアプリケーションがudevリソースを照会できる。

1.4. 他のソフトウェアとの統合
-----------------

systemdとGNOMEデスクトップ環境との相互運用性を向上させるため、systemdの共著者であるLennart PoetteringはThe GNOME Projectに対し、systemdをGNOME 3.2の外部依存にすることを考慮するよう要請した。

2012年11月にThe GNOME Projectは、基本的なGNOME機能はsystemdに依存すべきでないとの結論を出した。しかしGNOME 3.8では当時systemdのみが提供していたlogind}}と、ConsoleKit APIとのどちらかをコンパイル時に選べるようになった。Ubuntuは独立したlogind}}を提供したが、ほとんどのLinuxディストリビューションにおいてはsystemdは//事実上//GNOMEの依存ソフトウェアになった。こうなったのはConsoleKitがもはや保守されている状態ではなく上流ではsystemd-logind}}の使用を推奨していることが主な理由である。Gentoo Linuxの開発者達もOpenRCをこれらの変化に対応させようとしたが、その実装には多くのバグがあったため、systemdをGNOMEの依存ソフトウェアにした。

GNOMEはさらにlogind}}を統合した。Mutterはバージョン3.13.2現在、Waylandセッションにおいてlogind}}を依存ソフトウェアとしている。gnome-sessionをsystemdに置き換える計画があるが、systemdはPID 1として実行//されない//でさらにgnome-sessionはLinux以外のシステムでも利用できるままである。systemdはLinuxカーネルAPIを大量に使うため、Linuxしかサポートせず他のオペレーティングシステムへの移植は容易ではない。このため、OpenBSDのようなLinux以外のオペレーティングシステムは互換APIを提供する必要がある。

2014年9月のZDNetのインタビューでセオドア・ツォーは、技術的な課題よりも多いsystemdの中央集権型設計哲学をめぐる議論は、Linux生態系の均一化に向かう危険な一般的傾向の兆候であり、オープンソースコミュニティのあちこちを疎外して排斥することで代替プロジェクトの可能性がほとんど残らなくなるという意見を述べた。この中で彼は標準でない設定に対するThe GNOME Projectの姿勢との類似点を見い出した。後にツォーはソーシャルメディアで、2人の重要な開発者の姿勢とGNOME開発者の姿勢とを比較した。

2. グラフィカルフロントエンド
----------------

以下に示すグラフィカルフロントエンドが利用できる:

SYSTEMD-UI}}SYSTEMD-UIsystemd-ui systemadm}}としても知られるシンプルなGTK+ベースのsystemd用フロントエンドである。サービスを管理するシンプルなユーザーインタフェースとユーザーからのパスワード要求へのグラフィカルエージェントを提供する。2014年現在、開発の中心がsystemctl}}やsystemd-analyze}}のようなコマンドラインツールへと移ったため、systemadmプログラムはここ数年の間ほとんど開発や保守を受けていない。 KCMSYSTEMD}}KCMSYSTEMDKcmsystemdサムネイル|systemd-manager、systemdのグラフィカルフロントエンド|代替文=KDE SC 4デスクトップ環境用のグラフィカルsystemdフロントエンドを提供する。これはKDEのシステム設定ウインドウに統合されており、設定ファイルのグラフィカルな編集だけではなくsystemdサービスのモニタリングと制御もできる。

3. フォークおよび代替実装
--------------

eudev 2012年、Gentoo Linuxプロジェクトはsystemdアーキテクチャへの依存を避けるためにudevのフォークを作成した。これによって生まれたフォークは//eudev//と呼ばれ、systemdなしでudevの機能を利用できる。このプロジェクトの決められた目標は、eudevをLinuxディストリビューションやinitシステムに依存しないようにすることである。 uselessd 2014年、//uselessd//がsystemdの軽量フォークとして作られた。このプロジェクトは他のはっきりとした欠点に対処するだけではなく、initシステムに必要ないと考えられる機能とプログラムを削除し、実装のモジュール性を高め、プラットフォーム間の移植性を改善しようとしている。 uselessdはmuslとμClibcライブラリをサポートするため組み込みシステムで使えるが、systemdはglibcしかサポートしていない。uselessdはLinux以外のプラットフォームの初期サポートをしようとしているが、systemdプロジェクトはBSDシステムとの互換性を一切保とうとしていない。uselessdプロジェクトは将来のLinuxビルドにおけるアーキテクチャ上のオーバーホールやリファクタリングだけではなく、クロスプラットフォーム互換性のさらなる改善を計画している。 systembsd 2014年、OpenBSD用のsystemd代替API実装を提供するための"systembsd" と名付けられたGoogle Summer of Codeプロジェクトが開始された。systembsdプロジェクトの開発者達は元々、LinuxからOpenBSDへの移行を容易にするためにこのプロジェクトを始めた。 systembsdプロジェクトはinitの代替を提供しないが、とりわけhostnamed}}、timedated}}、localed}}およびlogind}}と互換性のあるデーモンをOpenBSDに提供することを狙いとしている。このプロジェクトは新しいsystemdライクな機能を作らず、単なるネイティブOpenBSDシステムのラッパーとして動作するよう意図されている。開発者はsystembsdを基本システムの一部としてではなく、Portsコレクション
の一部としてインストールできるようにすることを狙いとしており、「systemdと*BSDは哲学と開発習慣の点で根本的に異なる」と発言している。 consolekit2 2014年10月、Xfceの開発者達は依然としてConsoleKitの機能をLinux以外のオペレーティングシステムで保守し利用できるようことを望んでいたため、ConsoleKitをフォークした。ConsoleKit2の主な開発者は長期的には元のリポジトリを復活する可能性を除外していないが、systembsdが成熟するまでConsoleKit2が一時的に必要となると考えている。

4. 採用および反響
----------

ほとんどのディストリビューションはデフォルトでsystemdをブートするが、systemd以外のinitシステムを使えるディストリビューションもある。systemd以外のinitシステムに変更する場合は、適切なパッケージをインストールすればよい。DebianのフォークであるDevuanはsystemdを避けるつもりである。



4.1. 歴史と論争
----------

2011年5月、Fedoraはsystemdをデフォルトとして利用できるようにした最初のメジャーLinuxディストリビューションとなった。

2011年7月、Lennart PoetteringはDebianがFreeBSD版  もあるためsystemdの正式採用をためらっていたことを問題とは考えず、「Debian kFreeBSD はおもちゃのOSだ」と発言した。

2012年のインタビューでSlackwareの代表であるPatrick Volkerdingは、systemdアーキテクチャについての不安を述べ、systemdの設計が狭義に定義された機能による相互接続ユーティリティというUNIX哲学に反しているという彼の信念を表明した。2014年8月現在、Slackwareはsystemdのサポートや使用をしていないが、Volkerdingはsystemdへ変更する可能性を否定していない。

2013年10月から2014年の間、Debian Technical Committee内でDebian 8 "jessie" のデフォルトとしてどのinitシステムを使うかを話し合うための長期に渡る議論がDebianメーリングリストで起こり、その結果としてsystemdを選ぶことになった。この議論は広く公開され、この結論に引き続き議論がDebianメーリングリストで続いている。

2013年1月、Lennart Poetteringは//The Biggest Myths//と呼ばれるブログポストでsystemdについての懸念に対処しようとした。systemdをめぐり続いている論争の後の2014年10月、Poetteringは「オープンソースコミュニティはくそったれだらけで、他の誰よりも私が彼らの最もお気に入りの標的になっているのだろう」と不満を漏らした。続けてPoetteringはオープンソースコミュニティの状態をリーナス・トーバルズなどのカーネル開発者のせいにした。

2014年2月Debianの決定がされた後、ubuntuコミュニティのマーク・シャトルワースは2013年10月初期のコメントでsystemdは「非常に侵略的で正当化されることはほぼない」と評したにもかかわらず、systemd実装についてはUbuntuもやり抜くとブログでアナウンスした。

2014年3月、エリック・レイモンドはsystemdの設計目標はミッションクリープでソフトウェアの肥大化の傾向があると言った。2014年4月、リーナス・トーバルズはユーザーやバグレポートに向けてsystemdの中心開発者であるKay Sieversの姿勢についての不安を表明した。

2014年4月後期、systemdの採用に反対する様々な理由を並べたWebサイトを使って、systemdのボイコットキャンペーンが行われた。

2014年4月の//InfoWorld//で発行された記事で、Paul Veneziaはsystemd論争について書き、この論争をUNIX哲学の破壊と「自分達は何も間違っていないはずだと固く信ずる巨大なエゴ」にあると考えた。この記事はsystemdのアーキテクチャを、幅広い機能範囲で使われ酷評されるMicrosoft Windowsのシステムコンポーネントであるsvchost.exeのアーキテクチャとよく似ていると述べた。

2014年11月、DebianのメンテナーでTechnical CommitteeのメンバーであるJoey Hess、Russ Allbery、イアン・ジャクソンと、systemdパッケージメンテナーであるTollef Fog Heenが自らの地位を辞した。Debianのメンテナーであった3人は全員、通常のメンテナンスを事実上不可能にしてしまうDebianやオープンソースコミュニティ内におけるsystemd統合についての論争に関係する並外れたストレスレベルに身をさらしながら、公開されているDebianメーリングリストや個人ブログで決定を正当化した。

2014年12月、自身を"Veteran Unix Admins"と呼ぶグループがDevuanと呼ばれるDebianのフォークをアナウンスした。この意図はデフォルトでsystemdをインストールしないDebian派生を提供することである。

5. 脚注
-----

5.1. 注釈
-------

5.2. 出典
-------

6. 関連項目
-------

BusyBox
launchd
systemd-readahead
オペレーティングシステムサービス管理

7. 外部リンク
--------

[1]
[2]
[3]
[4] 
[5]
[6]
Init systems comparison: [7] and [8] 
[9]