序

本記事は具体的な設定などを扱うものではない。

Systemdについて詳しくない人が、Systemdに向き合うにあたってその入口となるような話をするものである。

なお、私はcronなんか使わずにユーザーtimerユニットを使うし、atではなくsystemd-runを使っているし、systemd-nspawnでコンテナを使うくらいにはSystemdユーザーである。

基本

SystemdはLinuxの基本的な部分を担うシステムである。

init(8)の代替として説明されることが多いが、実際は非常に多岐に渡ってLinuxシステムを制御するための機構がある。

サービスの起動・停止等はもちろんだが、基本的な要素に関してはSystemdがまかなっているのではないかという点について一度調べたほうが良い。 Systemdが互換性のある同名のコマンドを提供している場合もあるが、基本的にはSystemdが提供する基本的な機能と重複する別のソフトウェアを使うのは非推奨である可能性が高いからだ。

前述のとおり、cronに関してはtimerユニットによる制御、あるいはsystemd-runを使うものであり、atコマンドに関してもsystemd-runが担う。

システムメッセージはSystemdが管理し、もはや/var/log/messagesは(残すようなユニットを作らない限り)存在しない。 ログの確認にはjournalctlを用いる。 ユーザーセッションの管理はsystemd-logind.serviceによって管理され、その管理コマンドとしてloginctlを用いる。

システムのホスト名の管理はhostnamectlによって行う。 ネットワーク機能に関してはnetworkctlを用いるが、こちらについては必ずしもsystemd-networkdを用いているとは限らない。ネットワークの設定にNetwork Managerを使っている場合が多いためだ。同様に、systemd-resolvedも必ずしも使われていない。

また、ブートローダーとしてsystemd-bootがあるが、これが使われることはほとんどない。 その機能に関しては、これまた巨大なソフトウェアであるGrubには遠く及ばず、どちらかといえばSyslinuxの代替として選択されるようなものである。 systemd-bootよりはrEFIndが使われることのほうが多いだろう。

こうした知識は新しいものへの乗り換えを積極的に受け入れないと入ってこないもので、ネット上は間違ったレガシーな知識による記載が溢れている。 注意が必要だ。

Systemdを推す理由

便利だからだ。

cronやatは、長く使われてきたシンプルなシステムだが、柔軟性に欠け、分かりづらく、管理しづらい。 systemd-runやtimerユニットは、手間が少なく、混乱する要素が少なく、非常に管理しやすい。 また、cronやatでは内容によらずシステム管理者による一括の権限付与が必要であったが、そうした問題もなくユーザーのことはユーザーレベルでできる。

systemd-nspawnも非常に使いやすく、優れた機能だ。

確かに、旧来のシステムはUnix哲学に則っており、シンプルな原則に従っている。 一方でそれらの組み合わせはあまりに複雑で、覚えるべきことが多く、一貫性がなく、柔軟性も失ってしまう。 黎明期ならまだしも、システムが複雑化した現在では人間の手に負えない管理コストを要求される。

この問題は、システムを構築する基本的なソフトウェアたちが、一定の規則のもと、一括して管理できるインターフェイスを提供すれば解決する問題ではある。 だが、現実にはそのような協調性を持つことはできない。現実的な対応として、それらがひとつのソフトウェア群として提供されるのは、唯一の解決策となった。

実際、それによって非常に管理しやすくなり、強力な機能を手に入れた。 基本的な機能に対して不安定なソフトウェアを使い、メンテナンスされなくなったり、その代替が開発されたりしてそのたびに新しい知識を仕入れるというコストも抑制されている。

現実的な面として、優れた定番のソフトウェアがあるネットワーク管理(Network Manager)やブートローダー(Grub)はあまり使われていないのであり、Systemdが用いられている領域というのは十分手が行き届いていなかったものである、と考えることができる。 systemd-networkdもそうだが、systemd-homedのような機能に関しては「出過ぎた真似」だと考えることもできる。そういったものも、実際にはあまり使われない。

だからSystemdはシステム全体を掌握するようなソフトウェアとなっている一方、実際には必要とされているものは使われ、必要のないものは拒まれているので非常に健全だ。Systemdを使うとしても、いらないものは「いらない」で通すことができるという点でも健全であると見ることができる。

問題

すべてがSystemdに依存するようになると、Systemdが支配的になる、という問題がある。 現にそうなってきていると言えるし、Systemdと本質的に関係のないGNOMEがSystemdに依存しているのはそのわかりやすい例と言えるだろう。

Systemdが優れているから、人気だから、そして圧倒的なシェアを獲得したから、他のプロジェクトは生き残るのが難しくなってきている。Systemdしか存在しない、という状況は歓迎できるものではない。

Systemdの思想はFreeDesktop.orgの思想と親和性が高い。 しかしFreeDesktop.orgの思想は非常にWindows寄りで、最近は「Windows的なものを規格として定める」ことに執心している。

この点を考えるとSystemdの「管理」が行き過ぎたものになる可能性は否定できない。 これは、どれほど密に結合するかという点が深く関わってくる。

また、Systemd開発者の “彼” が非常に攻撃的な人物であることも私は懸念している。 自分が唯一絶対で正しいと考え、異を唱えるものに罵声を浴びせるような人物のプロダクトは、あまり幸せなものにならないと感じているのだ。

だが、Systemdは巨大だが過度に複雑ではなく、誰もが必要とするものであるということを考えると、例えSystemdが変な方向に行ったとしてもそれをフォークすることは不可能ではないように見える。それは、どれだけ「手を動かす人」が集まるかによるが、Systemdが根本的に間違っているのでない限り、そこまで悲観的になる必要はないだろう。