現在、多くのLinuxディストリビューションでは systemd が標準の初期化システムとして使われている。
サービス管理、ログ管理、起動制御までを一元化したsystemdは、確かに強力で便利だ。
「Linuxのトラブル 2」では、
journalctl によるログ確認、
systemctl を使ったサービス管理、
Timeshift による巻き戻しといった、
systemd前提のトラブル対処の型を整理してきた。
この型が身につくと、
Linuxのトラブルは「怖いもの」ではなく
管理できる事象として扱えるようになる。
しかし、ここで一つ重要な事実がある。
しかし、Linuxの世界では systemdが絶対の前提というわけではない。
軽量さを重視するディストリビューションや、
伝統的なUnixの思想を大切にする環境では、あえてsystemdを採用しない選択が取られている。
Alpine Linux、Void Linux、Artix Linux、Devuan などがその代表例だ。
こうした環境では、
systemctlが存在しないjournalctlでログを確認できない- サービスの起動や停止方法が全く異なる
といった状況が当たり前に起こる。
その結果、
「ネットで調べた手順をそのまま実行したら、そもそもコマンドが存在しなかった」
「解説通りに進めているのに、話が噛み合わない」
といった混乱に陥りやすい。
これは知識不足ではない。
前提となる仕組みが違うだけだ。
本記事では、
systemdを使わない環境でトラブルに直面したとき、
- 何を基準に考えればよいのか
- どこを見て切り分ければよいのか
- systemd前提の情報とどう付き合えばよいのか
といった 考え方の軸 を整理していく。
systemdがないからといって、Linuxが難しくなるわけではない。
むしろ、
「Linuxが本来どう動いているのか」を理解する絶好の機会でもある。
systemd前提の世界から一歩外に出たとき、
トラブルをどう捉え、どう解決していくのか。
ここから、その原点回帰の視点を身につけていこう。
systemdが使えない使わない環境とは何か
systemdを前提にした解説が通用しない最大の理由は、
「その環境では、そもそもsystemdが存在しない」からだ。
Linuxは一枚岩のOSではない。
同じLinuxカーネルを使っていても、起動方式や管理思想はディストリビューションごとに大きく異なる。
まずは、systemdを採用しない、あるいは意図的に排除している環境があることを押さえておこう。
systemd非採用ディストリの例
systemdを使わない代表的なディストリビューションには、次のようなものがある。
Alpine Linux
非常に軽量で、コンテナやサーバ用途で多く使われる。
起動管理には OpenRC を採用しており、systemdは最初から含まれていない。
Void Linux
シンプルさと高速起動を重視したディストリビューション。
runit という独自のinitシステムを使い、systemdとは完全に異なる管理方式を取る。
Artix Linux
Arch Linux互換を保ちつつ、systemdを排除したディストリビューション。
OpenRC / runit / s6 など複数のinitシステムを選択できる。
Devuan
Debianからsystemdを取り除いた派生ディストリビューション。
従来のSysVinitなどを使い、systemd導入以前の思想を維持している。
古い環境・組み込みLinux
ルーターや家電、古いサーバなどでは、systemdが存在しないLinuxが今も現役だ。
限られたリソースの中で動かすため、単純な起動方式が選ばれることが多い。
これらの環境では、systemctl や journalctl を使った操作は 最初から想定されていない。
systemdと何が違うのか
systemdを使わない環境を理解する鍵は、
PID 1（最初に起動するプロセス）の役割にある。
Linuxでは、起動直後に最初に動くプロセスが PID 1 になる。
systemd環境では、このPID 1をsystemdが担い、
- サービスの起動・停止
- 依存関係の管理
- ログの収集
- 再起動や障害検知
といった多くの役割を一手に引き受けている。
一方、systemdを使わない環境では、この役割が分散されている。
- 起動スクリプトは init / rc スクリプトが担当
- サービスの監視は runit や s6 が担当
- ログは syslog や個別ファイルに出力
つまり、
systemdが行っていたことを「複数の小さな仕組み」で支えている状態だ。
これは
「何でも一つにまとめる（統合）」systemd と、
「役割ごとに分ける（分離）」非systemd環境
という思想の違いでもある。
systemdが便利なのは、
「全部を一つのコマンド体系で扱える」からだ。
だが、systemdがない環境では、
「何がどこで動いているか」を自分で把握する力が求められる。
ここを理解できれば、
systemd前提の記事が通用しない理由も腑に落ちるはずだ。
systemd前提のトラブル解説が通用しない理由
systemdを使わない環境でトラブルに遭遇したとき、多くの人が最初に感じるのは「自分の操作が間違っているのではないか？」という不安だ。
だが実際には、
やり方が間違っているのではなく、前提が違うだけというケースがほとんどである。
ここでは、systemd前提の解説が通用しない理由を、
よくある混乱ポイントごとに整理していく。
systemctl が存在しない
トラブルが起きたとき、真っ先に検索すると、
多くの記事が次のような操作を勧めてくる。
systemctl status サービス名
systemctl start サービス名
systemctl enable サービス名しかし、systemdを使わない環境では、
systemctl というコマンド自体が存在しない。
その結果、
command not found: systemctlという表示が出て、
エラーの原因を調べる以前の段階で足止めを食らう。
これは設定ミスでも、インストール失敗でもない。
そもそも、その操作体系が採用されていないだけだ。
systemd前提の世界では「サービス＝systemctlで操作するもの」だが、
非systemd環境では、サービスの起動・停止方法そのものが異なる。
ここに気づかないと、
「なぜ説明通りにやっているのに動かないのか」という迷路に入り込む。
journalctl が使えない
次に直面するのが、ログの問題だ。
systemd環境では、
journalctl -xeを実行すれば、
ほぼすべてのシステムログを一括で確認できる。
しかし、systemdを使わない環境では
journalctl も存在しない。
ログは一元管理されておらず、
- /var/log/ 配下の個別ファイル
- サービスごとの独自ログ
- 標準出力・標準エラーに流れるメッセージ
といった形で分散している。
その結果、
「エラーは出ているはずなのに、どこを見ればいいかわからない」
という状況に陥りやすい。
systemd環境では「まず journalctl」という共通ルートがあるが、
非systemd環境では
ログは自分で探しに行くものだ。
ネット記事とのズレ
混乱に拍車をかけるのが、ネット上の情報とのズレだ。
現在、Linux関連の記事や解説の大多数はsystemd前提で書かれている。
ディストリビューション名が明記されていない場合、
ほぼ間違いなくsystemd環境を想定していると考えていい。
そのため、
- 書いてある通りにやってもコマンドが通らない
- 表示されるエラーが記事と一致しない
- 話が途中から噛み合わなくなる
といった事態が頻発する。
ここで重要なのは、
記事が間違っているわけでも、自分が下手なわけでもないということだ。
単に、
「systemdという前提が共有されていない」だけなのである。
このズレに気づけるようになると、
「この解説は自分の環境に合っているか？」
という視点を自然に持てるようになる。
systemdなし環境での「サービス管理」の考え方
systemdが使えない環境でトラブルに対応するには、
まず「サービスとは何か」を改めて捉え直す必要がある。
systemd環境では、
サービスは systemctl で管理する抽象的な存在として扱われがちだ。
だが、systemdがない世界では、もっと素朴で直接的な形に戻る。
initシステムという概念
Linuxでは、起動時に動く最初の仕組みを initシステム と呼ぶ。
これは「何を、どの順番で起動するか」を決める役割を持つ。
systemdがない環境では、主に次のようなinitシステムが使われる。
SysVinit
古くから使われてきた伝統的な方式。/etc/init.d/ にあるスクリプトを順番に実行してサービスを起動する。
シンプルだが、依存関係は基本的に人間が管理する。
OpenRC
SysVinitをベースにしつつ、依存関係の記述を可能にした方式。
Alpine Linuxなどで採用されている。
サービスはスクリプトとして定義され、状態管理は比較的軽量だ。
runit
Void Linuxなどで使われる、非常に単純な仕組み。
「起動する」「監視する」という役割に特化しており、
設定はディレクトリ構造で表現される。
s6
runitと同じ思想を持ちつつ、より厳密で高機能なinitシステム。
組み込みや高度な制御を必要とする環境で使われることが多い。
重要なのは、
どの方式も「systemdではない」という点だ。
initシステムが違えば、
サービスの起動方法も、管理の仕方も変わる。
まずは「自分の環境がどのinitを使っているか」を知ることが第一歩になる。
「サービス＝プロセス」という原点回帰
systemdなし環境を理解する最大の鍵は、
サービスを「プロセス」として捉えることだ。
サービスとは、結局のところ、
- バックグラウンドで動き続けるプログラム
- 常駐して仕事をするプロセス
にすぎない。
systemd環境では、
このプロセスの存在をsystemdが包み隠して管理してくれる。
だが、systemdがない環境では、
その裏側がそのまま見える。
- どのコマンドが実行されているのか
- どのユーザー権限で動いているのか
- 本当に起動しているのか
こうした点を、自分の目で確認する必要がある。
逆に言えば、
プロセスの正体が見えれば、サービス管理は怖くない。
起動していなければ起動する。
暴走していれば止める。
設定が間違っていれば直す。
systemdが提供していた便利さは失われるが、
その代わりに、
Linuxが本来どう動いているのかを理解する力が身につく。
この視点を持てるようになると、
systemdあり・なしに関係なく、
トラブル対応の基礎体力が一段上がる。
systemdがない環境での基本トラブル切り分け
systemdがない環境では、
「とりあえず status を見る」「再起動すれば直る」といった手軽な逃げ道はない。
その代わり、原因を一つずつ確認していく力が重要になる。
ここでは、systemdなし環境でトラブルが起きたときの
基本的な切り分けの考え方を整理する。
起動しないサービスの考え方
サービスが起動しないとき、
まず確認すべきなのは「そのサービスは、どうやって起動されるのか」だ。
systemd環境では unit ファイルを探せばよかったが、
非systemd環境では、起動処理はスクリプトとして存在していることが多い。
/etc/init.d/にスクリプトはあるか- OpenRC や runit の管理ディレクトリに定義はあるか
次に見るべきは 実行権限 だ。
スクリプトが存在していても、実行権限がなければ起動しない。
ls -l スクリプト名で、実行可能になっているかを確認する。
さらに、依存関係にも注意する。
systemdのように自動で順序を解決してくれる仕組みがない場合、
必要なサービスが先に起動していなければ、後続のサービスは失敗する。
起動しない原因は、
「スクリプトがない」「権限がない」「前提が満たされていない」
このどれかであることがほとんどだ。
ログは「自分で探す」
systemdがない環境では、
ログは一か所にまとまっていない。
そのため、
「ログはどこにあるか」を自分で考える必要がある。
基本となるのは /var/log/ ディレクトリ だ。
ここには、
- システム全体のログ
- サービスごとのログ
- エラー専用のログ
などが、ファイル単位で保存されている。
サービス名を手がかりに、
関連しそうなログファイルを探すのが基本になる。
それでも見つからない場合は、
標準出力（stdout）や標準エラー（stderr） に注目する。
サービスを手動で起動したときに、
画面に直接表示されるエラーメッセージは、
最も生の情報だ。
systemdが隠してくれていた「声」を、
自分の目と耳で拾い上げる感覚を持つとよい。
自動起動の仕組みを理解する
「手動では起動するのに、再起動すると動かない」
これは、非systemd環境で非常によくあるトラブルだ。
原因の多くは、
自動起動の設定がされていないことにある。
SysVinit系では、
起動時に実行される rc スクリプトや runlevel の設定が重要になる。
runit環境では、
特定のディレクトリにサービス用のフォルダが存在するかどうかが鍵だ。
systemdでの enable は、
「自動起動を登録する」という意味だったが、
非systemd環境では、そのやり方が環境ごとに異なる。
そのため、
「enableしたつもり」という感覚は通用しない。
- どの仕組みが起動時に読まれるのか
- そこに自分のサービスは登録されているか
これを確認できるようになると、
起動トラブルの多くは解決できる。
systemdなし環境で役立つ基本コマンド
systemdがある環境では、
多くの情報を systemctl や journalctl がまとめて見せてくれる。
だが、systemdがない環境では、
自分で事実を集める力がそのままトラブル対応力になる。
ここで紹介するコマンドは派手ではない。
しかし、これらを使いこなせるようになると、
systemdの有無に関係なく状況を把握できるようになる。
ps / grep / kill
生きているかどうかは自分で確認する
systemd環境では、
「サービスが起動しているかどうか」をsystemctl status 一発で確認できた。
非systemd環境では、
プロセスが存在しているかどうかを自分で見る。
ps aux | grep サービス名これで、
- 本当に起動しているのか
- 想定したユーザーで動いているか
- 複数起動していないか
といった事実を確認できる。
プロセスが暴走している、
あるいは終了しない場合は kill を使う。
kill プロセスIDそれでも止まらない場合の kill -9 は、
「最終手段」であることを忘れてはいけない。
systemdがいない環境では、
プロセス管理の責任がそのまま利用者に返ってくる。
ss / ip / ping
ネットワークはサービス以前に確認する
ネットワーク系のトラブルでは、
「サービスが動いているか」を疑う前に、
通信そのものが成立しているかを確認する。
まずは疎通確認だ。
ping アドレス次に、
どのポートが待ち受けているかを確認する。
ss -lntupこれで、
- サービスがポートを開いているか
- 別のプロセスが奪っていないか
といった点が見えてくる。
IP設定の確認には ip コマンドを使う。
ip addr
ip routesystemd環境では NetworkManager などが隠していた部分を、
生の状態で見る感覚が大切になる。
dmesg / tail
最低限の「事実確認手段」
ログが一元化されていない環境では、
即座に確認できる情報源が重要になる。
dmesg は、
カーネルが出力したメッセージを表示するコマンドだ。
- デバイス認識の失敗
- ドライバ関連のエラー
- 起動直後の問題
といった、systemd以前のレイヤーの問題が見えてくる。
ログファイルの追跡には tail を使う。
tail -f ログファイルサービスを起動しながらこれを実行すれば、
何が起きているかをリアルタイムで確認できる。
systemdのように整形された情報はないが、
代わりに「加工されていない事実」が手に入る。
systemdなし環境で詰まりやすいポイント
systemdを使わない環境は、軽量でシンプルな反面、
「面倒を見てくれる存在」がほとんどいない。
ここでは、
多くの人が同じところで詰まるポイントを整理しておく。
「自動で何かしてくれない」問題
非systemd環境で最初に感じるのは、
何も自動でやってくれないという戸惑いだ。
systemd環境では、
- 依存関係の解決
- 起動順序の調整
- 再起動時の自動復旧
といったことを、ほぼ意識せずに使えていた。
しかし、systemdがない環境では、
これらは基本的に自分で考える前提になる。
- このサービスは、何が起動していれば動くのか
- 先に起動すべきものは何か
- 失敗したとき、再実行されるのか
起動順序を誤れば、
「手動では動くのに、自動起動だと失敗する」
といった現象が起きる。
これは欠点というより、
Linuxの仕組みがそのまま見えている状態だ。
ここを理解できるようになると、
systemd環境に戻ったときでも、
「裏で何が起きているか」を想像できるようになる。
ドキュメントが少ない不安
もう一つの壁は、
情報が少ない、または見つからないという不安だ。
非systemdディストリは、
利用者が少ない分、日本語情報も限られている。
検索しても、systemd前提の記事ばかりが出てくる。
そこで重要になるのが、
公式ドキュメントを起点にする姿勢だ。
- ディストリビューションの公式Wiki
- initシステムの公式ドキュメント
これらは、情報量は少なくても、
「その環境で正しいこと」だけが書かれている。
また、Arch Wikiは非常に強力な資料だが、
そのまま真似するのは危険な場合もある。
Arch Wikiは、
- 仕組みの説明
- 考え方の整理
を借りる場所だと割り切るとよい。
コマンドや設定例は、
自分の環境に合うかを必ず確認する。
この一手間が、迷子になるのを防いでくれる。
systemdを使わない選択のメリットと覚悟
systemdを使わない、という選択は
「流行に逆らう」ことでも
「上級者向けを気取る」ことでもない。
それは、
何を重視してLinuxを使いたいか
という価値観の選択だ。
仕組みが見えやすい
systemdを使わない最大のメリットは、
Linuxの動きがそのまま見えることだ。
サービスはスクリプトとして存在し、
起動順序も、依存関係も、
人間が読める形で書かれている。
- なぜ起動したのか
- なぜ失敗したのか
- どこで止まっているのか
これらがブラックボックスになりにくい。
systemd環境では便利さと引き換えに隠れていた
「PID 1の役割」「プロセス管理」「起動の流れ」を、
自然に理解できるようになる。
これは遠回りに見えて、
Linuxの基礎体力を鍛える近道でもある。
代わりに求められるもの
一方で、
systemdを使わない環境は、
利用者に多くを求める。
- 読む力
エラーメッセージ、ログ、スクリプトを読む力 - 切り分ける力
どこまでがカーネルで、どこからがサービスなのかを考える力 - 自分で調べる姿勢
答えがすぐに見つからなくても、掘り下げる姿勢
systemdがやってくれていたことは、
決して「不要」だったわけではない。
それを自分で引き受ける覚悟が必要になる。
しかし、その覚悟を持てたとき、
Linuxは「使われるOS」から
「自分で使いこなすOS」に変わる。
systemdなし環境は、万人向けではない。
だが、Linuxの本質に触れたい人にとっては、
これ以上ない教材になる。
systemdがあってもなくても、
「何が起きているかを自分で説明できる」
そんなLinuxユーザーになるきっかけになれば幸いだ。
