PostgreSQL завис при перестроении

Поддержка Самостоятельное хостинг
1

Всем привет,

У меня возникла проблема с запуском 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```
2

Похоже, оно не завершилось корректно, попыталось что-то исправить и теперь считает, что всё в порядке.

Попробуйте прервать процесс с помощью Ctrl+C и запустить ./launcher start app, чтобы снова поднять старый контейнер.

Если это сработает, попробуйте ещё раз выполнить ./launcher stop app, а затем пересобрать.

3

У меня тоже возникает такая же проблема при попытке пересобрать систему в последние несколько дней. Я не могу запустить или пересобрать Discourse без ошибок.

Я пробовал использовать возможности запуска/остановки, но это, похоже, не сработало. Сама виртуальная машина также перезагружалась несколько раз. Система просто зависает на строке о том, что база данных готова принимать подключения.

4

Ctrl+C не сработал, и я перепробовал множество разных вещей, включая откат к старым версиям, но как только я попытался выполнить пересборку, процесс завис в том же самом месте.

5

Сколько у вас оперативной памяти? Ваше сетевое соединение медленное?

6

По поводу моей проблемы… памяти достаточно — 8 ГБ. С сетью всё в порядке.

7

4 ГБ ОЗУ. Я проверил сеть, использование диска, процессора и оперативной памяти — всё в порядке.

8

Мне удалось добиться дальнейшего прогресса. В директории /var/discourse/ на моём сервере я переключился на коммит b1108913820edd27f869634d0fc654639758889a. Этот коммит сделан несколько дней назад и не содержит трёх следующих коммитов (1, 2, 3) из истории discourse_docker. Я подозреваю, что одно из этих изменений стало причиной зависания PostgreSQL.

В любом случае, в итоге приложение снова запущено. Это был ужасный опыт, lol.

11

Та же проблема при обновлении с версии 3.3.0 до 3.3.1. Обновление застревает на той же строке лога (система базы данных готова принимать подключения).

Помогает перезагрузка или просто завершение процесса обновления и запуск команды ./launcher start app. Новая версия 3.3.1 отображается. Но не уверен, что это правильный способ действий.

13

Итак, похоже, у четырёх человек возникла проблема.

У кого из вас возникли трудности на ARM или на Intel?

14

Отличный вопрос.

Я только что выполнил чистую установку на новой виртуальной машине Digital Ocean, затем запустил пересборку, и всё прошло без проблем.

15

Я использую Intel.

Чтобы решить проблему, мне пришлось создать новый droplet, выполнить чистую установку, восстановить резервную копию, после чего пересборка заработала корректно.

У меня также есть резервная копия рабочей версии (которая на немного более старой версии), но как только я обновился до последней версии через пересборку, возникла та же проблема. Поэтому я подозреваю, что в одном из последних коммитов было внесено изменение, которое ломает обновление со старой версии на новую.

16

Черт.

Хм. Посмотрю, есть ли у меня сайт, который не жалко, если он упадёт.

Думаю, у вас стандартная установка в одном контейнере. Поищу что-то подобное.

17

Просто напоминаю об этом, так как я тоже столкнулся с этой проблемой после указанного коммита. Попробовал все предложенные выше способы для её решения.

18

x86. У меня на хост-системе Ubuntu Bionic… возможно, это имеет значение. Не знаю, какие ОС у других.

19

Поддержка этой версии уже более года как прекращена. Ubuntu 18.04 EOL – keep your fleet of devices up and running | Ubuntu.

Самое время запустить новую виртуальную машину и перейти на неё.

20

Вот дополнительная информация, которая поможет в расследовании проблемы.

Ошибка наблюдается на одном хосте с Ubuntu 18.04.6, но на другом хосте, который также был обновлён сегодня до той же версии Ubuntu, процесс пересборки Discourse прошёл нормально.

Я планирую обновить Ubuntu на проблемном хосте и посмотреть, поможет ли это. Буду держать всех в курсе.

21

Для тех, кого это затронуло, пожалуйста, выполните команду 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
22 
# 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
23

Вывод из ВМ с проблемой восстановления:

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

Просто примечание: в моём случае всё произошло немного иначе.
Восстановление зависло на сообщении The database system is ready to accept connections, как это случалось и у других. Пришлось перезагрузить ВМ и выполнить ./launcher start app, чтобы запустить Форумы. Однако, когда Discourse снова стал доступен, его версия осталась прежней — 3.3.0.beta4-dev.

Сегодня я не смогу выполнить обновление Ubuntu, но буду держать всех в курсе, как только смогу, и сообщу, будет ли восстановление успешным после этого.

Я обновил нашу тестовую среду до Ubuntu 20.6, и восстановление/обновление прошло успешно до версии Discourse 3.4.0.beta2-dev. Однако это та же хост-система, которая вчера без проблем прошла восстановление на Ubuntu 18.4.