PostgreSQL 再構築でスタック

皆さん、こんにちは。

アプリを再構築しようとした際にPostgreSQLの起動問題に遭遇しており、ヘルプを求めています。

ログは以下の通りで、30分以上この状態のままです。

Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1]  INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.362740 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.367767 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.372845 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377501 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377876 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres & && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-08-26T17:16:15.453058 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1]  INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG:  database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG:  redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG:  invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG:  redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG:  database system is ready to accept connections

正常にシャットダウンされず、修復を試みましたが、完了したと考えているようです。

おそらく、Ctrl+Cで終了し、./launcher start app を実行して古いコンテナを再度起動できるか確認してください。

それが機能すれば、./launcher stop app を試してから再構築できます。

「いいね!」 3

ここ数日、再構築を試みて同じ問題に直面しています。Discourse を問題なく実行または再構築することができません。

開始/停止機能を使ってみましたが、機能しないようです。VM 自体も数回再起動しました。データベースが接続を受け入れる準備ができたという行で、常にハングアップします。

Control-C が機能せず、古いバージョンに戻すことも含め、さまざまなことを試しましたが、リビルドを試みると、まったく同じ場所でスタックしてしまいました。

RAMはどれくらいありますか?ネットワーク接続は遅いですか?

問題についてですが、RAMは8GBと十分あり、ネットワークも問題ありません。

4GB RAM、ネットワーク、ディスク使用率、CPU使用率、RAM使用率を確認しましたが、すべて正常に見えます。

さらに進捗がありました。サーバーの /var/discourse/ で、コミット b1108913820edd27f869634d0fc654639758889a をチェックアウトしました。このコミットは数日前のもので、discourse_docker の履歴にあるこれらの3つのコミット (1, 2, 3) は含まれていません。これらの変更のいずれかが、ハングしている postgres の原因であると疑っています。

とにかく、アプリを再び起動させることができました。ひどい経験でした(笑)

「いいね!」 3

こちらでも3.3.0から3.3.1へのアップグレード時に同様の問題が発生しました。アップグレードは同じログ行(データベースシステムは接続を受け入れられる状態です)で停止します。

再起動するか、アップグレードプロセスを強制終了して ./launcher start app を実行すると解決します。新しいバージョン3.3.1が表示されます。しかし、これが安全な手順かどうかは不明です。

つまり、問題があるのは4人だと思います。

ARMをお使いの方とIntelをお使いの方、どちらで問題が発生しましたか?

「いいね!」 1

それは素晴らしい質問ですね。

新しいDigital Ocean VMにクリーンインストールを実行し、その後再構築を実行したところ、問題なく動作しました。

Intelを使用しています。

問題を解決した方法は、新しいドロップレットを開始し、クリーンインストールを実行してバックアップを復元したところ、再構築が正常に機能したことです。

動作中のバージョン(わずかに古いバージョン)のバックアップもありますが、再構築で最新バージョンにアップグレードした直後に同じ問題が発生したため、最近のコミットで導入された何かが古いバージョンから新しいバージョンへの更新のみを壊しているのではないかと疑っています。

「いいね!」 1

残念です。

うーん。壊れても気にしないサイトがあるか確認してみます。

標準的な1コンテナの標準インストールをお使いだと思います。それを見つけられるか確認してみます。

これも、上記のコミット以降、この問題を確認しています。問題を解決するために上記すべてを試しました。

「いいね!」 2

x86。ホストOSはUbuntu Bionicを使用しています…これは関係があるかもしれません。他の人のOSが何であるかはわかりません

EOL(サポート終了)から1年以上経過しています。https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices

新しい仮想マシンを起動してそちらに移行しても、早すぎるということはありません。

「いいね!」 4

問題の調査に役立つ追加情報です。

これは Ubuntu 18.04.6 を実行しているホストの 1 つで発生していますが、今日同じバージョンの Ubuntu を使用して更新された別のホストでは、Discourse の再構築は正常に進みました。

影響を受けているホストで Ubuntu をアップグレードしてみて、それが役立つかどうかを確認します。進捗を皆さんに報告します。

「いいね!」 2

影響を受けている方は、ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" コマンドを実行し、以下の出力と異なるかどうか教えていただけますでしょうか。

drwxr-xr-x  2  101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19  101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x  3  101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 01:38 redis_data
「いいね!」 1
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dec 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data
「いいね!」 2

VM の再構築の問題が発生している場合の出力:

drwxr-xr-x  2  101 104 4.0K Jun 15  2020 postgres_backup
drwx------ 19  101 104 4.0K May  3  2022 postgres_data
drwxrwsr-x  5  101 104 4.0K May  3  2022 postgres_run
drwxr-xr-x  2  103 106 4.0K May  3  2022 redis_data

私の場合は少し異なります。
再構築は、他の人が経験したように「データベースシステムは接続を受け入れる準備ができました」でスタックしました。VM を再起動し、./launcher start app を実行してフォーラムを開始する必要がありました。しかし、Discourse が復旧した後、Discourse のバージョンは以前のバージョン 3.3.0.beta4-dev のままでした。

本日 Ubuntu のアップグレードを実行できませんが、実行可能になり、再構築が成功した場合は、全員に進捗状況を報告します。

本日、開発インスタンスを Ubuntu 20.6 に更新し、再構築/アップグレードは Discourse 3.4.0.beta2-dev で成功しました。ただし、これは昨日 Ubuntu 18.4 で問題なく再構築されたホストでもありました。