この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
セミナーでこんな質問を受けることがあります。MX Linuxが海外レビューサイトで好意的に取り上げられることが増え、「systemdを使わないディストリビューション」というキーワードが注目を集めているのを見て、疑問を持った方からの質問です。
この記事では、20年以上Linuxサーバーを運用してきた経験から、systemdが普及した背景、なぜ反systemdの動きが根強いのか、そして現場エンジニアはこの論争をどう受け止めるべきかを3軸で整理します。
結論から言えば、「systemdが正しいかsysVinitが正しいか」を決めることより、「どちらを選んだかを語れること」の方が、現場での価値につながります。
この記事のポイント
・systemdが標準になった経緯と、その設計思想が批判される理由
・MX Linuxが支持される理由は「軽さ」ではなく「設計判断への共感」
・init系の変遷を知ることで、現場での会話力と設計判断力が上がる
・「使えるLinuxエンジニア」と「語れるLinuxエンジニア」の差は知識の体系化にある
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／
詳細はこちら
systemdが嫌われる理由を、ちゃんと説明できますか
「systemdが嫌いなLinuxユーザーがいる」という話を聞いたことがある方は多いでしょう。しかし「なぜ嫌われているのか」を技術的に説明できる人は、意外に少ないのです。
私がセミナーで確認すると、「なんとなく複雑そう」「ベテランが嫌っているから」という答えが返ってくることが多い。
感情で語られていることが多く、技術的な根拠が共有されていないのです。
ですので、まずsystemdへの批判の核心を整理します。
批判の中心は「UNIX哲学との乖離」
UNIX哲学の基本原則の一つに「一つのことをうまくやれ（Do one thing and do it well）」があります。プログラムは小さく、単一の責任を持ち、標準入出力でつながる——これがUNIX設計の根幹です。
systemdはこの原則から大きく外れています。
systemdは「システム管理デーモン」として始まりましたが、現在では以下の機能を一手に担っています。
・プロセス管理（サービスの起動・停止・再起動）
・ログ管理（journald）
・ネットワーク管理（systemd-networkd）
・DNS管理（systemd-resolved）
・タイムゾーン管理（timedatectl）
・ユーザーセッション管理（systemd-logind）
・ブート管理（systemd-boot）
・コンテナ管理（systemd-nspawn）
「プロセス管理だけをやる」はずのinitが、OS全体の多くを飲み込んでいく——この拡張の連続が、「UNIXらしくない」という批判を生んでいます。
デバッグのしにくさという実務問題
理念の話だけではありません。現場エンジニアからの批判には、実務的な問題もあります。sysVinitやOpenRC（MX Linuxが採用しているinit）では、起動スクリプトはシェルスクリプトです。
問題が起きたとき、`/etc/init.d/` 配下のスクリプトを読めば、何をしているかがそのまま分かります。
systemdのユニットファイルは宣言的な記述です。「このサービスはこのサービスの後に起動する」「失敗したらリスタートする」という設定を書きます。
この宣言的な記述は確かに分かりやすい部分もあるのですが、複雑な依存関係が絡んだとき、「どこで詰まっているか」の調査が難しくなることがあります。
journaldのバイナリログも批判対象です。
従来のsyslogはテキストファイルで、`cat /var/log/messages` や `tail -f /var/log/syslog` で直接読めました。
journaldのログはバイナリ形式で、`journalctl` コマンドを通じてしか読めません。
ログが壊れたとき、復元・解析が難しい——という指摘は、本番環境を持つエンジニアほど気にします。
批判の感情的側面も無視できない
公平に見ると、systemdへの批判には感情的な側面もあります。2010年代にsystemdが主要ディストリビューションへの採用を進めていく過程は、非常に急速でした。
Debian、Ubuntu、Fedora、RHEL——これらが次々とsystemdを採用する過程で、既存のinitスクリプトとの互換性が失われ、「慣れ親しんだ方法が使えなくなった」という反発が生まれました。
技術的優劣とは別に、「変化の速さ」「選択肢が奪われる感覚」への不満も、批判の一部を形成しているのです。
MX Linuxが支持される背景——systemd不採用という設計判断
MX Linuxは、DistroWatchのページヒットランキングで2019年から数年にわたりトップを走り続け、現在も上位を維持している人気ディストリビューションです。その特徴の一つが、systemdを採用せずSysVinit＋runit（または設定によりOpenRC）を使っていることです。
なぜMX Linuxはこれほど評価されるのでしょうか。
「軽さ」だけが理由ではない
「MX Linuxが人気なのは軽いから」という説明をよく見かけます。確かに軽量であることは事実ですが、それだけが理由であれば、もっと軽量なディストリビューションが上位に来るはずです。
MX Linuxの支持には、「設計哲学への共感」という側面があります。
「システム管理の仕組みを自分で把握できる」「シェルスクリプトとして読める起動処理」「不要なコンポーネントを入れない判断」——これらは単純な性能の話ではなく、「コントロール可能なシステムを持ちたい」という考え方の話です。
特に、組み込みシステム・ルーターやNAS・古いハードウェアの活用など、「リソースが限られた環境」でLinuxを使うエンジニアには、systemdの存在感が大きすぎると感じられることがあります。
主要ディストリビューションとMX Linuxの設計比較
| 項目 | systemd採用（Ubuntu・RHEL等） | MX Linux（SysVinit+runit） |
|---|---|---|
| initシステム | systemd | SysVinit / runit（選択可） |
| 起動スクリプト形式 | ユニットファイル（宣言的） | シェルスクリプト（手続き的） |
| ログ管理 | journald（バイナリ） | syslog（テキスト） |
| 並列起動 | 依存関係に基づき並列 | シーケンシャル中心（runit使用時は並列も可） |
| 設定の透明性 | 複雑な依存関係グラフ | スクリプトを読めばわかる |
| エンタープライズ採用 | 主流（RHEL・Ubuntu Server） | デスクトップ・個人用途が中心 |
| コミュニティ規模 | 非常に大きい | 中規模だが熱心なユーザー層 |
「systemd不採用」がアイデンティティになっている
MX Linuxのユーザーコミュニティを見ると、「systemdを使わない」という選択がある種のアイデンティティになっています。これは技術的に正しいか否かとは別の問題です。
「自分の使うシステムについて自分で判断できる」という感覚を大切にするユーザーにとって、systemdの不採用は「選択の結果」を象徴しているのです。
この背景を理解すると、MX Linuxへの評価は単なる「軽量OSの評価」ではなく、「Linuxにおける設計思想の選択」に関する議論の反映だということが分かります。
init系の変遷を知ることが、現場での会話力になる理由
「init系の歴史なんて、現場では使わないでしょ？」と思う方もいるかもしれません。私が20年以上Linuxを教えてきた経験から言うと、この知識は思っている以上に役立ちます。
Linuxのinit変遷：簡略年表
| 時期 | 技術 | 特徴 |
|---|---|---|
| 〜2000年代初頭 | SysVinit | UNIX System Vから継承。ランレベル制御。シーケンシャル起動 |
| 2006年〜 | Upstart（Ubuntu） | イベント駆動型。並列起動に対応。Ubuntu 6.10〜14.04で採用 |
| 2010年〜 | systemd（Fedora15〜） | Lennart Poetteringらが開発。依存関係ベースの並列起動。ユニットファイル方式 |
| 2014〜2015年 | systemd主流化 | Debian・Ubuntu・RHEL7が採用。事実上の標準に |
| 現在 | systemd vs 代替 | OpenRC・runit・s6等が代替として存在。MX Linux・Gentooなどが採用 |
この変遷が「現場の会話力」に直結する場面
たとえば、こんな場面があります。RHEL 6（SysVinit）で運用していたシステムをRHEL 7（systemd）にアップグレードする際、起動スクリプトの書き換えが必要になりました。
このとき、「なぜスクリプトの書き方が変わるのか」を説明できる人と、「マニュアル通りに変えた」だけの人では、チーム内での評価が違います。
また、Dockerコンテナの中でsystemdを動かすのがなぜ難しいか——という議論も、initの動作原理を知っていると即座に理解できます。
Dockerコンテナは基本的にPID 1として特定のプロセスを動かす設計ですが、systemdはPID 1として動くことを前提に設計されており、コンテナ環境ではcgroupの扱いなどで衝突が起きやすい。この説明ができるかどうかが、「設計を理解しているエンジニア」の証明になります。
さらに、クラウド環境（AWS EC2、GCPなど）でLinux AMIを使うとき、OSの起動シーケンスに問題が起きると、cloud-initとsystemdの関係を理解していないと原因調査ができません。
cloud-initはsystemdのターゲット（target）として管理されており、ネットワーク設定やメタデータ取得の順序がサービス起動に影響します。
「なぜそうなっているか」を語れることの価値
3,100名以上を指導してきた経験から言うと、長くエンジニアとして活躍する人には共通点があります。「どうやるか（How）」だけでなく、「なぜそうなっているか（Why）」を語れることです。
「systemdで`systemctl start nginx`を実行する」は誰でも覚えられます。
しかし「systemdのUnit依存関係でnginxがnetwork.targetを待つ設定になっているから、ネットワーク設定より前に起動しようとするとエラーになる」という説明ができるかどうかは、initの仕組みを理解しているかどうかで大きく変わります。
「使えるLinuxエンジニア」と「語れるLinuxエンジニア」の差
ここまで、systemdへの批判の根拠、MX Linuxが支持される背景、init変遷の意味を整理してきました。最後に、これらをどう自分のキャリアに結びつけるかを話します。
「使える」と「語れる」は別のスキルです
現場で求められるスキルには、大きく2つの層があります。「使えるエンジニア」の層：コマンドを正確に実行できる、設定ファイルを読み書きできる、トラブルを解決できる。これは実務に直結する必須スキルです。
「語れるエンジニア」の層：技術の設計思想を説明できる、選択肢の比較ができる、「なぜこの設計か」を答えられる。これは設計・提案・指導の場面で差が出るスキルです。
経験の浅い段階では「使えるエンジニア」になることが先決です。
しかし、ある程度の年数が経ったとき、「この人に聞けば背景まで教えてくれる」という評価を得ている人と、「コマンドは知っているが設計の話になると詰まる」という評価の人に分かれていきます。
systemd論争から得られる学習の具体的ポイント
systemdとinit系の議論を通じて、以下のことを「語れる」ようにすることを目標にしてください。① SysVinitのランレベルとsystemdのターゲットの対応関係
| SysVinitランレベル | systemdターゲット | 意味 |
|---|---|---|
| 0 | poweroff.target | シャットダウン |
| 1 | rescue.target | シングルユーザーモード |
| 3 | multi-user.target | マルチユーザー・CLIモード |
| 5 | graphical.target | グラフィカルモード |
| 6 | reboot.target | 再起動 |
この対応を知っていると、SysVinitで書かれた古いドキュメントとsystemdの設定を結びつけて読める。
RHEL 6→7移行プロジェクトの設計書を読むときにも、即座に対応関係が頭に浮かびます。
② 「並列起動」がsystemdで何を解決したか
SysVinitはサービスをシーケンシャルに（順番に）起動します。サービスAが完全に起動してから、サービスBが起動する。
これはシンプルですが、サービス数が増えた現代のサーバーでは起動時間が長くなる原因になりました。
systemdは依存関係グラフを解析して、「並列に起動できるサービスは同時に起動する」設計を採りました。
これがブート時間の短縮に大きく貢献した理由です。
この仕組みを知っていると、「なぜsystemdへの移行が推進されたか」を、感情論ではなく技術的事実として説明できます。
③ 今もsystemdを使わない選択肢がある理由
「systemdが主流になったなら、他の選択肢を知る意味があるのか」という疑問は正当です。
しかし、以下の文脈では今もinit代替が現役です。
・組み込みLinux・ルーター・IoTデバイス（BusyBox環境）
・Gentoo Linux（OpenRC採用）
・Alpine Linux（OpenRC採用）
・MX Linux（SysVinit+runit）
・セキュリティ重視の最小構成システム
特に、Dockerの公式イメージで多く使われるAlpine Linuxはapk(Alpine Package Keeper)を使い、OpenRCを採用しています。
コンテナ技術を使うエンジニアにとって、systemd以外のinit系を知ることは実用的な意味があります。
FAQ：受講生からよく来る質問
Q. systemdの批判を知ると、今後もsystemdを使い続けるべきか迷いますA. 企業のサーバー（RHEL・Ubuntu Server）を管理するエンジニアにとって、systemdを使うことは現状では必須です。批判の背景を知ることと、実務でsystemdを使うことは矛盾しません。「なぜ批判があるかを理解した上で使う」のが現場では最も価値があります。
Q. MX Linuxを使うと、サーバー管理のスキルが身につきますか
A. 学習環境としては有益ですが、サーバー管理のスキルを身につけるなら、エンタープライズで使われているUbuntu ServerやRHEL/AlmaLinuxで学ぶことをお勧めします。MX Linuxはsystemdの代替を体験するには良いですが、現場のサーバー環境と乖離があります。
Q. systemdのログが読みにくいのですが、コツはありますか
A. `journalctl` のオプションを覚えることが近道です。よく使うオプションを整理します。
| コマンド | 用途 |
|---|---|
journalctl -xe |
最新のログをエラー詳細付きで確認 |
journalctl -u nginx |
nginxサービスのログのみ表示 |
journalctl --since "2026-01-01 00:00:00" |
日時を指定してログを絞り込む |
journalctl -f |
リアルタイム追尾（tail -f に相当） |
journalctl -p err |
エラー以上の重要度のみ表示 |
Q. init系の違いは資格試験に出ますか
A. LPICやLinuCでは、SysVinitとsystemdの両方に関する問題が出題されます。特に「SysVinitのrunlevelとsystemd targetの対応」「systemctlコマンドの使い方」は頻出です。試験対策としても、両方を理解しておくことは有益です。
「どちらが正解か」より「どちらを選んだか語れるか」
最終的に、私がこの議論を通じて受講生に伝えたいのは一点です。「systemdが正解か、SysVinitが正解か」という問いに、絶対的な答えはありません。
ただ、「このシステムではsystemdを使います。理由は並列起動でブートを速くしたかったからで、ログ管理にはjournaldを使いますが、テキストログへのエクスポートも設定しています」という説明ができるエンジニアと、「とりあえずsystemdが標準だから」というエンジニアの差は、設計レビューや障害対応の場で明確に現れます。
同様に、「このシステムではOpenRCを採用しています。理由は組み込み環境でsystemdのフットプリントが大きすぎたためです」と説明できるエンジニアは、systemdを使うシステムも理解した上で、別の選択をしていることが伝わります。
MX Linuxへの注目が示しているのは、「Linuxにおける設計の選択について、自分の意見を持つユーザーが増えている」という事実です。
エンジニアとしても、その流れを「ベテランの懐古趣味」と切り捨てるのではなく、「なぜその選択肢が評価されるのか」を理解することで、自分の視野を広げる機会にしてほしいのです。
まとめ：現場で差がつく「init設計の知識チェックリスト」
この記事を通じて整理したポイントを、現場で「語れる」かどうかのチェックリストとしてまとめます。【systemdの基本】
□ SysVinitとsystemdの設計思想の違いを1分で説明できる
□ systemd批判の主な根拠（UNIX哲学との乖離・バイナリログ）を技術的に説明できる
□ journaldのログを読むコマンド（journalctl）を5種類以上使える
□ SysVinitのランレベルとsystemd targetの対応を覚えている
【init代替の知識】
□ OpenRC・runit・s6の名前と採用OSを言える
□ MX Linuxが人気な理由を「軽さ以外」の観点で説明できる
□ Alpine Linuxがsystemdを採用していない理由を説明できる
【設計判断力】
□ コンテナ環境でsystemdを使うことが難しい技術的理由を説明できる
□ cloud-initとsystemdの関係を説明できる
□ 「なぜsystemdが主流になったか」を並列起動の観点で説明できる
全部にチェックが入る必要はありません。
ただ、半分以上にチェックが入るなら、init設計について「語れるエンジニア」の領域に入っています。
使えるエンジニアから語れるエンジニアへ——この一歩が、現場での評価の差になっていきます。
「語れるLinuxエンジニア」への最初の一歩を踏み出しませんか？
systemdの設計思想もinit系の変遷も、「コマンドを動かせる」だけでは見えてきません。
現場で通用するLinuxサーバー構築の「型」と「なぜそうなっているか」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます