Фатальная ошибка при запуске Docker (Oracle VM)

Всем привет — я новичок в Discourse (выглядит потрясающе!) и, хотя у меня есть некоторые общие технические навыки, считаю себя относительным новичком в мире Docker и Linux VM.

У меня есть бесплатная виртуальная машина Oracle, на которой работает Oracle Linux. Я выполнил шаги, описанные здесь (https://blogs.oracle.com/developers/install-run-discourse-for-free-in-the-oracle-cloud), и сейчас запускаю шаг ./discourse-setup.

Постоянно получаю сообщение об ошибке, приведённое ниже. Пробовал запускать discourse doctor, но безрезультатно. Надеюсь, кто-то сможет подсказать, в чём может быть проблема. Большое спасибо заранее! — Тим

[2021-06-11T04:09:29.733935 #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, [2021-06-11T04:09:29.735773 #1]  INFO -- : > sleep 5
2021-06-11 04:09:30.320 GMT [54] LOG:  0 8kB находится вне допустимого диапазона для параметра "shared_buffers" (16 .. 1073741823)
2021-06-11 04:09:30.322 UTC [54] FATAL:  конфигурационный файл "/etc/postgresql/13/main/postgresql.conf" содержит ошибки
I, [2021-06-11T04:09:34.739847 #1]  INFO -- : 
I, [2021-06-11T04:09:34.740097 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: ошибка: не удалось подключиться к базе данных template1: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	соединения через Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:34.860266 #1]  INFO -- : 
I, [2021-06-11T04:09:34.860745 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	соединения через Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.023425 #1]  INFO -- : 
I, [2021-06-11T04:09:35.023810 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	соединения через Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.137806 #1]  INFO -- : 
I, [2021-06-11T04:09:35.138325 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: ошибка: не удалось подключиться к серверу: Нет такого файла или каталога
	Работает ли сервер локально и принимает ли он
	соединения через Unix-сокет "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.257190 #1]  INFO -- : 
I, [2021-06-11T04:09:35.257476 #1]  INFO -- : Завершение асинхронных процессов


ОШИБКА
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' завершилась с кодом возврата #<Process::Status: pid 80 exit 2>
Место возникновения ошибки: /pups/lib/pups/exec_command.rb:112:in `spawn'
Выполнение завершено с ошибкой с параметрами "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
14ef6216494c846091ea6ce48143e2f25018b9d2579b6d4d0021d605f7f5e145
** НЕ УДАЛОСЬ ИНИЦИАЛИЗИРОВАТЬ ** пожалуйста, прокрутите вверх и найдите более ранние сообщения об ошибках, их может быть несколько.

Привет @Meathead40
У меня возникла, возможно, та же проблема.

В июне мне удалось настроить Discourse на Oracle Free. Теперь я снова запустил скрипт настройки, чтобы изменить несколько параметров, связанных с настройками электронной почты.
Первая ошибка, которую я смог отследить в логе: FATAL: configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors.
Однако в моём случае этот файл не существует. Кроме того, служба PostgreSQL не запущена (даже не доступна как служба).

Вам удалось решить эту проблему? Кто-нибудь ещё сталкивался с тем же?

С уважением,
Стеф

Можете ли вы показать вывод команды free -m --si?

Вы смотрели внутри контейнера? Была ли у вас также запись в логе о том, что shared_buffers слишком мала?

В моём случае:

# /var/discourse/launcher enter app
# egrep shared_buffers /etc/postgresql/13/main/postgresql.conf
shared_buffers = 128MB
exit

Привет, @Falco, вот результат выполнения команды:
всего использовано свободно общее кэш/буфер доступно
Память: 703 359 86 7 257 207
Своп: 8388 246 8142

Привет @Ed_S, я получаю следующее сообщение:

/var/discourse/launcher enter app
Не удалось подключиться к демону Docker — проверьте, что он запущен и у вас есть доступ.

Здесь вы должны увидеть тот же файл:
/var/discourse/shared/standalone/postgres_data/postgresql.conf

В идеале, непосредственно перед записью в логе, сообщающей об ошибке в конфигурации, вы увидите строку с описанием этой ошибки.

Возможно, вы найдете лог здесь:
/var/discourse/shared/standalone/log/var-log/postgres/current

Спасибо за предложения. Мне удалось собрать больше информации.
Это из лога, примерно в момент возникновения ошибки (предыдущие сообщения относятся к дням ранее):

2021-08-02 13:33:16.980 UTC [2419] LOG:  received smart shutdown request
2021-08-02 13:33:28.273 UTC [2419] LOG:  background worker "logical replication launcher" (PID 2442) exited with exit code 1
2021-08-02 13:33:28.344 UTC [2437] LOG:  shutting down
2021-08-02 13:33:28.552 UTC [2419] LOG:  database system is shut down

Также я получил конфигурацию общего буфера:

shared_buffers = 128MB     # min 128kB
#wal_buffers = -1            # min 32kB, -1 sets based on shared_buffers

Хм, давайте вернёмся немного назад: какие несколько строк предшествуют ошибке FATAL, где бы вы её ни увидели?

Конечно, и ещё раз спасибо за поддержку.

Я запускаю скрипт настройки на существующей установке, чтобы изменить несколько параметров конфигурации. Первая часть скрипта определяет следующее:

sudo ./discourse-setup 
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
The configuration file containers/app.yml already exists!

. . . reconfiguring . . .


Saving old file as app.yml.2021-08-03-102829.bak
Stopping existing container in 5 seconds or Control-C to cancel.
+ /bin/docker stop -t 30 app
app

Found 0GB of memory and 1 physical CPU cores
setting db_shared_buffers = 0MB
setting UNICORN_WORKERS = 0
containers/app.yml memory parameters updated.

Далее я передаю все параметры конфигурации и запускаю сборку… именно это, вероятно, и есть ключ к решению вашей проблемы:

2021-08-03 10:30:37.709 GMT [55] LOG:  0 8kB is outside the valid range for parameter "shared_buffers" (16 .. 1073741823)
2021-08-03 10:30:37.713 UTC [55] FATAL:  configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors

Это нехороший знак! Это число должно напрямую браться из вывода команды:

free -g --si | awk ' /Mem:/  {print $2} '

Это показывает 703 МБ, что (официально) слишком мало для нормальной работы Discourse. Если вы хотите рискнуть (и при этом не будете иметь поддержки), вы можете изменить магическое число 990 в файле:

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

Да, до сих пор экземпляр работал нормально, и проверка памяти уже была отключена при установке. Это как-то связано с этим постом: Discourse won't install because I have 960MB of ram and not 1GB - Discourse System Administration - Unix Linux Community

В конфигурационном файле проверка всё ещё отключена, но, похоже, она переопределяется? Я попробую изменить значение, как вы указали, и сообщу, что получится.

Хм, многое зависит от того, что вы там сделали.

Мне удалось завершить настройку и пересборку. Шаги были следующими:

  • закомментировать проверку памяти (#check_disk_and_memory) в файле /var/discourse/discourse-setup (не уверен, что это необходимо)
  • выполнить команду sudo ./discourse-setup из папки /var/discourse (это создаст файл /var/discourse/containers/app.yml и попытается продолжить сборку, которая завершится ошибкой, как описано выше)
  • отредактировать файл app.yml, явно установив db_shared_buffers: “128MB” и UNICORN_WORKERS: 1
  • запустить пересборку командой sudo ./launcher rebuild app (из папки /var/discourse)

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

спасибо за поддержку

Рад, что вы разобрались. На связанной ветке и в ветке здесь, на которую она ссылается, мне кажется гораздо предпочтительнее изменить число «магического прощения» 990 на число, соответствующее вашей системе. «Отключение проверки памяти» на самом деле создает проблемы.

Мне очевидно, что команде Discourse нужно установить нижний предел какого-то значения, чтобы провести границу между поддерживаемыми и неподдерживаемыми конфигурациями, и они официально установили его на уровне 1 ГБ, с послаблением до 990 МБ. Но 960 мне кажется довольно близким к 990, и возникает по схожим причинам. С другой стороны, 703 выглядит совершенно иначе!

Привет, Эд,
Согласен, я изменю количество. Меня довольно удивляет такой небольшой объем памяти. Спецификации экземпляра Oracle (бесплатный тариф) указывают 1 ГБ памяти, однако в бесплатной версии доступно примерно 60–70% от этого объема. Я немного запутался и не понимаю причины этого.

Это уже упоминалось ранее — я думаю, Oracle поступает нечестно, предоставляя вам значительно меньше 1 ГБ, который они округляют при описании:

Редактирование: см. соответствующий блог:

Возможно, самое важное упущенное указание — не используйте образ сервера по умолчанию. Для Discourse требуется 1 ГБ оперативной памяти (или примерно столько), но образ Oracle Linux по какой-то причине не оставляет достаточно памяти. Не знаю, сработает ли CentOS, но образ Ubuntu работает нормально. Только обязательно выберите полную установку2, а не «Минимальную».

Я подозреваю, что в Oracle Linux по умолчанию включено множество компонентов, не необходимых для установки Discourse. Предполагаю, что основное назначение этой ОС — размещение серверов баз данных Oracle. :wink: К счастью, образ Ubuntu работает без проблем. Мой тестовый сайт/хостинг комментариев всё ещё работает. (Хотя активности немного.)