Systemd – 知っておくべきこと
あなたが岩の下で生活しているか、あるいはもっと悪いことにLinuxの仕組みにあまり興味がない限り、ほとんどの主要なLinuxディストリビューションによって最近採用された、古くて時代遅れのSysV initを置き換える（比較的新しい）initシステムであるsystemdについて聞いたことがあるはずです。
initシステムとは？
Linuxマシンが起動すると、最初にBIOSまたはUEFIから読み込まれた「ビルトイン」コードが実行され、次にブートローダーがその設定に従ってLinuxカーネルを読み込みます。カーネルはドライバを読み込み、最初の仕事としてinitプロセスを起動します。このプロセスは最初に起動するため、PID（プロセスID）1が割り当てられます。
ユーザーの観点から見ると、これはネットワーキングやデータベースなどを起動するように見えますが、実際には背後でかなり複雑なプロセスが進行しています。サービスは起動、停止、再起動され、しばしば並行して実行されます。いくつかは他のものと異なる特権の下で実行され、サービスの状態が報告・記録され、多くの他のタスクが実行され、システムの異なる部分が動作し、ユーザーや環境と相互作用できるようになります。
しかし、これをどのように実装するかは決して統一されておらず、実際にはすべてが共通で明確になるところで止まってしまいます。
古いinitシステム
最近までほとんどの主流Linuxディストリビューションで使用されていたinitシステムはSystem V init（略してSysV init）であり、その名前はUNIX System V（発音は「システムファイブ」）に由来しています。これは、最初の商業的に入手可能なUNIXシステムです。System V OSは特定の方法でinitプロセスを実行しており、SysV initは長年この忠実さを保っています。
そして多くの年月が経ちました。UNIX System Vは1983年にリリースされ、SysV initは30年以上前のLinuxマシン起動に対するアプローチです。
変更の必要性
以前から指摘されてきたように、SysV initは時代遅れであり、置き換えられるべき時期がきています。その理由のいくつかを挙げると：
- SysV initは/initプロセスを起動するために/sbin/initを使用しますが、init自体の役割は非常に限られています。initは単に/etc/init.d/rcを起動するだけで、これは/etc/inittabから読み込まれた設定に従って起動します。このため、明示的に並行処理をしない場合（例えばDebianのstartparを使用する場合）、スクリプトが一つ一つ順番に実行され、全体のプロセスが遅くなります。
- SysV initはPIDやそのプロセスを（間接的に）取得したものを持っていません。実際のプロセスに関連付けるためには、複雑な手法でPIDsを読み込む必要があります。
- 特定のプロセスが起動する環境を変更しようとするシステム管理者にとって、SysV initは非常に困難です。（そのためには、与えられたプロセスを起動する責任のあるinitスクリプトを修正する必要があります。）
- SysVは、全てのサービスに共通する特定の機能を実装しておらず、各プロセスが自分自身で実装する必要があります。たとえば「デーモン化」すること（システムデーモンになること）は、非常に手間がかかるプロセスです。これらの手順を一度だけ実装するのではなく、SysVは各プロセスに自分でこの作業を行うよう要求します。
- SysVはまた、特定の機能を外部プログラムに任せ、そのサービスを起動したものに関しては何も知りません。
以上のすべて、さらにたくさんの設計上の欠陥、つまりSysVの時代遅れなシステム設計が、現代的なinitシステムの創造を長い間待たせてきました。
systemdの登場
代替のinitシステムを作成する試みは多くありましたが、その中の一つがsystemdです。Ubuntuはかつてupstartという独自のinitシステムを運用していました。Gentooは今でもOpenRCを使用しています。他のinitシステムにはinitng、busybox-init、runit、Mudurなどがあります。
systemdが明らかな勝者である理由は、ほとんどの主要なディストリビューションによって採用されていることです。RHLとCentOSは事実上systemdの道を歩んでおり、Fedoraは2011年にsystemdを公式に採用した最初のディストリビューションです。しかし、Debian 8が公式にsystemdに切り替え、Ubuntuや派生版もそれに続くと、systemdは本当にすべてを支配するinitシステムになりました。これはCanonical（より正確にはMark Shuttleworth）のsystemdに対する初期の反対に対抗した結果です。
systemdの違い
- Systemdはinitプロセスを一貫して取り扱う単一の中央集権的な方法を提供することを目指しています。
- プロセスやサービスを起動・停止し、その依存関係を追跡します。プロセスの依存関係が必要な場合には、別のプロセスの応答として新しいプロセスを起動することもできます。
- ブート時にプロセスを起動・停止するだけでなく、特定のトリガーイベント（例えばデバイスの接続時）に応じてシステムが稼働しているときにもプロセスを起動できます。
- また、プロセスに自分をデーモン化させる必要はありません。SysV initとは異なり、systemdはデーモンになる長いプロセスを経ずにサービスを管理できます。
- SysV initとは異なり、systemdはすべてのプロセスを把握・追跡し、PIDを含め、システム管理者がプロセスの情報を取得するのがはるかに簡単です。
- Systemdは、基本的に孤立したサービス環境であるコンテナをサポートします。これは将来的により安全で簡素なシステム設計への大きな可能性を孕んでいます。
もちろん、これらは主な利点の一部に過ぎません。systemdの利点については、Debian 8の「Systemd Position Statement」を読むことをお勧めします。
論争
もちろん、systemdはすべての人に歓迎されたわけではありません。実際、多くの人々がこれに反対し、巨大で手間がかかると呼び、すべてを中央集権化する「ウィンドウズの道」を歩んでいると非難する人もいます。多くの人が「Linuxの道ではない」と主張しており、systemdはPOSIX標準に従っているようには見えません。また、systemdをツールキット（単なるバイナリを超えて）として考えると、確かに巨大です。
それでもやはり、systemdは明らかに前進したステップであり、完全ではないものの、受けた批判の多くは、元の著者で開発者のレナート・ポッタリングによって対処されています。これは、古いinitシステムから必要不可欠な前進であり、ステップアップです。Linuxの創始者であるリーナス・トーバルズはsystemdについてそれほど気にしていないようで、「創始者」と議論するのは誰でしょうか。
結論
すべての主要なLinuxディストリビューションによって採用されたsystemdは、今後も存在し続けるでしょう。いかなる理由であれ、一部のシステム管理者が言うことに関わらず、systemdは主流のLinuxの未来であり、個々のユーザーが好むかどうかにかかわらず、その明確な利点を考慮すれば、必ずしも悪いことではありません。
平均のユーザーにとって、これはより速い起動時間とおそらくより信頼性のあるシステムをもたらし、将来的には採用するディストリビューション同士がより「互換性」を持てるようになるかもしれません。ユーザーの立場としては、デスクトップに提供するより最新で現代的なシステムデザインから確実に恩恵を受けることができるでしょう。
