Docker起動時に実行するDDL,DMLの検証のために色々ガチャガチャやってたら起動できなくなって、その原因と対処法が分かったのでメモ。

 

エラー内容

FATAL: configuration file "/var/lib/postgresql/data/postgresql.conf" contains errors
LOG: could not open configuration file "/var/lib/postgresql/data/postgresql.conf": No such file or directory

postgresql.sqlがないって言われてますね。

よく見るNo such file or directoryです。

 

ちなみに、ガチャガチャやってる過程で以下のエラーも発生しました。これもいっしょに解消しました。

LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.auto.conf"
FATAL: "/var/lib/postgresql/data" is not a valid data directory
DETAIL: File "/var/lib/postgresql/data/PG_VERSION" is missing.

 

以下のissueでも少し触れられていますね。

https://github.com/void-linux/void-packages/issues/13377

 

発生環境

Dockerの仕様で発生していると思われます。

Dockerのバージョン以外はあんまり関係ないのかなと思いますが、Windows版のDockerでは発生したことがないのでどうか分からないです。

• Apple Silicon M3
• macOS Sequoia v15.2
• Docker v27.4.0
• PostgreSQL v16.4(v17.2も発生)

 

発生原因

原因は、ホスト側にマウントしているPostgreSQLのファイルを削除したからでした。

 

以下の手順で削除したんですが、ダメだったようです。

 

Dockerコンテナ削除

↓

ボリューム削除

↓

PostgreSQLのファイル削除

↓

Docker Image削除

 

の順番に削除して、再度docker-compose upでコンテナ起動すれば完全に初期化できるやろーって思って安易に削除したのが良くなかったみたいです。

だってImageまで消してれば全部なかったことにできそうじゃんねぇ。

解決方法

エラーの解決方法は、ホスト側PCにあるマウント先のディレクトリ(PostgreSQLのファイルがあるディレクトリ)ごと削除することです。

 

理屈は分かりませんが、ディレクトリが残っていると、「ファイルがない状態にした」つもりが、「ファイルを削除する操作をした」ことになっているんでしょうね。

Dockerがその辺の情報を管理しているのは少し意外ですが、こう考えるのが自然かなと。

 

まぁ、双方向バインディングみたいな状態だからそうなるのか🤔

 

そのため、マウント先のディレクトリを削除して、再度同じ名前のディレクトリを作成することで、このエラーは解消できます。

 

まとめると、以下の手順で再作成ができます。

1. docker-compose stop(またはdocker stop)でコンテナを停止
2. Dockerコンテナ削除
3. ボリューム削除
4. マウント先のディレクトリごとPostgreSQLのファイルを削除
5. Docker Image削除
6. マウント先のディレクトリを再作成
7. docker-compose up(またはdocker run)

 

PostgreSQLの場合、起動時にDDL, DMLを実行するように設定していると、完全初期化したいケースって多いんじゃないですかね？

その割に記事が少ないような気もしますが…。

 

もっといいやり方ある場合は教えてください。