やりたかったこと（または「症状」）
契約している軽量プランのVPSに公式手順どおりDockerをインストールし、動作確認のためにdocker psを実行したところ、デーモンに接続できないというエラーが出た。
docker ps
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory
デーモンが起動していないのだろうと判断し、systemctlでDockerサービスを起動しようとしたが、こちらも別のエラーで失敗した。
systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
インストール自体はエラーなく完了していたし、docker --versionでクライアントのバージョンも正しく表示される。それなのにサービスの起動コマンドがそもそも受け付けられない状態で、最初は何が起きているのか分からなかった。
環境
- OS: Ubuntu 24.04.4 LTS
- 実行環境: 軽量プランのVPS（LXCベースのコンテナ仮想化。KVMではなくOSレベル仮想化のプラン）
- Docker: 29.3.1（公式インストールスクリプト経由）
- init: PID 1がsystemdではなく、コンテナのランチャープロセスになっている
試したこと
まずserviceコマンド（SysVinit経由）でも同じように起動できないか試した。
service docker start
* Docker is not running
service docker status
* Docker is not running
serviceコマンド自体はエラーなく実行できたが、実際にはDockerは起動していなかった。次に、そもそもこのサーバーでsystemdがPID 1として動いているか確認した。
ps -p 1 -o pid,comm
PID COMMAND
1 tini
PID 1がsystemdではなくtini（軽量な初期化プロセス）になっていた。これでsystemctlが「System has not been booted with systemd as init system」と言っていた理由が分かった。このVPSはKVM等のフル仮想化ではなく、コンテナ型の軽量仮想化プランで、ホスト側のinitプロセスをそのまま使う構成になっており、systemdそのものが存在しない、あるいはPID 1として動いていない環境だった。
原因
systemctlやserviceコマンドは、systemdのinitプロセス（PID 1）にsocket経由で命令を送ることでサービスを起動・停止している。今回の環境ではPID 1がtiniであり、systemdがそもそも稼働していなかったため、systemctl start dockerは「systemdとして起動していないので操作できない」というエラーで即座に失敗していた。dpkgや公式インストールスクリプトはDockerパッケージ自体（dockerd本体やCLI、docker.serviceユニットファイル）を正しく配置してくれるが、そのユニットファイルを実際に起動する仕組み（systemd）が環境に存在しなければ、サービスとしての自動起動はできない。つまり原因は「Dockerのインストールミス」ではなく、「このVPSプランがsystemdベースのinitを持たない仮想化方式である」という環境側の制約だった。
解決方法
1. PID 1がsystemdかどうかを確認する
ps -p 1 -o comm=
systemd以外（tiniやinitなど）が返ってきた場合、systemctl／serviceでのDocker管理はそもそも成立しない。
2. dockerdを直接起動する
systemdに頼らず、dockerdをバックグラウンドプロセスとして直接起動する。
dockerd > /var/log/dockerd.log 2>&1 &
数秒待ってからログの末尾を確認し、API listen on /var/run/docker.sockが出ていれば起動成功。
tail -5 /var/log/dockerd.log
time="2026-07-29T00:10:25.601757834Z" level=info msg="Docker daemon" commit=f78c987 containerd-snapshotter=true storage-driver=overlayfs version=29.3.1
time="2026-07-29T00:10:25.640565695Z" level=info msg="Daemon has completed initialization"
time="2026-07-29T00:10:25.640910959Z" level=info msg="API listen on /var/run/docker.sock"
3. 動作確認する
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
エラーなく空のコンテナ一覧が返ってきて、デーモンに接続できるようになった。
4. 再起動後も自動で立ち上がるようにする
&でバックグラウンド起動しただけでは、サーバー再起動後に再度手動でdockerdを叩く必要がある。恒常的に使う場合は、環境が対応していればsupervisord等のプロセスマネージャにdockerdを登録するか、起動スクリプト（/etc/rc.local相当）に起動コマンドを追記して、サーバー起動時に自動実行されるようにしておく。
ハマったポイント
-
service docker startが「エラーなく」終了したように見えたため、一瞬起動できたのかと勘違いした。実際には裏でsystemd未検出により何もしていなかった。service docker statusまで必ず確認する必要があった - インストールスクリプトが成功メッセージを出していたため、Docker自体のインストール手順を何度もやり直してしまい、時間を無駄にした。原因はインストールではなくinitシステム側にあった
-
dockerdをフォアグラウンドで動かしたままSSHセッションを切断すると、プロセスごと終了してDockerが止まってしまう。&でバックグラウンド化するか、nohup／disownを併用する必要がある
よくある質問
Q: このエラーはWSLでも出ますか？
WSL1やsystemdを有効化していないWSL2ディストリビューションでも、PID 1がsystemdでないため同様のエラーが出ることがある。WSL2でsystemdサポートが有効になっている場合は通常どおりsystemctlが使える。
Q: dockerdを直接起動する方法は本番運用でも問題ないですか？
恒常的に稼働させるなら、SSH切断で落ちないようプロセスマネージャ（supervisord等）で管理することを強く推奨する。手動での&起動はあくまで動作確認や一時的な用途向け。
Q: そもそもこの仮想化方式のVPSでDocker（Docker in Docker相当）を使うこと自体に制約はありますか？
コンテナ型仮想化の環境では、カーネル機能の一部がホストと共有されるため、ネットワークやcgroup周りで通常のKVM環境と挙動が異なる場合がある。今回のケースではdocker ps自体は正常に動いたが、環境によってはさらに追加の対応が必要になることもある。
関連記事
- VPSにDockerをインストールしてWebサーバーを構築する方法
- Dockerの基本コマンドまとめ
- dockerコマンドがpermission deniedになる時の対処法
- docker-composeの基本的な使い方
- 不要なDockerイメージを整理する方法
この記事は errsolved.com にも掲載しています。