トップQs
タイムライン
チャット
視点
Systemd
ウィキペディアから
Remove ads
systemdは、システム管理を担うソフトウェア群であり、従来のSystem V initに代わって導入された仕組みである。デーモン・ライブラリおよび各種ユーティリティで構成され、システム管理・設定における中心的プラットフォームとして、2010年、RedHat社のエンジニアにより、Linux OS用に設計された。
Remove ads
著者によるとsystemdはオペレーティングシステムの「基本的な積木」であると評され[5]、UNIX System VやBSDから継承されたinitシステムを置き換えることを第一の目標としている。
systemdという名前はファイル名の最後尾にdという文字を付けることでデーモンを区別しやすくするというUNIXの慣習を受け継いでいる[6]。また、この名称は言葉遊びの側面もある。フランスで最近よく言われている「システムD」とは、「状況に迅速に適応し問題を即興で解決する個人の能力」を意味する。ここでの「D」は、「仏: débrouille＝なんとかする」の頭文字である[6]。
systemdはLinux用に設計され、Linux API専用にプログラミングされている。systemdはGNU Lesser General Public License (LGPL) version 2.1以降という条件で自由なオープンソースソフトウェアとして公表されている[4]。
systemdの設計は自由ソフトウェアコミュニティにおける重要な論争の元となった。これはsystemdのアーキテクチャはUNIX哲学に反しており最終的に相互依存でがんじがらめの塊を作ってしまうと批評家達を主張させるようになっているためである[7]。しかしながら2015年現在、主要なLinuxディストリビューションのほとんどはsystemdをデフォルトのinitシステムとして採用している。
Remove ads
設計
要約
視点
初期にsystemdを開発したソフトウェア技術者である[1]Lennart PoetteringとKay Sieversはどうにかしてinitデーモンの効率をしのごうとした。彼らはシステムのブート中にたくさんの処理を並行または並列に行えるようにし、さらにシェルのオーバーヘッドを減少させるために、依存関係を表現できるようにそのソフトウェアフレームワークを改良したいと思っていた。
Poetteringはsystemdの開発を「決して終了せず決して完成しないが、技術の進歩を追い求める」ことと述べている。2014年5月にPoetteringはさらに進んで、systemdは以下の3つの一般的な機能を提供して「ディストリビューション間の無意味な違い」の統合を目指すものであると定義した[9]:
- システムとサービスマネージャ（様々な設定を適用することでシステムとそのサービスを両方管理する）
- ソフトウェアプラットフォーム（他のソフトウェアの開発基盤となる）
- アプリケーションとLinuxカーネルとの接着剤（カーネルが提供する機能をさらけ出す様々なインタフェースを提供する）
systemdは単なるinitデーモンの名前ではなく、systemd initデーモンに加えjournald、logindおよびnetworkdの各デーモンとそれ以外の多くの低レベルコンポーネントを含む、ソフトウェアバンドル全体を指している。2013年1月、Poetteringはsystemdは1つのプログラムではなく、69個の個別バイナリから成る巨大なソフトウェア一式だと述べた[10]。systemdは統合されたソフトウェアスイートとして、伝統的なinitデーモンが自身の制御の元で実行するシェルスクリプトと協力して制御していた起動過程とランレベルを置き換える。その他にもsystemdは、ユーザーログイン、システムコンソール、デバイスホットプラグ（udevを参照）、計画された実行（cronを置き換える）、ロギング、ホスト名およびロケールを処理することで、Linuxシステムで共通するサービスの多くを統合する。
systemdはinitデーモンのように、systemd自身を含むバックグランドプロセスである全てのデーモンを管理するデーモンである。systemdはブート中に開始される最初のデーモンであり、シャットダウン中に終了される最後のデーモンである。systemdデーモンはユーザー空間のプロセスツリーのルートとなる。最初のプロセス (pid 1) は（親プロセスから分離した）デーモンプロセスが終了した際にSIGCHLDシグナルを受け取るため、UNIXシステムでは特殊な役割を持つ。このため、最初のプロセスはデーモンをモニタリングする目的のために特に適している。systemdはこの領域において、デーモンを自動的に再起動するのではなくデーモンを一度だけ開始してモニタリングをしないという伝統的なアプローチよりも改善しようとしている。
systemdはその起動過程の要素を並行に実行する。それは伝統的な起動過程のシーケンシャルなアプローチよりも高速である[11]。プロセス間通信 (IPC) のため、systemdはUNIXドメインソケットとD-Busを実行しているデーモンから使えるようにする。将来の再呼び出しに備えて、systemd自身の状態をスナップショットに保存することもできる。
ユニットファイル
systemdは伝統的に使われるデーモンごとの起動シェルスクリプトを置き換えるため、宣言型言語を使う設定ファイル（これを「ユニットファイル」と言う）に各デーモン用の初期化命令を記録する。ユニットファイルの型にはservice、socket、device、mount、automount、swap、target、path、timer（cronライクなジョブスケジューラとして使用できる[12]）、snapshot、sliceおよびscopeなどがある[13]。
コアコンポーネントおよびライブラリ
systemdは統合されたアプローチに従い、起動シェルスクリプト、pm-utils、inetd、acpid、syslog、watchdog、cronおよびatdなどの様々なデーモンやユーティリティの代替も提供する。systemdのコアコンポーネントには以下が含まれる:
- systemdはLinuxオペレーティングシステム用のシステムおよびサービスマネージャである。
- systemctlはsystemdのシステムおよびサービスマネージャの状態を監視し制御できる。
- systemd-analyzeはシステムブートアップパフォーマンス統計を決定し、システムおよびサービスマネージャからの他の状態と追跡情報を回収することために使うことができる。
MACHINECTL systemdはプロセス識別子 (PID) ではなくLinuxカーネルのcgroupsサブシステムを使うことでプロセスを追跡する。このため、デーモンは2回forkしてもsystemdから逃れることができない。systemdはcgroupsだけを使うのではなく、ソフトウェアコンテナの作成と管理を容易にするユーティリティプログラムであるsystemd-nspawnとmachinectlによりcgroupsを強化する[14]。バージョン205から、systemdはそのLinuxカーネルcgroupsへのAPIであるControlGroupInterfaceも提供する[15]。Linuxカーネルcgroupsはkernfsをサポートするよう改造されており[16]、さらに統一された階層構造をサポートするよう修正中である[17]。
補助コンポーネント
systemd一式はLinux initシステムの代替を提供することを第一の目的としているが、それ以外にも以下のコンポーネントを含む追加機能を提供する:
- consoled
- systemd-consoledはユーザーコンソールデーモンを提供し、Linuxカーネルの仮想コンソールサポートをより能力のあるユーザー空間コンポーネントで置き換えようとしている[18]。systemd-consoledのプレビューバージョンは2014年10月にsystemd バージョン217の一部としてリリースされた[19]。
- journald
- systemd-journaldはイベントロギングを担当するデーモンであり、そのログファイルは追加専用のバイナリファイルである。システム管理者はシステムイベントのログ出力をsystemd-journald、syslog-ngまたはrsyslogのどれで行うかを決めることができる。
- logind
- systemd-logindは様々な方法でユーザーログインとシートを管理するデーモンである。これはマルチシートの改善を提供し[20]既に保守されていないConsoleKit[21]を置き換える、統合されたログインマネージャである。XディスプレイマネージャにおいてConsoleKitをlogindに置き換えるのは最小限の移植で済む[22]。これはsystemdバージョン30で統合された。
- networkd
- networkdによりsystemdは様々なネットワーク設定を行うことができる。バージョン209でnetworkdが最初に統合された時、静的に割り当てられたアドレスしかサポートせず、さらにブリッジ設定の基本的なサポートしかなかった。2014年7月に、IPv4ホストのDHCPサーバーやVXLANサポートといった新機能[23]を追加したsystemdバージョン215がリリースされた[24][25][26][27][28]。
- timedated
- systemd-timedatedはシステム時間、システムタイムゾーン、またはUTCとローカルタイムゾーンシステムクロックとのどちらかの選択といった時間関連設定のコントロールに使えるデーモンである。D-Busでアクセスできる[29]。systemdバージョン30で統合された。
- udevd
- udevはLinuxカーネル用のデバイスマネージャである。udevは/devディレクトリを処理し、さらにデバイスの装着および脱着時におけるファームウェアのロードなどのユーザー空間アクションを全て処理する。2012年4月、udev用のソースツリーがシステムソースツリーにマージされた[30][31]。
- libudev
- libudevはudevを利用するための標準ライブラリで、これによりサードパーティアプリケーションがudevリソースを照会できる。
他のソフトウェアとの統合
→「GNOME 3をめぐる論争」も参照
systemdとGNOMEデスクトップ環境との相互運用性を向上させるため、systemdの共著者であるLennart PoetteringはThe GNOME Projectに対し、systemdをGNOME 3.2の外部依存にすることを考慮するよう要請した[32]。
2012年11月にThe GNOME Projectは、基本的なGNOME機能はsystemdに依存すべきでないとの結論を出した[33]。しかしGNOME 3.8では当時systemdのみが提供していたlogindと、ConsoleKit APIとのどちらかをコンパイル時に選べるようになった。Ubuntuは独立したlogindを提供したが、ほとんどのLinuxディストリビューションにおいてはsystemdは事実上GNOMEの依存ソフトウェアになった。こうなったのはConsoleKitがもはや保守されている状態ではなく上流ではsystemd-logindの使用を推奨していることが主な理由である[34]。Gentoo Linuxの開発者達もOpenRCをこれらの変化に対応させようとしたが、その実装には多くのバグがあったため、systemdをGNOMEの依存ソフトウェアにした[35][36]。
GNOMEはさらにlogindを統合した[37]。Mutterはバージョン3.13.2現在、Waylandセッションにおいてlogindを依存ソフトウェアとしている[38]。gnome-sessionをsystemdに置き換える計画があるが、systemdはPID 1として実行されないでさらにgnome-sessionはLinux以外のシステムでも利用できるままである。systemdはLinuxカーネルAPIを大量に使うため、Linuxしかサポートせず他のオペレーティングシステムへの移植は容易ではない。このため、OpenBSDのようなLinux以外のオペレーティングシステムは互換APIを提供する必要がある。
2014年9月のZDNetのインタビューでセオドア・ツォーは、技術的な課題よりも多いsystemdの中央集権型設計哲学をめぐる議論は、Linux生態系の均一化に向かう危険な一般的傾向の兆候であり、オープンソースコミュニティのあちこちを疎外して排斥することで代替プロジェクトの可能性がほとんど残らなくなるという意見を述べた。この中で彼は標準でない設定に対するThe GNOME Projectの姿勢との類似点を見い出した[39]。後にツォーはソーシャルメディアで、2人の重要な開発者の姿勢とGNOME開発者の姿勢とを比較した[40]。
Remove ads
グラフィカルフロントエンド
以下に示すグラフィカルフロントエンドが利用できる:
- SYSTEMD-UIsystemd-ui
- systemadmとしても知られるシンプルなGTK+ベースのsystemd用フロントエンドである[41]。サービスを管理するシンプルなユーザーインタフェースとユーザーからのパスワード要求へのグラフィカルエージェントを提供する。2014年現在、開発の中心がsystemctlやsystemd-analyzeのようなコマンドラインツールへと移ったため、systemadmプログラムはここ数年の間ほとんど開発や保守を受けていない。
- KCMSYSTEMDKcmsystemd
systemd-manager、systemdのグラフィカルフロントエンド
Remove ads
フォークおよび代替実装
- eudev
- 2012年、Gentoo Linuxプロジェクトはsystemdアーキテクチャへの依存を避けるためにudevのフォークを作成した。これによって生まれたフォークはeudevと呼ばれ、systemdなしでudevの機能を利用できる[42]。このプロジェクトの決められた目標は、eudevをLinuxディストリビューションやinitシステムに依存しないようにすることである[43]。
- uselessd
- 2014年、uselessdがsystemdの軽量フォークとして作られた。このプロジェクトは他のはっきりとした欠点に対処するだけではなく、initシステムに必要ないと考えられる機能とプログラムを削除し、実装のモジュール性を高め、プラットフォーム間の移植性を改善しようとしている[44]。
- uselessdはmuslとμClibcライブラリをサポートするため組み込みシステムで使えるが、systemdはglibcしかサポートしていない。uselessdはLinux以外のプラットフォームの初期サポートをしようとしている（現在のところ準備状態におけるビルド時のみ）が、systemdプロジェクトはBSDシステムとの互換性を一切保とうとしていない[44]。uselessdプロジェクトは将来のLinuxビルドにおけるアーキテクチャ上のオーバーホールやリファクタリングだけではなく、クロスプラットフォーム互換性のさらなる改善を計画している[45]。
- systembsd
- 2014年、OpenBSD用のsystemd代替API実装を提供するための"systembsd" と名付けられたGoogle Summer of Codeプロジェクトが開始された。systembsdプロジェクトの開発者達は元々、LinuxからOpenBSDへの移行を容易にするためにこのプロジェクトを始めた[46]。
- systembsdプロジェクトはinitの代替を提供しないが、とりわけhostnamed、timedated、localedおよびlogindと互換性のあるデーモンをOpenBSDに提供することを狙いとしている。このプロジェクトは新しいsystemdライクな機能を作らず、単なるネイティブOpenBSDシステムのラッパーとして動作するよう意図されている。開発者はsystembsdを基本システムの一部としてではなく、Portsコレクションの一部としてインストールできるようにすることを狙いとしており、「systemdと*BSDは哲学と開発習慣の点で根本的に異なる」と発言している[46]。
- consolekit2
- 2014年10月、Xfceの開発者達は依然としてConsoleKitの機能をLinux以外のオペレーティングシステムで保守し利用できるようことを望んでいたため、ConsoleKitをフォークした。ConsoleKit2の主な開発者は長期的には元のリポジトリを復活する可能性を除外していないが、systembsdが成熟するまでConsoleKit2が一時的に必要となると考えている[47]。
採用および反響
要約
視点
ほとんどのディストリビューションはデフォルトでsystemdをブートするが、systemd以外のinitシステムを使えるディストリビューションもある。systemd以外のinitシステムに変更する場合は、適切なパッケージをインストールすればよい。DebianのフォークであるDevuanはsystemdを避けるつもりである[48]。
歴史と論争
2011年5月、Fedoraはsystemdをデフォルトとして利用できるようにした最初のメジャーLinuxディストリビューションとなった。[65]
2011年7月、Lennart PoetteringはDebianがFreeBSD版 (kFreeBSD) もあるためsystemdの正式採用をためらっていた[66]ことを問題とは考えず、「Debian kFreeBSD はおもちゃのOSだ」と発言した[67]。
2012年のインタビューでSlackwareの代表であるPatrick Volkerdingは、systemdアーキテクチャについての不安を述べ、systemdの設計が狭義に定義された機能による相互接続ユーティリティというUNIX哲学に反しているという彼の信念を表明した[68]。2014年8月現在、Slackwareはsystemdのサポートや使用をしていないが、Volkerdingはsystemdへ変更する可能性を否定していない[69]。
2013年10月から2014年の間、Debian Technical Committee内でDebian 8 "jessie" のデフォルトとしてどのinitシステムを使うかを話し合うための長期に渡る議論がDebianメーリングリストで起こり[70]、その結果としてsystemdを選ぶことになった。この議論は広く公開され[71][72]、この結論に引き続き議論がDebianメーリングリストで続いている。
2013年1月、Lennart PoetteringはThe Biggest Mythsと呼ばれるブログポストでsystemdについての懸念に対処しようとした[10]。systemdをめぐり続いている論争の後の2014年10月、Poetteringは「オープンソースコミュニティはくそったれだらけで、他の誰よりも私が彼らの最もお気に入りの標的になっているのだろう」と不満を漏らした。続けてPoetteringはオープンソースコミュニティの状態をリーナス・トーバルズなどのカーネル開発者のせいにした[73]。
2014年2月Debianの決定がされた後、ubuntuコミュニティのマーク・シャトルワースは2013年10月初期のコメントでsystemdは「非常に侵略的で正当化されることはほぼない」と評した[74]にもかかわらず、systemd実装についてはUbuntuもやり抜くとブログでアナウンスした[75]。
2014年3月、エリック・レイモンドはsystemdの設計目標はミッションクリープでソフトウェアの肥大化の傾向があると言った[76]。2014年4月、リーナス・トーバルズはユーザーやバグレポートに向けてsystemdの中心開発者であるKay Sieversの姿勢についての不安を表明した[77]。
2014年4月後期、systemdの採用に反対する様々な理由を並べたWebサイトを使って、systemdのボイコットキャンペーンが行われた[78][79]。
2014年4月のInfoWorldで発行された記事で、Paul Veneziaはsystemd論争について書き、この論争をUNIX哲学の破壊と「自分達は何も間違っていないはずだと固く信ずる巨大なエゴ」にあると考えた[80]。この記事はsystemdのアーキテクチャを、幅広い機能範囲で使われ酷評されるMicrosoft Windowsのシステムコンポーネントであるsvchost.exeのアーキテクチャとよく似ていると述べた[80]。
2014年11月、DebianのメンテナーでTechnical CommitteeのメンバーであるJoey Hess[81]、Russ Allbery[82]、イアン・ジャクソン[83]と、systemdパッケージメンテナーであるTollef Fog Heen[84]が自らの地位を辞した。Debianのメンテナーであった3人は全員、通常のメンテナンスを事実上不可能にしてしまうDebianやオープンソースコミュニティ内におけるsystemd統合についての論争に関係する並外れたストレスレベルに身をさらしながら、公開されているDebianメーリングリストや個人ブログで決定を正当化した。
2014年12月、自身を"Veteran Unix Admins"と呼ぶグループがDevuanと呼ばれるDebianのフォークをアナウンスした。この意図はデフォルトでsystemdをインストールしないDebian派生を提供することである[85]。
Remove ads
脚注
関連項目
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads