やりたかったこと（または「症状」）

契約している軽量プランの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自体は正常に動いたが、環境によってはさらに追加の対応が必要になることもある。

関連記事

この記事は errsolved.com にも掲載しています。